CallKit does not activate audio session with higher probability after upgrading to iOS 18.4.1

Just to provide an update: Our metrics show that iOS 18.6 is still maintaining a high one-way ratio.

Is this with or with the workaround I recommended?

BTW, since you've raised this issue to your team, is it possible to share the plan or indicate in which version the issue is expected to be resolved?

No, I'm afraid I can't talk about our release schedule.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Hi @DTS Engineer

Is this with or with the workaround I recommended?

No, we may try your recommended workaround solution. However, it won't be implemented quickly before we release to production.

Hi @DTS Engineer

I would like to update our metrics for iOS 26 regarding this issue. It appears that the problem persists on iOS 26 and has worsened as the iOS 26 call count has increased. We will keep eyes on our metrics and post update here.

Has there been any specific change on iOS 26?

We start to implement your recommended solution, but we still need time to release it to our production environment.

@DTS Engineer

The iOS 26 audio session issue has significantly worsened since the iOS 26 release. Currently, it affects 0.628% of calls, resulting in thousands of impacted calls daily, compared to approximately 300,000 total calls per day with iOS 26. We anticipate this issue to escalate further as iOS 26 adoption increases.

Given the critical nature of this problem to our operations, we respectfully request that it be given higher priority or escalated for immediate attention.

After the iOS 18.4 system update, we also encountered an increase in the number of failed call recording initiations for incoming calls. We tested several methods midway through, and only force-quitting the app and restarting it would restore the functionality. Recently, we tried the method suggested by Apple engineers: calling cxProvider.setConfiguration once before each reportNewIncomingCall invocation. Since then, the rate of failed incoming call recordings has started to decrease. This method is recommended for everyone to try, and we would like to thank the Apple engineers for their suggestion.

Glad to here that's working!

Note if you have a case where you get the same failure even with the workaround I suggested, please:

• File a separate bug on it.
• Start a new forum thread on it (this one is getting long).
• Include links to both this forum thread and the new thread in that bug.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

@Sierre Thank you for the information, glad to here that's working. We also have implemented the suggested solution in our app and are awaiting rollout. We hope it will also help resolve the issue with our app.

@rc-yorick_zheng is your problem has been solved?

One bit of follow-up on the bug fix side of this:

FB19429215 (CallKit does not activate audio session with higher probability after upgrading to iOS 18.4.1)

Having looked into the issue in more depth, there are technical issues that are likely to delay a fix coming from our side. The CallKit team is still committed to resolving this, but you should not expect the issue to be resolved in the short term.

I'll also say that, based on my own analysis, I do NOT think this is in fact a "new" issue. That is, going back to the original report on this thread:

We've noticed that this issue occurs more frequently after upgrading to iOS 18.4.1

The focus here was on the increased rate; however, it's very likely that this was simply a shift in the rate an existing bug occurred, NOT a new/different issue. Because of that, my recommendation is that all CallKit apps send a "setConfiguration" immediately before they report a new call. It's the best way I can see to prevent the problem from occurring and is already fully supported by the API, so it's unlikely to introduce new problems. This also means that this code can be left in place indefinitely, regardless of our own bug fix schedule. I strongly suspect that using this approach will improve overall call reliability across all system versions, not just our most recent releases.

*As I noted earlier, it's the only way to do per-call ringtone and icon customization.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Hi @DTS Engineer

After rolling out the workaround solution ("setConfiguration" immediately before reporting a new call), the issue still persists. So looks like the workaround can not resolve this issue. cc  @goat_herd

Today, we reproduced this issue once on iOS 26, WITH the workaround solution. I have reported a bug.

FB20789841 (CallKit does not activate audio session, the issue rate increased on iOS 26.)

Base on our metrics, this issue is the primary contributor to one-way audio problems in our app and continues to increase as iOS 26 adoption grows. The occurrence rate seems to be twice as high on iOS 26 compared to iOS 18. Our metrics currently show a 0.67% rate for iOS 26, and this figure is still rising.

!!!Given the ineffectiveness of the workaround, we respectfully request that this issue be given higher priority. This is particularly important as iOS 26 is being adopted by an increasing number of iPhone users.!!!

FB20789841 (CallKit does not activate audio session, the issue rate increased on iOS 26.)

I've looked over the sysdiagnose from that log and I'm left a bit confused. You said that you've applied the workaround I'd suggested, but when I look at the log you sent I don’t see the workaround I'd suggested. I can see where you're reporting calls:

2025-10-23 16:00:39.916170+1100 <exec>: (CallKit) [com.apple.calls.callkit:Default] Provider <private> was asked to report a new incoming call with UUID: <private> update: <private>
…
2025-10-23 16:01:34.063889+1100 <exec>: (CallKit) [com.apple.calls.callkit:Default] Provider <private> was asked to report a new incoming call with UUID: <private> update: <private>
…
2025-10-23 16:02:01.765404+1100 <exec>: (CallKit) [com.apple.calls.callkit:Default] Provider <private> was asked to report a new incoming call with UUID: <private> update: <private>

However, if the workaround was active I'd expect to see a log message like this before each of those call reports:

2025-10-23 16:00:39.916170+1100 <exec>: (CallKit) [com.apple.calls.callkit:Default] Provider <private> was notified that configuration was set to <private> update: <private>

...but I don't actually see evidence of ANY setConfiguration calls. Every indication in the log is that you setConfiguration when you initially connected and that logging was then lost due to purging.

What's particularly frustrating here is that there is every indication in the log that the workaround would have worked, as the core failure is the same as the other cases I've looked at:

2025-10-23 16:01:52.259438+1100 callservicesd: (AudioSession) [com.apple.coreaudio:as_client]     AVAudioSession_iOS.mm:597   Creating proxy session failed, session ID = 0x0, error = <NSError:0x60000071c03da10(NSOSStatusErrorDomain:-50) - {
    NSLocalizedDescription = "Session lookup failed";
}>

...and later in that same log, your app IS able to activate the AudioSession later in the same log, probably because of a direct "setActive" call while your app was in the foreground.

2025-10-23 16:01:07.946140+1100 callservicesd: [com.apple.calls.callservicesd:Default] Entered foreground for call with identifier <private>

2025-10-23 16:01:17.244642+1100 Glip: (AudioSession) [com.apple.coreaudio:as_client]     AVAudioSession_iOS.mm:984   Activated session 0xd387b18

Note that I'm particularly concerned about the workaround here because if the workaround I've suggested DOESN'T work, then that indicates a much deeper failure in the audio system that CallKit may not be able to address.

If you're able to reproduce the issue with the workaround, please provide a sysdiagnose showing that failure, ideally with the FaceTime debugging profile installed.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware