Any update on this issue?

Further testing on other devices, including the iPhone 13 (iOS 26 beta 8) and other dynamic island devices, indicates that the issue is not present on those models. However, the issue is consistently observed and reproducible only on the iPhone 11 (iOS 26 beta 8). This device is with customer and unable to deploy the Speakerbox.

Thanks for the update. [quote='855119022, DTS Engineer, /thread/797563?answerId=855119022#855119022'] Oddly, as far as I can tell, the issue has basically been present from the beginning, so I'm not sure why I haven't heard of this before. Are you creating CXProvider on a background thread? I generally recommend using the main thread for CallKit and PushKit, and it's possible that initializing them on a background thread might make this problem more likely due to differences in thread priority. [/quote] Here as mentioned in the feedback, the CallKit gets initialised is in Main queue, please refer the below code: callkitProvider = [[CXProvider alloc] initWithConfiguration:config]; [callkitProvider setDelegate:self queue:dispatch_get_main_queue()]; But client has getting initiated in secondary queue for the PushKit, voipRegistry = [[PKPushRegistry alloc] initWithQueue: voipPushNotificationQueue]; does this could lead to the issue regarding not received providerDidBegin(_:) delegate ?

We are working on handling the above use case. on the original issue about this thread, the speaker toggle not working. This is occurring even when re-initiating CallKit in the foreground state. Updated feedback - FB18855566

Please find the feedback ID: FB19754948 Attached the sample project in the above feedback, which demonstrates the issue.

[quote='852438022, DTS Engineer, /thread/793663?answerId=852438022#852438022'] That statement was not a vague warning. We are ACTIVELY shutting down the PTT workarounds we created in iOS 13. That includes starting outgoing calls from the background. Indeed, the fact this works in iOS 26 is an accidental oversight, not an intentional choice. [/quote] Client is already migrated to PTC framework. we have a use case which actually needs to report Audio and video calls to CallKit (in this case BLE permission is enabled.) As mentioned earlier: Reported a incoming Video call using CallKit User has now initiated a Audio call (Full duplex call) which is using the active callKit session. User has now ended call in CallKit UI, To resume the ongoing audio call - client requires to report to callKi, which is on end call action and no early call process at this moment

Its partially rendered(components loaded) even after brought to foreground. Using Main storyboard and configured with MainViewControlller which adds the webKit to the view with autolayout (No issues on layout) Hence no code additions handling at willConnectToSession. (Does require any if so) Part of BG launch, say 2 seconds later post to this willConnectToSession, client is loading local html page using [webView loadFileURL:urlReq allowingReadAccessToURL:urlReq];

you might be able to get this working by adding an additional delay after the first call terminates before you trigger the second call. That separates the two transitions, which might be enough to allow the second to complete. Issue(Speaker icon disabled) is still seen after introducing an delay(700 ms) as suggested above. Updated the feedback with sysdiagnose file - FB18855566

Issue is not seen when diagnose file is captured in iOS beta 4 devices.

The client requests registerForRemoteNotifications, and then receives a token delegation before the user has acknowledged the notification permission. For your reference, here are the relevant logs: <PushToTalk> <ALA_SIGNAL>: Enter -[PushNotificationManager registerForPushNotification:] [2442] PushNotificationTypeRemote Timestamp: 2025-07-24 13:06:12.368408+05:30 <ALA_SIGNAL>: Enter -[AppDelegate application:didRegisterForRemoteNotificationsWithDeviceToken:] [2442] Timestamp: 2025-07-24 13:06:13.575766+05:30 In this situation, if the user subsequently acknowledges the notification permission, and the token received during the initial delegation is not the same as the one received during the registerForRemoteNotifications request, will the client receive another token delegate?

Thanks for the update, Yes it is for iOS . Trying to understand why enterprise and debug builds don't show the same complaint, especially when frameworks are embedded in the NSE .

I have uploaded the Sysdiagnose logs from iPhone and Sysdiagnose from Mac as well in the Feedback. Please let me know if anything else is required

Feedback reported with sysdiagnose file https://feedbackassistant.apple.com/feedback/18897587

Thanks for the detailed explanation.

We observed an issue on a low-end device where the OS throttled a request, causing approximately an hour delay in its initiation. The throttling was due to MemoryPressurePolicy and CPUUsagePolicy. We would like to understand the real use case that would lead to this behavior. Additionally, we are looking for information on whether there is any delegate that could inform the client about this throttling.