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

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

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.

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

"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?"

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