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

"We are developing an application use case that requires us to prompt the user to restart their device. We plan to use the system uptime value provided by [NSProcessInfo processInfo].systemUptime to determine if a restart has occurred. Apple's documentation defines this API as 'The amount of time the system has been awake since the last time it was restarted.' Our questions are: Can we reliably use this API, in conjunction with persistent storage, to detect a device restart? Are there any known limitations or considerations when accessing or relying on this API while the application is running in the background?"

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

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.

Rejecting a Cellular Call Also Rejects Application Video Call Steps: 1.When a user receives a cellular call and it is in the "ringing" state and application receives a video call which is reported to CallKit 2.User rejects the Cellular call from Callkit UI, Video call is also getting rejected. 3.Application is receiving performEndCallAction when user is rejecting the Cellular call As a part of CXcallobserver Application is receiving call connected then disconnected for the cellular call Irrespective of OS, the issue only reproduces on cellular calls if Live Voicemail is enabled. Issue is not reproduced when Live Voicemail is disabled for cellular calls, and it is not reproducing on FaceTime calls, regardless of the Live Voicemail setting. This results in a poor user experience because: The recipient unintentionally misses the CallKit-reported call. The initiator receives confusing and inaccurate status information, believing the recipient is busy rather than having chosen to decline the pending video call.

As per the US state law including SB2420 in Texas. We are suppose to meet their compliance. We have following queries Could you please confirm whether the provided Declared Age Range API framework is available for sandbox testing How does the API respond for a region other than Texas

Satellite Communication framework, experiences a failure in receiving network path updates when a device transitions from Satellite to a fringe LTE area. The iOS Status Bar correctly updates to show "LTE," but our application does not receive the corresponding network path update (e.g., via NWPathMonitor). This leaves our app UI locked in "Satellite Mode," while the user sees "LTE" in the status bar, causing critical user confusion. Feedback: FB20976940

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

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.

Application is in foreground state, When a user receives a cellular call and it is in the "ringing" state and application receives a VoIP APNS(video call) which is reported to CallKit. User rejects the Cellular call from CallKit UI, application Video call is also getting rejected (separate feedback - 19017978) and Here the issue is observed that an Application moved to background. Issue is not observed in iOS 18 and older versions. Issue observed only with UISceneDelegate changes. Using traditional UIApplicationDelegate doesn't have the issues. Video and Sysdiagnose logs are added in feedback: FB20187309

Steps To reproduce: Login to application and App has joined the PTC channel. Push the application to background and Lock the device. From the System UI press the talk button which will start transmit. Audio Session has been activated and Audio unit has been initialised properly. On terminator side no media is being played out. Issue observed consistently on specific models which has configured audio codec with Stereo type. More details are added : FB20281626

We have an application WAVE PTT(Push to talk) and Application is in foreground state, When a user receives a cellular call and it is in the "ringing" state and application receives a VoIP APNS(video call) which is reported to CallKit. User rejects the Cellular call from CallKit UI, application Video call is also getting rejected (separate feedback - 19017978) and Here the issue is observed that an Application moved to background(OS26 beta 9). Issue is not observed in iOS 18 and older versions. Frequency : 1 out of 3. Please refer the sysdiagnose logs in below reported feedback ID. Feedback Ticket ID: 20187309 Syslogs Snippet reference: default 2025-09-10 12:30:06.991950 +0530 WAVE PTX 0x10e078100 - ApplicationStateTracker: UISceneDidEnterBackground

Application has specified the bluetooth-central background mode. Peripheral Device(BLE) is connected to the iPhone. Application will initiate a request 'retrieveConnectedPeripheralsWithServices' along with list of services to scan for. Application will receive a list of peripherals connected to the system whose service UUID's match. From the list of peripherals, application will initiate a request 'connectPeripheral' with the interested peripheral along with the option set to 'CBConnectPeripheralOptionEnableAutoReconnect'. This option is available from iOS 17+. CBConnectPeripheralOptionEnableAutoReconnect - This option will help in reconnect back to peripheral when peripheral becomes available. (Turn OFF and Turn ON) How do we achieve the same thing in earlier IOS version

There consistent build failure in Xcode Beta 26.0 (Build 24112) on a project targeting iOS. The build process fails with an error indicating that the actool utility is unable to decode its own version information, leading to the overall build failure. error: Failed to decode version info for '/Applications/Xcode26.0.app/Contents/Developer/usr/bin/actool': The data couldn’t be read because it is missing. Feedback: FB19969269

The crash log, an IPS file, indicates a crash occurred at a specific time, with the exception backtrace pointing to _terminateAppIfThereAreUnhandledVoIPPushes. However, cross-reference with the SysDiagnose logs, there is no corresponding process or activity for the application at the reported crash time. The app was not active, nor was it woken up by any event. IPS file and SysDiagnose logs have been attached in the Feedback. Feedback - FB20044587