[iOS 26] [CallKit] [SDK 26] Application got crashed while App was Inactive

The crash log, an IPS file, indicates a crash occurred at a specific time, with the exception backtrace pointing to _terminateAppIfThereAreUnhandledVoIPPushes.

So, this crash ONLY occurs for one reason, which is that your app received a voip push and failed to report a new incoming call, as the API contract requires. There's no other way this crash can occur.

However, cross-reference with the SysDiagnose logs, there is no corresponding process or activity for the application at the reported crash time.

The app was not active, nor was it woken up by any event.

I'm not sure where you were looking, but there is plenty of syslog data about the crash. Starting from the crash log, the crash occurred at:

Date/Time:           2025-08-29 16:21:32.6696 +0530
...
Terminating Process: <exec name> [283]

And the time and pid (283) match up with the crash log embedded the system log archive:

2025-08-29 16:21:32.669000+0530 283  <exec name>: {

In terms of the general flow of the crash, your app was initial launched into the background here for a PTT push which it handled properly:

2025-08-29 16:21:19.348953+0530 callservicesd: [com.apple.calls.callservicesd:Default] Successfully launched application with bundle identifier <bundle id>
2025-08-29 16:21:19.353564+0530 callservicesd: [com.apple.calls.callservicesd:Default] Asked to deliver message 0xc70d028c0 to application <CSDVoIPApplication 0xc70cc0f00 bundleIdentifier=<bundle id> environment=production pushKitClient=<CSDXPCClient: 0xc70f6e1b0 object=<NSXPCConnection: 0xc709c6f80> connection from pid 283 on mach service named com.apple.telephonyutilities.callservicesdaemon.voip processIdentifier=283 processName=<process name> processBundleIdentifier=<bundle id> entitlementCapabilities={(
2025-08-29 16:21:19.353685+0530 callservicesd: [com.apple.calls.callservicesd:Default] Delivering 1 channel push payload(s) to application <CSDVoIPApplication 0xc70cc0f00 bundleIdentifier=<bundle id> environment=production pushKitClient=<CSDXPCClient: 0xc70f6e1b0 object=<NSXPCConnection: 0xc709c6f80> connection from pid 283 on mach service named com.apple.telephonyutilities.callservicesdaemon.voip processIdentifier=283 processName=<process name> processBundleIdentifier=<bundle id> entitlementCapabilities={(
2025-08-29 16:21:19.360236+0530 callservicesd: [com.apple.calls.callservicesd:Default] Channel: received ptt push result type :2 participant:<private>

It remained awake in the background and a voip push was then received and delivered to your app ~13s later:

2025-08-29 16:21:32.517408+0530 callservicesd: [com.apple.calls.callservicesd:Default] Asked to deliver message 0xc71ba01a0 to application <CSDVoIPApplication 0xc70cc0f00 bundleIdentifier=<bundle id> environment=production pushKitClient=<CSDXPCClient: 0xc70f6e1b0 object=<NSXPCConnection: 0xc709c6f80> connection from pid 283 on mach service named com.apple.telephonyutilities.callservicesdaemon.voip processIdentifier=283 processName=<process name> processBundleIdentifier=<bundle id> entitlementCapabilities={(
2025-08-29 16:21:32.517512+0530 callservicesd: [com.apple.calls.callservicesd:Default] Delivering 1 VoIP payload(s) to application <CSDVoIPApplication 0xc70cc0f00 bundleIdentifier=<bundle id> environment=production pushKitClient=<CSDXPCClient: 0xc70f6e1b0 object=<NSXPCConnection: 0xc709c6f80> connection from pid 283 on mach service named com.apple.telephonyutilities.callservicesdaemon.voip processIdentifier=283 processName=<process name> processBundleIdentifier=<bundle id> entitlementCapabilities={(
2025-08-29 16:21:32.517889+0530 callservicesd: (ApplePushService) [com.apple.apsd:connection] <APSConnection: 0xc715c0600> returned from <CSDVoIPApplicationController: 0xc71900880> connection:didReceiveIncomingMessage:
2025-08-29 16:21:32.517934+0530 callservicesd: (ApplePushService) [com.apple.apsd:connection] <APSConnection: 0xc715c0600> responding with an ack for message with guid 65D7EF6B-BA2B-40F2-9126-9C3B3AE0B591
...
2025-08-29 16:21:32.518460+0530 <process name>: (CriticalCommunication) didReceiveIncomingPushWithPayload is received <private>

The logging above occurred on thread 4007, which then logged 27 (mostly redacted) log messages before it logged:

2025-08-29 16:21:32.521813+0530 <process name>: (CriticalCommunication) Push Message Relased
2025-08-29 16:21:32.521989+0530 <process name>: (PushKit) The com.apple.developer.pushkit.unrestricted-voip entitlement is no longer supported.
2025-08-29 16:21:32.522031+0530 <process name>: (PushKit) Apps receving VoIP pushes must post an incoming call via CallKit in the same run loop as pushRegistry:didReceiveIncomingPushWithPayload:forType:[withCompletionHandler:] without delay.
2025-08-29 16:21:32.522110+0530 <process name>: (Foundation) [com.apple.Foundation:general] *** Assertion failure in <private>, PKPushRegistry.m:349
2025-08-29 16:21:32.563632+0530 <process name>: (CoreFoundation) *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Killing app because it never posted an incoming call to the system after receiving a PushKit VoIP push.'
2025-08-29 16:21:32.563670+0530 <process name>: CRASH: Killing app because it never posted an incoming call to the system after receiving a PushKit VoIP push.
2025-08-29 16:21:32.563727+0530 <process name>: Stack Trace: <private>

The app was not active, nor was it woken up by any event.

I don't know what data you were looking at, but the log data seems straightforward.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

The newly uploaded logs in the feedback contain the relevant information regarding the issue. Please disregard the earlier uploaded logs.

However, cross-referencing with the SysDiagnose logs, there is no corresponding process or activity for the application at the reported crash time.

The newly uploaded logs in the feedback contain the relevant information regarding the issue.

Unfortunately, the device was rebooted (at ~11:50am) before the sysdiagnose was triggered, which, unfortunately, renders the log largely useless for diagnostic purposes as log purging has destroyed too much context.

In terms of what you said here:

The app was not active, nor was it woken up by any event.

I'm not sure what you mean here. There were three crash logs attached to the bugs. In all three cases, callservicesd initiated the launch:

(1) PID 286:

2025-08-29 11:47:42.381409+0530 runningboardd: Acquiring assertion targeting app< ___ > from originator [osservice<com.apple.SpringBoard>:35] with description <RBSAssertionDescriptor| "FBApplicationProcess" ID:34-35-111 target:app< ___ > attributes:[
2025-08-29 11:47:42.381844+0530 runningboardd: Assertion 34-35-111 (target:app< ___ >) will be created as active
2025-08-29 11:47:42.418884+0530 runningboardd: Now tracking process: [app< ___ >:286]
...
2025-08-29 11:47:42.423299+0530 runningboardd: Acquiring assertion targetingapp< ___ >:286 from originator [osservice<com.apple.telephonyutilities.callservicesd>:148] with description <RBSAssertionDescriptor| "CSDVoIPProcessAssertion-___" ID:34-148-114 target:app<___((null))> attributes:[
	<RBSLegacyAttribute| requestedReason:VoIP reason:VoIP flags:( PreventTaskSuspend PreventTaskThrottleDown WantsForegroundResourcePriority )>,
	<RBSAcquisitionCompletionAttribute| policy:AfterValidation>
	]>

(2) PID 346:

2025-08-29 11:48:51.625626+0530 runningboardd: Acquiring assertion targeting app< ___ > from originator [osservice<com.apple.SpringBoard>:35] with description...
....
2025-08-29 11:48:51.631016+0530 runningboardd: Now tracking process: [app< ___ >:346]
...
2025-08-29 11:48:51.635110+0530 runningboardd: Acquiring assertion targeting [app< ___ >:346] from originator [osservice<com.apple.telephonyutilities.callservicesd>:148] with description <RBSAssertionDescriptor| "CSDVoIPProcessAssertion-___" ID:34-148-259 target:app<___((null))> attributes:[
	<RBSLegacyAttribute| requestedReason:VoIP reason:VoIP flags:( PreventTaskSuspend PreventTaskThrottleDown WantsForegroundResourcePriority )>,
	<RBSAcquisitionCompletionAttribute| policy:AfterValidation>
	]>

(3) PID 350:

2025-08-29 11:49:18.569160+0530 runningboardd: Acquiring assertion targeting app< ___ > from originator [osservice<com.apple.SpringBoard>:35] with description...
...
2025-08-29 11:49:18.574023+0530 runningboardd: Now tracking process: [app< ___ >:350]
...
2025-08-29 11:49:18.578195+0530 runningboardd: Acquiring assertion targeting [app< ___ >:350] from originator [osservice<com.apple.telephonyutilities.callservicesd>:148] with description <RBSAssertionDescriptor| "CSDVoIPProcessAssertion-___" ID:34-148-298 target:app<___((null))> attributes:[
	<RBSLegacyAttribute| requestedReason:VoIP reason:VoIP flags:( PreventTaskSuspend PreventTaskThrottleDown WantsForegroundResourcePriority )>,
	<RBSAcquisitionCompletionAttribute| policy:AfterValidation>
	]>

...and all three processes logged significant data before crashing. With that context, let me return to here:

The app was not active, nor was it woken up by any event.

One thing to understand here is that the system can't really "fake" a crash log. The system creates crash logs by scraping the stack frame state of your process from your process’s own memory. The entire collection process involves a complicated hand of process where the kernel stops your process’s normal scheduling and runtime (since it has "crashed"), then hands that special process to a system daemon which then reads your process’s memory state and uses that to create "a crash log". That process can't really be "faked”, occur by "accident", or be "wrong". Whatever a crash log "shows" is in fact what happened. It's critical to understand this because in a conflict like this:

*I suppose you could build one by hand, but the system certainly doesn't have any way to do that.

However, cross-referencing with the SysDiagnose logs, there is no corresponding process or activity for the application at the reported crash time.

...the crash log is going to be "the truth". There are many reasons why log data might be missing (for example, a device reboot as above). There's basically NO way for the system to generate a crash log without a process having been in exactly the state the crash log shows.

Finally, in terms of the crash log itself, they all crashed with this exception (edited down for clarity):

Last Exception Backtrace:
0   CoreFoundation                    	       0x1901848c8 __exceptionPreprocess + 164 
1   libobjc.A.dylib                   	       0x18d0f97c4 objc_exception_throw + 88 
2   Foundation                        	       0x18e07ea70 -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 288 
3   PushKit                           	       0x244ec8bd8 -[PKPushRegistry _terminateAppIfThereAreUnhandledVoIPPushes] + 168 
...
7   PushKit                           	       0x244ec7c38 __73-[PKPushRegistry voipPayloadReceived:mustPostCall:withCompletionHandler:]_block_invoke + 532 
...
21  libsystem_pthread.dylib           	       0x1ead3e3b8 _pthread_wqthread + 292 
22  libsystem_pthread.dylib           	       0x1ead3d8c0 start_wqthread + 8

This crash can ONLY happen for one reason, namely that you returned from didReceiveIncomingPushWithPayload without having called reportNewIncomingCallWithUUID as the API contract requires.

There are only two reasons that can happen:

1. There exists a code path inside your didReceiveIncomingPushWithPayload handler that could allow reportNewIncomingCallWithUUID to be bypassed. The solution is to fix that.

2. Issues in your implementation make it possible for you to receive a VoIP push before you've properly set up your CXProvider. Note that this is technically a special case of #1.

The second case here is almost always caused by the combination of using secondary queues for PushKit/CallKit and timing problems in that initialization sequence. See this post for more specific advice on avoiding these issues.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware