FRONTBOARD crash App killed while running in the background.

I don't see details in the crash report (such as a "Termination Description") that could guide me to address the issue. So I would appreciate it if you can give me some insight on what could be causing this.

The key detail here is:

Termination Reason: FRONTBOARD 0xbaadca11

Which means:

0xbaadca11 (3131951633) — pronounced "bad call"

The operating system terminated the app for failing to report a CallKit call in response to a PushKit notification.

I assume that since the app was awakened by a VoIP push, those background notifications won't count towards the iOS restriction of not getting too many background pushes:

Correct. There isn't any restriction or limitation on the number of VoIP pushes that can be sent to an app and, indeed, the main reason the CallKit reporting requirements were introduced is that VoIP pushes were being widely abused and we didn't want to artificially limit push volume.

However...

Those pushes are delivered within 30 seconds after the call starts.

...I think using PushKit for things like this is a mistake:

incoming call bye: let the app know that the calling end hanged up the call. incoming call answered: lets the app know that another device (with the same shared number) answered the call (web app, Android).

The problem here is that you MUST report a new call to CallKit for every push you receive so if the user ended the call before either of those messages, you're going to be forced to present an additional, unnecessary, incoming call screen.

IF you choose to use this approach, then the correct way to handle this is to report a new incoming call using the same call ID as your existing call. What will then happen is one of two things:

1. Best case, the existing call is still active, so your "extra" call report will fail with a duplicate call ID error. You can ignore that error and don't need to take any additional action.

2. Worst case, the existing call has already ended, so the call UI will trigger again. Your app (or the user) will then need to end the call.

Returning to the crash itself:

Our app (a VoIP and messaging app) has been experiencing a crash when running in the background for long periods of time (a couple of days) while receiving calls and message notifications.

Based on my own experience, I suspect what's actually happening is something like this:

1. Your app is sent to the background.

2. At some point, the system terminates your app. The exact reason doesn't matter, as it's normal and expected for VoIP apps to be terminated when they're in the background.

3. A VoIP push arrives, and callservicesd (the daemon that manages VoIP apps) launches your app into the background so that it can deliver that push.

4. Your app did not initialize itself properly and, in particular, it never created a PKPushRegistry object and/or set up the delegate.

5. Because PKPushRegistry was never created, callservicesd is unable to deliver the push into your app. A short time after app launch (~7s), callservicesd "gives up" and terminates your app, setting the exception code 0xbaadca11 to indicate why you've been terminated.

A few supporting details for #5:

• If you look at the launch and crash times in your crash logs, I believe you'll find that it's ~7s. That happens to be the current delay callservicesd uses for its enforcement mechanism. There are cases where it could be longer (because something else launched you into the background at an earlier point), but ~7s is what I see most of the time.

• If you look at the stack trace you sent above, it shows your app as idle. That's typical of the pattern above, as that 7s is generally enough time that most apps complete their own launch cycle.

Exactly while failure #4 occurs tends to be very specific to the app implementation; however, the two most common cases I see are:

1. The app assumes the user will always log in when the app launches, which breaks when the app is launched into the background.

2. The app assumes data will be available when it isn't, particularly in the case where the app is relaunched on a locked device immediately after reboot ("Prior to first unlock").

Note that those are the two common, "basic" cases. The details of this can be much more complicated and involved (see this thread for an example). I'd also highlight my advice from this post on that thread:

"On that last point, my recommendation is that VoIP apps should create their basic call handling "infrastructure" as early as possible (typically, applicationDidFinishLaunching) AND that the "core" component should be able to FULLY process a call without ANY of the rest of your app functioning at all."

And then later:

"The goal of my recommendation above is to prevent exactly the kind of issue you're seeing here. It won't prevent your app from failing (obviously, there is some reason your app wasn't able to initialize the way it should have), but it does change the situation from "my app is dying and I don't know why" to "my app received a VoIP push and it couldn't complete the call because <insert component> didn't work correctly."

The crash you’re seeing simply cannot happen in ANY app that actually follows that advice.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Thanks for your response, clarifying the reason the app is killed is very helpful in this case.

I think everything is clear to me at this point. I just want to clarify one thing about my report: the "incoming call bye" and "incoming call answered" pushes are not PushKit notifications, they are the usual background notifications with the content-available flag set to 1. This is why they were the initial suspects. Let me know if you advise against using these background pushes in this case, even if they aren’t to blame.

I think everything is clear to me at this point. I just want to clarify one thing about my report: the "incoming call bye" and "incoming call answered" pushes are not PushKit notifications, they are the usual background notifications with the content-available flag set to 1. This is why they were the initial suspects. Let me know if you advise against using these background pushes in this case, even if they aren’t to blame.

That's an unusual use for those pushes, but no, there's nothing wrong with using them for that. More specifically, as long as these are standard pushes that are delivered into your app through the standard notification delegates, NOT through PushKit, then they cannot cause the crash you're seeing. You may have reliability issues (because the push simply doesn't reach your app), but you won't crash.

Also, just to make sure this was clear, the ONLY thing that can cause this crash:

Termination Reason: FRONTBOARD 0xbaadca11

...is failing to report a CallKit call in response to a VoIP push. Similarly, the dynamics described in this post mean that the ways you trigger this termination are:

1. (Common case) Issues in your app’s logic mean that you don't have a PKPushRegistry object/delegate, making it impossible for the system to deliver the call notification to your app.

2. (Uncommon case) You've intentionally disabled the in-process mechanism which would normally have caused your app to crash when it returned from the registry delegate without reporting a call.

I want to highlight this because I've seen developers waste a lot of time looking for more complex or elaborate explanations, when the underlying issue was that their app simply didn't work the way that it did/should, so they were hitting #1.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware