CallKit report incoming with same UUID

Yes — CallKit will return callUUIDAlreadyExists on the second report, which suppresses the second ring. However, on iOS 16+ we observed that the duplicate reportNewIncomingCall still produces a brief banner flash (~80–120 ms on A13-class silicon) before CallKit rejects it. On newer silicon the flash is imperceptible but a subtle haptic tick still plays.

To make the duplicate report truly invisible, three things together:

1. Deterministic UUID derivation from the call ID (SHA-256), so both transport paths converge on the same UUID without any coordination.

2. A phantom CXCallUpdate with empty caller info on the duplicate path — if the race slips through, what flashes is an empty card, not "Unknown".

3. Immediately in the completion block, a historical end: reportCall(with: uuid, endedAt: Date(timeIntervalSinceNow: -3600), reason: .answeredElsewhere)

The .answeredElsewhere + historical endedAt combination is the only end reason we found that CallKit dismisses with zero transient UI — no flash, no haptic, no Missed entry in Recents. We tried .remoteEnded, .failed, .declinedElsewhere, and .unanswered — each has a visible or audible side-effect.

Full writeup with drop-in Swift code, reproduction guide, and the full list of alternatives we tried and rejected:

https://github.com/sefatanis/ios-callkit-duplicate-ring-suppression

Tested on iOS 14.8 – 18.1.

So, first and foremost, if you haven't already, then you should adopt the new PushKit delegate we just added. That's the "proper" solution to these issues, as it will allow you to simply skip any call you’re not obligated to report.

Similarly, if that delegate returns "mustReport", then I would suggest just reporting the call with a new UUID. The checks are structured in such a way that I don't think there's ANY way you could actually get this to happen:

• PKVoIPPushMetadata.mustReport=true

AND

• The call to fail with callUUIDAlreadyExists

Yes — CallKit will return callUUIDAlreadyExists on the second report, which suppresses the second ring. However, on iOS 16+ we observed that the duplicate reportNewIncomingCall still produces a brief banner flash (~80–120 ms on A13-class silicon) before CallKit rejects it.

Did you file a bug on this and, if so, what's the bug number? When we first introduced this "trick", callservicesd was dropping the duplicate call as soon as it arrived so the rest of the call infrastructure never even saw the call. Any sort of glitch like you're describing indicates that there is something very odd going on.

Next, looking over the post you linked to (interesting write-up, BTW), I have a few comments:

Dual-path delivery: your backend must send BOTH a PushKit VoIP push AND an ordinary alert push (APNs alert, FCM, etc.) for the same call.

Why are you doing this? A standard alert push and VoIP push have basically IDENTICAL delivery behavior. More to the point, how is the standard alert push helping your app? It won't wake your app, so you'll either end up:

1. Posting an alert you don't need (because your app was asleep).

2. Receiving the push in-app... because callservicesd woke your app up to handle the VoIP push!

Note that these issues can easily make it seem like push latency it higher/lower/different than it really is, as differences in infrastructure timing swamp relatively small differences in actual arrival time.

Note that this:

The two pushes travel over different APNs topics (VoIP vs alert), arrive on independent TCP connections,

...is false. Both push types are received by APNs over the same network connection. This is visible in the console log if you know what to look for.

and are dispatched into different iOS delivery pipelines.

This is true. VoIP pushes are routed to callservicesd while standard pushes are routed to the standard push infrastructure.

Many production apps do this intentionally for reliability — VoIP has a hard rate limit (~3/min on iOS 13+) and alerts are the safety net.

What?? Where have you heard of this? And have you filed bugs? I have no idea where this idea would have come from but I'm not aware of any such limit and it's totally the opposite of my own experience. In particular:

• The primary reason the iOS 13 call reporting requirements were introduced was widespread PushKit behavior that could charitably be described as "bonkers". So apps were generating 100+ pushes/minute for EVERY call report.

• Between iOS 13 and 14, a number of small timing bugs in callservicesd enforcement mechanism were found by a developer whose testing harness was... unique. My favorite example was an invalid termination which was reliably reproduced by repeating the voip push-> call report-> end call immediately cycle every 7s (no more, no less)... for several HOURS.

As I said, I don't know where this idea came from but it's not true and never has been. As long as you report a call as the system requires, you can send as many VoIP pushes as you want.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware