Thank you — this is very helpful, especially the clarification that PKPushRegistry plays no role in delivery and that the new mustReport delegate is the recommended direction. We will adopt that delegate and post a "Call Missed" notification when delivery latency is too high. Before we close this out, there is one point we'd like your read on, because it's the main reason we escalated. This is a recent regression, not a long-standing condition. These same users, on the same devices, same carriers, and the same usage pattern, received VoIP calls reliably until approximately mid-May 2026 (about a month ago). The onset was relatively sudden and is now consistently reproducible. Nothing changed on our side in that window — same app build, same push server, same apns-expiration — yet reliability dropped sharply across multiple users at roughly the same time. It is predominantly a cellular problem, but it is not exclusive to cellular — we have also reproduced it on Wi-Fi, just far more rarely and with much greater difficulty. Combined with the fact that the failure is cross-app (WhatsApp's own VoIP push was delivered ~3 minutes late on the same device in our tests), our working assumption is that something changed at the platform or network layer recently, rather than our implementation degrading. Question: Were there changes in a recent OS release (or in APNs reconnection / power-management behavior) around that timeframe that could increase how long apsd stays unable to re-establish the APNs connection before the device sleeps? We're trying to understand whether this is expected new behavior or a regression worth a bug report. For completeness, confirming our current implementation matches your guidance: apns-expiration = 0 — every VoIP push is sent with apns-expiration = 0 (immediate-or-discard), specifically to avoid the long-delayed expired-push deliveries you described. We report the call synchronously inside the push handler. The PKPushRegistry is created once and held strongly for the controller's lifetime (not a local var), and we call reportNewIncomingCall(with:update:completion:) synchronously within pushRegistry(_:didReceiveIncomingPushWith:for:completion:) before invoking the PushKit completion handler: final class PushController: NSObject, PKPushRegistryDelegate { // Held strongly for the controller's lifetime — not a local var. private var voipRegistry: PKPushRegistry? func enablePushKit() { let registry = PKPushRegistry(queue: .main) registry.delegate = self registry.desiredPushTypes = [.voIP] self.voipRegistry = registry // retained } func pushRegistry(_ registry: PKPushRegistry, didReceiveIncomingPushWith payload: PKPushPayload, for type: PKPushType, completion: @escaping () -> Void) { let uuid = UUID() let update = CXCallUpdate() update.remoteHandle = CXHandle(type: .generic, value: payload.dictionaryPayload["caller"] as? String ?? "") update.hasVideo = (payload.dictionaryPayload["callType"] as? String) == "video" // Reported synchronously, in the same run-loop turn as the push; // the PushKit completion handler is only called afterwards. provider.reportNewIncomingCall(with: uuid, update: update) { error in completion() } } } The CXProvider is created eagerly at app launch (before PushKit registration) so it is never nil when a push arrives. Evidence attached — same device and build: Cellular (frequent): apsd repeatedly logs Connection closed WWAN with isWWANUsable YES, isWiFiUsable NO (no Wi-Fi to fail over to), and no VoIP push is delivered within the call window. Cross-app (cellular): WhatsApp's own VoIP push (net.whatsapp.WhatsApp) was delivered ~3 min 22 s and ~3 min 34 s late in two separate tests on the same device. Wi-Fi (typical): APNs delivers the push and the call is reported in ~77 ms (apsd … Received message for enabled topic … → app launched → reportNewIncomingCallWithUUID). This is the common Wi-Fi behavior; however we have also observed the same failure on Wi-Fi on rare occasions, which is why we don't believe it is purely a cellular-radio condition. FAIL_17-48_cellular-idle_all-apps-comera-whatsapp-teams.txt FAIL_13-43_cellular_whatsapp-late-3m34s.txt FAIL_13-08_cellular_push-never-delivered.txt Our open question is specifically why this became common only recently, given nothing changed in our app or push pipeline.