We require assistance in resolving a critical audio design conflict within our Push-to-Talk (PTT) application. Our current volume amplification strategy—which relies on applying a GAIN factor to PCM samples in conjunction with setting the AVAudioSession category to Playback—is working successfully when PTT is used independently. However, upon integrating and reporting the same PTT call through the CallKit framework, this amplification effect is lost. The CallKit integration appears to be forcing a different, non-amplifying audio session category or configuration, negatively impacting the user's perceived call volume. We need guidance on how to maintain the AVAudioSessionCategoryPlayback setting, or an equivalent high-volume configuration, while operating under the control of CallKit.

The iOS application is a Central Manager connected to a Bluetooth Low Energy (BLE) accessory that utilizes the Hands-Free Profile (HFP). When the application plays a notification tone (using AVAudioPlayer or System Sounds), the audio is incorrectly routed to the device's internal speaker instead of the active HFP headset. How do we programmatically ensure that these notification tones are automatically and reliably routed to the connected HFP headset

When an iOS device is connected to a Bluetooth accessory that utilizes the Hands-Free Profile (HFP), we are encountering an incorrect audio routing behavior specifically for system notification tones. Accessory Connected: The iOS device is successfully connected to a Bluetooth accessory (specifically, a WM500 device) using the HFP profile for voice communication. Voice Audio: Audio streams related to phone calls or voice communication (using the HFP/SCO link) are correctly routed to the WM500. Notification Tones Issue: System notification tones, which are played using the tonetype.systemsounds API, are not being routed to the connected HFP accessory (WM500). Instead, they are incorrectly played through the iOS device's built-in speaker. This causes a poor user experience, as critical application alerts and system notifications are missed when the user is relying on the connected HFP accessory for all audio output.

When an iOS device is connected to a Bluetooth accessory that utilizes the Hands-Free Profile (HFP), we are encountering an incorrect audio routing behavior specifically for system notification tones. Accessory Connected: The iOS device is successfully connected to a Bluetooth accessory (specifically, a WM500 device) using the HFP profile for voice communication. Voice Audio: Audio streams related to phone calls or voice communication (using the HFP/SCO link) are correctly routed to the WM500. Notification Tones Issue: System notification tones, which are played using the tonetype.systemsounds API, are not being routed to the connected HFP accessory (WM500). Instead, they are incorrectly played through the iOS device's built-in speaker. Accessory team has suggested to establish SCO connection to route the tones through WM500. But iOS does not provide an external API (like Android's startBluetoothSco) to explicitly force the establishment of an SCO connection for notification tones. Is there any other approach to establish SCO connection in iOS to route notification tones through WM500

Share Age Range Permission is set to 'Ask First'. Application requested for AgeRange via requestAgeRange API. System presented a consent window where user has to make a choice. User did not acted. Application was pushed to background. Our Application supports PushToTalk Framework and we have successfully joined the channel already. User tapped on the blue-pill , SystemUI will get presented. User tapped on the SystemUI, A New Full Screen SystemUI will get presented. User chosen 'Leave' option and our application left the active channel. 10 User brought the application to foreground and the previous "Share Age Range" system window disappeared. 11. After Step 10, We need to terminate and launch our application in order to get the "Share Age Range" system window. Is "Share Age Range" system window getting disappear is expected here or a BUG

Facing an issue with audio playback using AVPlayerViewController in iOS application. We are using the native player to play recorded audio files. When the AVPlayerViewController appears, the native user interface is displayed correctly, including the playback controls and the volume slider. However, when the user interacts with the volume slider The slider UI moves and responds to touch events. The actual audio output volume does not change. The audio continues playing at the initial volume level regardless of the slider position. We initialize the player and present it modally using the following code: AVPlayerViewController *avController = [[AVPlayerViewController alloc] init]; avController.player = [AVPlayer playerWithURL:videoURL]; // Setting initial volume avController.player.volume = 1.0f; avController.modalPresentationStyle = UIModalPresentationOverFullScreen; avController.allowsPictureInPicturePlayback = NO; // Present the controller [self presentViewController:avController animated:YES completion:nil];

We are getting the above mentioned error while uploading to TestFlight. We have used a Swift Class to request for the Age Range via DeclaredAgeRange Framework. We have exposed Swift class and a helper function to be available in Objective-C layer. We have enabled the following build settings SWIFT_OBJC_INTERFACE_HEADER_NAME = "Common-Swift.h"; SWIFT_OBJC_BRIDGING_HEADER = "Common-Bridging-Header.h "; ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES = YES Also we are compiling the application using latest available Xcode release 17C52 Is there anything else we need to do to resolve the error?

