Let the device is in locked screen Get incoming APNS video request to start video recording we are reporting this APNS to Callkit Accept incoming APNS request We are trying to initialise audio unit. Initialisation is success but starting is failing. Note - This issue is reproduced only if we receive video pull request in locked screen, after accepting callkit call we should not unlock the phone. If we unlock phone everything works as expected.

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

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

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

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