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 .

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?

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

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

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

[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

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

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

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 ?

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.

Any update on this issue?

Issue is only happening with one of the devices which is with customer and we cannot deploy the Speakerbox. We tried by disabling the PTT system in the issue observed device and the issue is still observed. Attached logs and video in the feedback. FB19827793 [quote='855161022, DTS Engineer, /thread/797869?answerId=855161022#855161022'] This is a weird one. Can you reproduce this in Speakerbox? And does it happen if you're don't have the PushToTalk system active? From what I can tell in the logs, its seems like this might be caused by some kind of interaction with the PTT system. [/quote]

Yes we did try requesting connectPeripheral() command on receiving disconnect callback but there is one use-case where the behaviour was wrong. Application has issued connectPeripheral() command and is connected with the LE device. User will go and chose "Forget the device " under bluetooth settings. Application will receive didDisconnectPeripheral and because of connectPeripheral() command , it was connecting back again to BLE which was NOT the user wanted Since we saw the above behaviour which will be annoying to user , then we tried scanForPeripheralsWithServices() command with the serviceUUIDs we are interested in. When we use this command is when we saw an issue where our application was not receiving didDiscoverPeripheral() delegate which we were expecting. We did receive didDiscoverPeripheral() delegate the moment we bring our application into foreground

Yes as mentioned earlier, CallKit gets initialised is in Main queue (the mentioned code init is happening in main queue) [quote='856460022, DTS Engineer, /thread/797563?answerId=856460022#856460022'] That's the queue you're targeting, but is that code also running on the main queue? [/quote] As you suggested,we have now initialised PushKit on the main queue. We are currently monitoring the issue since it is not consistently reproducible. Since the issue is not consistent we are monitoring this issue. I'm still not entirely convinced that initialising PushKit on a secondary queue might led the root cause of this problem. As per Feedback analysis: The user launched the application at [07/31 15:04:45:858]*******{}BEGIN LOGGING{}***** Here user has put app to background [07/31 15:20:41:695][ 0x105147e80]<ALA_SIGNAL>: [OS-PLT] -[AppDelegate applicationDidEnterBackground:] and then received an VoIP APNS and it got crashed, [07/31 15:20:55:639][ 0x122c53680] [Pushnotif] [] <ALA_SIGNAL>: [OS-CCF] Enter -[PushNotificationManager pushRegistry:didReceiveIncomingPushWithPayload:forType:withCompletionHandler:] and did not receive a callback for approximately 15 minutes of the entire app session. so does really initialising PushKit on a secondary queue is the primary concern for this issue?

[quote='856777022, DTS Engineer, /thread/797563?answerId=856777022#856777022'] Expanding on that, there isn't really any reason for your app to delay anything based on providerDidBegin. Just start using the provider and everything will work fine. [/quote] Without this check in one of the earlier case CallKit session went into a bad state and there was no recovery for the CallKit session until swipe kill(we don't have the logs now for the instance). Anyway, removed this check and proceeding to report to CallKit without providerDidBegin(_:) check. Will update here if any issues observed. Thanks