We are experiencing a failure in CLMonitor event delivery when the application is launched into the background via an APNS (Remote Push Notification). Even when a CLBackgroundActivitySession is instantiated immediately upon background launch, CLCircularGeographicCondition "Enter" events are suppressed. The system fails to deliver these events until the user manually brings the application to the Foreground. This indicates that CLBackgroundActivitySession does not correctly maintain background persistence when the session begins in a background state rather than transitioning from the foreground. Comparison of API Behavior (Background State) Launch via APNS: CLMonitor: Fails to trigger "Enter" events until the app is manually brought to the foreground. Legacy API: Successfully triggers and delivers "Enter" events immediately upon background launch. Exit Event Reliability: CLMonitor: Reliably triggers exit events even in the background. Legacy API: Reliably triggers exit events. Foreground Dependency: CLMonitor: Requires a foreground transition to "flush" or activate the delivery of pending entry events. Legacy API: No foreground transition required; events are delivered directly to the background process. Event Recovery: CLMonitor: Relies on the developer re-instantiating the CLMonitor and awaiting the events stream, which appears to "stall" during warm-starts. Legacy API: Relies on the CLLocationManagerDelegate which remains active as long as the manager instance exists. Steps to Reproduce Preconditions: Location Permissions: Set to "Always Allow". Background Modes: "Location updates" and "Remote notifications" enabled. App State: Terminated or Killed (by the user or the OS). Reproduction Path: Trigger Background Launch: Send a silent push notification (APNS) to wake the app in the background. Initialize Session: Within the background launch sequence (e.g., didFinishLaunchingWithOptions), immediately create and hold a strong reference to a CLBackgroundActivitySession. Register Monitor: * Initialize CLMonitor using requestMonitorWithConfiguration. Add a geofence using addConditionForMonitoring with a CLCircularGeographicCondition. Simulate Entry: Move the physical device (or simulate location) into the geofence boundary while the app remains in the background state. Observe: No "Enter" event is received in the CLMonitor event stream. Foreground Transition: Bring the app to the foreground. Actual Result: The "Enter" event is only delivered the moment the app enters the Foreground. Expected Result: The CLBackgroundActivitySession should enable CLMonitor to deliver "Enter" events immediately in the background, parity with the deprecated startMonitoringForRegion API.

Hi there, I am trying to register for an App Identifier with the new PushToTalk Capability but getting the following message This request is forbidden for security reasons The selected team does not have a program membership that is eligible for this feature. If you need assistance, please contact Apple Developer Program Support. https://developer.apple.com/support We have enrolled for Annual Apple Developer Program Could you please help us in resolving this error.

Crash observed on brought app to foreground with exit reason (namespace: 3 code: 0x2) - OS_REASON_CODESIGNING App was being idle and then the user brought an application to foreground, on being app transition observed app crash. 2025-04-23 19:16:26.795985 +0530 launchd exited with exit reason (namespace: 3 code: 0x2) - OS_REASON_CODESIGNING, ran for 1801880ms default Exception Type: EXC_BAD_ACCESS (SIGKILL) Exception Subtype: KERN_PROTECTION_FAILURE at 0x0000006d6f632e74 Exception Codes: 0x0000000000000002, 0x0000006d6f632e74 VM Region Info: 0x6d6f632e74 is in 0x1000000000-0x7000000000; bytes after start: 401300729460 bytes before end: 11016130955 REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL commpage (reserved) fc0000000-1000000000 [ 1.0G] ---/--- SM=NUL reserved VM address space (unallocated) ---> GPU Carveout (reserved) 1000000000-7000000000 [384.0G] ---/--- SM=NUL reserved VM address space (unallocated) UNUSED SPACE AT END Termination Reason: CODESIGNING 2 Invalid Page Attached the crash stack file and sysdiagnose file here https://feedbackassistant.apple.com/feedback/17723296

Before device Reboot: Here no issue from keychain. 2025-06-17 11:18:17.956334 +0530 WAVE PTX [DB_ENCRYPTION] Key successfully retrieved from the Keychain default When device is in reboot and locked (Keychain access is set to FirstUnlock) App got woken up in background SEEMS(NOT SURE) DEVICE STILL IN LOCKED STARE IF YES THEN WHICH IS EXPECTED 2025-06-17 12:12:30.036184 +0530 WAVE PTX <ALA_ERROR>: [OS-CCF] [DB_ENCRYPTION] Error while retriving Private key -25308 default 2025-06-17 12:15:28.914700 +0530 WAVE PTX <ALA_ERROR> [DB_ENCRYPTION] Error retrieving key from the Keychain: -25300 default —————————————————— And as per logs, here user has launch the application post unlock and application never got the keychain access here also. HERE STILL HAS ISSUE WITH KEYCHAIN ACCESS. 2025-06-17 12:52:55.640976 +0530 WAVE PTX DEBUG : willFinishLaunchingWithOptions default 2025-06-17 12:52:55.651371 +0530 WAVE PTX <ALA_ERROR> [DB_ENCRYPTION] Error retrieving key from the Keychain: -25300 default

