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.

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. 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.

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

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

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

Applicaiton is built with WebKit and native camera view controller . Issue is seen always when presenting a UIVideoEditorController class on top of MainVC(webKit). Please refer the attached image Code: self.videoEditor.modalPresentationStyle = UIModalPresentationFullScreen; [viewController presentViewController:self.videoEditor animated: YES completion:nil];

Hello, I'm experiencing an issue with my app where it's being terminated by the system with a watchdog violation during back-to-back messaging operations. I've analyzed the crash logs but would appreciate additional insights on optimizing my approach. I'd appreciate any insights on how to resolve this problem. Crash Details: Exception Type: EXC_CRASH (SIGKILL) Termination Reason: FRONTBOARD with code 0x8BADF00D Error: "scene-update watchdog transgression: app exhausted real time allowance of 10.00 seconds" Reproduction Steps: User A initiates back-to-back messages to other User User A's UI becomes unresponsive and eventually the app crashes. Stack Trace Analysis: The crash occurs on the main thread, which appears to be blocked waiting for a condition in the keyboard handling system. The thread is stuck in [UIKeyboardTaskQueue _lockWhenReadyForMainThread] and related methods, suggesting an issue with keyboard-related operations during the messaging process. Crash Tag Exception Type: EXC_CRASH (SIGKILL) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: FRONTBOARD 2343432205 <RBSTerminateContext| domain:10 code:0x8BADF00D explanation:scene-update watchdog transgression: app<com.msikodiak.eptt(AD934F8A-DF57-4B75-BE73-8CF1A9A8F856)>:301 exhausted real (wall clock) time allowance of 10.00 seconds ProcessVisibility: Foreground ProcessState: Running WatchdogEvent: scene-update WatchdogVisibility: Background WatchdogCPUStatistics: ( "Elapsed total CPU time (seconds): 6.390 (user 3.640, system 2.750), 11% CPU", "Elapsed application CPU time (seconds): 0.020, 0% CPU" ) ThermalInfo: ( "Thermal Level: 0", "Thermal State: nominal" ) reportType:CrashLog maxTerminationResistance:Interactive> Triggered by Thread: 0 Thread 0 name: Dispatch queue: com.apple.main-thread Thread 0 Crashed: 0 libsystem_kernel.dylib 0x1e773d438 __psynch_cvwait + 8 1 libsystem_pthread.dylib 0x2210bc328 _pthread_cond_wait + 1028 2 Foundation 0x1957d8a64 -[NSCondition waitUntilDate:] + 132 3 Foundation 0x1957d8888 -[NSConditionLock lockWhenCondition:beforeDate:] + 80 4 UIKitCore 0x1998f1238 -[UIKeyboardTaskQueue _lockWhenReadyForMainThread] + 456 5 UIKitCore 0x19a3d775c __59-[UIKeyboardImpl updateAutocorrectPrompt:executionContext:]_block_invoke_9 + 28 6 UIKitCore 0x19986b084 -[UIKeyboardTaskQueue lockWhenReadyForMainThread] + 168 7 UIKitCore 0x19a3f2994 -[UIKeyboardTaskQueue waitUntilTaskIsFinished:] + 148 8 UIKitCore 0x19a3f2ac4 -[UIKeyboardTaskQueue performSingleTask:breadcrumb:] + 132 9 UIKitCore 0x199e2f7e4 -[_UIKeyboardStateManager updateForChangedSelection] + 144 10 UIKitCore 0x199e24200 -[_UIKeyboardStateManager invalidateTextEntryContextForTextInput:] + 92 11 WebKit 0x1ad52fa54 WebKit::PageClientImpl::didProgrammaticallyClearFocusedElement(WebCore::ElementContext&&) + 40 12 WebKit 0x1ad55adcc WebKit::WebPageProxy::didProgrammaticallyClearFocusedElement(WebCore::ElementContext&&) + 136 13 WebKit 0x1acec74e8 WebKit::WebPageProxy::didReceiveMessage(IPC::Connection&, IPC::Decoder&) + 18604 14 WebKit 0x1acd21184 IPC::MessageReceiverMap::dispatchMessage(IPC::Connection&, IPC::Decoder&) + 236 15 WebKit 0x1ace449b8 WebKit::WebProcessProxy::dispatchMessage(IPC::Connection&, IPC::Decoder&) + 40 16 WebKit 0x1ace44228 WebKit::WebProcessProxy::didReceiveMessage(IPC::Connection&, IPC::Decoder&) + 1764 17 WebKit 0x1acd1e904 IPC::Connection::dispatchMessage(WTF::UniqueRef<IPC::Decoder>) + 268 18 WebKit 0x1acd1e478 IPC::Connection::dispatchIncomingMessages() + 576 19 JavaScriptCore 0x1ae386b8c WTF::RunLoop::performWork() + 524 20 JavaScriptCore 0x1ae386960 WTF::RunLoop::performWork(void*) + 36 21 CoreFoundation 0x196badce4 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28 22 CoreFoundation 0x196badc78 __CFRunLoopDoSource0 + 172 23 CoreFoundation 0x196bac9fc __CFRunLoopDoSources0 + 232 24 CoreFoundation 0x196babc3c __CFRunLoopRun + 840 25 CoreFoundation 0x196bd0700 CFRunLoopRunSpecific + 572 26 GraphicsServices 0x1e3711190 GSEventRunModal + 168 27 UIKitCore 0x1997ee240 -[UIApplication _run] + 816 28 UIKitCore 0x1997ec470 UIApplicationMain + 336 29 Telstra PTT 0x1004d30c8 main + 56 30 dyld 0x1bd5d3ad8 start + 5964

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

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

Observed few times that providerDidBegin(_:) delegate never called for the complete app session after app init(as part of this CXProvider registered) which was built with SDK 26 and running on iOS 26. This issue observed multiple times with our testing. Since there is no providerDidBegin:, client is marking CallKit as not ready and never report any calls for VoIP APNS and ended up in app crash due to "[PKPushRegistry _terminateAppIfThereAreUnhandledVoIPPushes]" Please refer for sysdiagnose logs : FB19778306

We've observed an issue where the video button on the CallKit UI is disabled during Video VoIP calls. This issue appears to be specific to notch devices running SDK 26 and iOS 26 beta 7, specifically on iPhone 11. We have not seen this behavior on devices with Dynamic Island or on older iOS versions. For further details, please refer to the attached video and sysdiagnose file. : FB19827793 Our experimentation suggests this issue is exclusively present on non-Dynamic Island devices with iOS 26 beta.