We are seeing a reproducible scenario on iOS 26 where incoming VoIP push notifications are never delivered when the device has been idle and screen-locked for 30+ minutes. The same failure was observed simultaneously on WhatsApp, and Microsoft Teams and our app as well, on the same device during one incident, confirming this is a platform-level issue and not specific to our implementation.
We have captured full system logs across three separate incidents. Below are the exact log sequences.
Incident — All VoIP apps fail simultaneously (Our app, WhatsApp, Teams)
Device: iPhone 17 Pro · iOS: 18.x · Network: 5G NSA (kNRNSA)
The device had been idle with the screen locked for approximately 31 minutes. An LTE cell handover caused apsd to begin an APNs reconnection. powerd entered policy 3 before apsd reached channel-flow viable, defuncting the app.
17:45:59.562 symptomsd New RRC 0 when previous 1 from pdp_ip0
↑ Radio drops to RRC_Idle. Device has been idle since 17:14:56 (31 min).
17:46:01.206 CommCenter #I Mapping the registration state to kRegisteredHome
↑ LTE cell handover triggers RRC reconnect.
17:46:01.330 apsd [C138 IPv4#b71cac13:5223 ready parent-flow
(satisfied (Path is satisfied), interface: pdp_ip0[lte],
scoped, ipv4, ipv6, dns, expensive, uses cell, LQM: good)]
event: path:satisfied_change @594.391s
↑ APNs path re-satisfied. Reconnection begins.
channel-flow viable NOT yet reached — TLS handshake still in progress.
17:48:08.057 apsd Powerd has requested assertion activity update
↑ Warning: powerd about to change policy.
── 2 minutes 40 seconds after APNs reconnect started ──
17:48:41.248 powerd Sending com.apple.powerd.assertionpolicy 3
17:48:41.250 apsd Update assertion policy 3
17:48:41.250 powerd Activity changes from 0x1 to 0x0. UseActiveState:0
17:48:41.250 powerd hidActive:0 displayOff:1 assertionActivityValid:0
↑ Screen off, device locked. OS enters restricted idle.
apsd restricted. APNs reconnection abandoned.
17:48:42.669 kernel necp_process_defunct_list: necp_update_client abort
nexus error (2) for pid 1518 Comera
↑ Kernel terminates Comera's network stack via NECP.
No API available to prevent this.
WhatsApp and Teams remain suspended — no DEFUNCT,
but apsd in policy 3 means no push delivery for them either.
── Dead zone: VoIP pushes for all 3 apps undeliverable ──
17:50:04.028 powerd Process CommCenter.104 Created SystemIsActive
"com.apple.ipTelephony.sipIncoming.cell"
↑ Incoming cellular PSTN call forces system wake.
17:50:04.494 powerd Sending com.apple.powerd.assertionpolicy 0
17:50:04.598 apsd Update assertion policy 0
↑ Full wake. Queued VoIP pushes from Comera, WhatsApp,
and Teams are delivered simultaneously.
Gap between channel-flow viable needed and actual delivery: 4 minutes 3 seconds. Recovery trigger: external cellular call from carrier — not any app action.
Working case (same test, different conditions)
Device: iPhone 17 Pro · iOS: 26.5.1 · Screen unlocked, no hotspot
19:2x:xx apsd policy state {downgradeWhenLocked: NO,
isSystemLocked: NO,
isConnectedOnUltraConstrainedInterface: NO}
↑ Device unlocked. No policy 3. Comera NOT defuncted.
Push delivered. Call rings normally.
Our implementation
PKPushRegistry is held strongly and re-registered on every applicationWillEnterForeground reportNewIncomingCall(with:update:completion:) is called synchronously within pushRegistry(_:didReceiveIncomingPushWith:) VoIP background mode entitlement is present App has com.apple.developer.pushkit.voip entitlement
Questions
Is there any entitlement or API to prevent NECP from defuncting a process holding an active PKPushRegistry? The VoIP push entitlement exists for exactly this background delivery scenario.
Is pushDisallowed being applied to apps with VoIP push entitlements when InternetSharingActive == 1 intentional? Should VoIP entitlements exempt an app from the Internet Sharing Policy gate in dasd?
Is there a documented way to know when apsd has fully completed APNs reconnection (i.e. channel-flow viable) so a server can time push retries more accurately within a call validity window?
What is the recommended apns-expiration value for VoIP pushes to survive brief APNs reconnection windows without exceeding a 60-second call validity period?
Full log stream captures available for all incidents.