CallKit UI with speaker button is not functional - Only speaker mode is enabled

Working through the details:

When a user initiates a video call with CallKit and then, using the existing CallKit session, initiates an audio call, there are no issues with CallKit or the audio.

This is standard and supported behavior, as any app has broad control of its call set while it's active on a call, including initiating outgoing calls from the background (something CallKit normally prevents).

That capability ends:

However, if the user terminates the video call from the CallKit UI, the active CallKit session ends

...when the call ends.

To resume the ongoing audio call, we report a new CallKit call upon the end call trigger.

A few different things I need to say here:

• Why are you doing this? The user ended the call, so the natural result would be to terminate the call. Alternatively, you could also report a new incoming call (which would work).

• Reporting an outgoing call from the background is ONLY supported by CallKit as a compatibility solution for PushToTalk apps. More specifically, ONLY PTT apps with the correct entitlement are allowed to initiate outgoing calls from the background, and those apps should ONLY do so in response to specific user interaction (for example, in response to now playing events or Bluetooth activity).

• This approach has been deprecated since introducing the PushToTalk framework (in iOS 16). We've now disabled the entitlement in the macOS 26 SDK (as announced here), and you should not assume that outgoing call reporting will continue to work, even if it works in the current iOS 26 beta.

In other words, what you ultimately need to do here is either move to the PTT framework or simply stop this. There is a regression here that we should probably address; however, I want to be clear that the ultimate solution here will require you to stop doing this entirely.

In terms of the specifics of the bug here:

While there are no issues with this reporting, the CallKit UI does not provide an audio route for the built-in receiver, and the speaker button remains unresponsive.

I suspect what you're hitting here is an issue with the timing of audio session activation, which has always been somewhat "brittle" and error-prone. In terms of restoring the functionality of your existing approach, 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.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

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

Updated the feedback with sysdiagnose file - FB18855566

First of all, I need to repeat what I said earlier:

In other words, what you ultimately need to do here is either move to the PTT framework or simply stop this. There is a regression here that we should probably address; however, I want to be clear that the ultimate solution here will require you to stop doing this entirely.

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.

Shifting to the workaround side:

Issue(Speaker icon disabled) is still seen after introducing a delay(700 ms) as suggested above.

I'd probably go as high as 0.5s before assuming this won't work, though that will obviously introduce a significant delay.

Having said that, if you really want to use this kind of "flow", then I think my suggestion would be that you try reporting an additional outgoing call early in the call process, probably as soon as the video call is answered. I haven't tested this in a long time, but I believe you're allowed to report an outgoing call anytime your app is active (and always have been).

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

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.

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:

1. Reported a incoming Video call using CallKit
2. User has now initiated a Audio call (Full duplex call) which is using the active callKit session.
3. 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

Let me start by returning to what I said here:

Indeed, the fact this works in iOS 26 is an accidental oversight, not an intentional choice.

That is not an exaggeration. The ability to report outgoing calls from the background was a compatibility workaround we preserved in iOS 13 to support PTT apps. The ONLY reason it continues to work in iOS 26 is because I didn't think about it when we were disabling the PTT entitlement. It will not continue to work and continuing to rely on it is a mistake.

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

I'm sorry, but this isn't something CallKit will continue to support. You need to stop doing this, as it WILL break in the future.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

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

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

Are you able to reproduce the issue with Speakerbox and/or a modified version of Speakerbox?

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware