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