Our application has initiated an NSURLSession data task, and we have received an initiation ID. However, Application not received callback on the subsequent activity: the task has not been requested, has not timed out, and no error callback has been received. [06/17 09:29:40:559][ 0x282a7d8c0] Requested TaskIdentifier 120 2025-06-17 09:29:40.623337 +0530 nsurlsessiond SUBMITTING: com.apple.CFNetwork-cc-166-373-Task .&lt;120&gt;:A71666 default 2025-06-17 09:29:40.631280 +0530 dasd Submitted Activity: com.apple.CFNetwork-cc-166-373-Task .&lt;120&gt;:A71666 at priority 10 default Seen couple of rejection with for CPUUsagePolicy and MemoryPressurePolicy 2025-06-17 09:29:40.989360 +0530 dasd com.apple.CFNetwork-cc-166-373-Task .&lt;120&gt;:A71666:[ {name: CPUUsagePolicy, policyWeight: 5.000, response: {Decision: Must Not Proceed, Score: 0.00, Rationale: [{[Max allowed CPU Usage level]: Required:90.00, Observed:95.00},]}} {name: MemoryPressurePolicy, policyWeight: 5.000, response: {Decision: Must Not Proceed, Score: 0.00, Rationale: [{[memoryPressure]: Required:1.00, Observed:2.00},]}} ], FinalDecision: Must Not Proceed} default 2025-06-17 10:55:22.500277 +0530 dasd com.apple.CFNetwork-cc-166-373-Task .&lt;120&gt;:A71666:[ {name: MemoryPressurePolicy, policyWeight: 5.000, response: {Decision: Must Not Proceed, Score: 0.00, Rationale: [{[memoryPressure]: Required:1.00, Observed:2.00},]}} ], FinalDecision: Must Not Proceed} default And more an hour later then it throws with an error BUT NEVER indicated the same to client 2025-06-17 10:55:27.426549 +0530 WAVE PTX Task .&lt;120&gt; is for &lt;&gt;.&lt;&gt;.&lt;120&gt; default 2025-06-17 10:55:27.776951 +0530 nsurlsessiond Task .&lt;120&gt; summary for task failure {transaction_duration_ms=5147145, response_status=-1, connection=0, reused=1, request_start_ms=0, request_duration_ms=0, response_start_ms=0, response_duration_ms=0, request_bytes=0, response_bytes=0, cache_hit=false} default 2025-06-17 10:55:27.777096 +0530 nsurlsessiond NDSession &lt;714296D7-20F9-4A0A-8C31-71FB67F39A56&gt; Task .&lt;120&gt; for client will be retried after error Error Domain=_nsurlsessiondErrorDomain Code=6 UserInfo={NSErrorFailingURLStringKey=, NSErrorFailingURLKey=, _NSURLErrorRelatedURLSessionTaskErrorKey=, _NSURLErrorFailingURLSessionTaskErrorKey=} - code: 6 default Then It got resumed and says successful but never got any callback on the same to client 2025-06-17 10:55:28.877245 +0530 nsurlsessiond NDSession &lt;714296D7-20F9-4A0A-8C31-71FB67F39A56&gt; Task .&lt;120&gt; resuming default 2025-06-17 10:55:55.225456 +0530 nsurlsessiond Task .&lt;120&gt; received response, status 401 content K default 2025-06-17 10:55:55.250371 +0530 nsurlsessiond Task .&lt;120&gt; finished successfully default Please refer feedback for diagnose logs: https://feedbackassistant.apple.com/feedback/18173303

When attempting to open sysdiagnose logs collected from an iPhone running iOS 26 beta 3 on macOS Console, the application consistently crashes. Crash report has been added for reference. Apple Feedback- FB18834450

I'm encountering an issue with our legacy Objective-C codebase that uses UIApplicationDelegate. Here are the steps to reproduce the issue: Uninstall the application from the device. Install and launch the application. As part of the launch event, the client requests notification permission. The permission prompt is still displayed, even though the client receives a remote notification token (which appears to be a cached one). I followed the same steps with a sample app built with Swift (SwiftUI), and this issue did not occur. In the Swift app, I consistently received a delegate<didRegisterForRemoteNotificationsWithDeviceToken> call after the user allowed the notification permission. Could you please provide some insights into why this might be happening with only our client?

We have a client with an application that includes a main application, NSEs (Notification Service Extensions) as an extension, and framework1 embedded within the main application. The NSEs also require framework1 as a dependency. When we embedded framework1 within the NSEs, the App Store Connect validation failed with the following error: Validation failed (409) CFBundleIdentifier Collision. There is more than one bundle with the CFBundleIdentifier value 'com.test.xyz-LoggerUtility' under the iOS application 'test.app'. (ID: -----------) We've observed an issue specifically when uploading to App Store Connect. We're able to debug and distribute the application without any problems using our enterprise distribution.