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

An issue with the CallKit UI, specifically regarding the functionality of the speaker button.

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.

However, if the user terminates the video call from the CallKit UI, the active CallKit session ends. To resume the ongoing audio call, we report a new CallKit call upon the end call trigger. 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.

IPA was build on SDK 18 and running on iOS beta 26. Issue is NOT seen with SDK18 and running iOS 18.x or lower devices.

Feedback - FB18855566

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

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