Track App Crashes

Answers to questions about how crashes are tracked and best practices for avoiding false crashes.

Important: We highly recommend that you update to iOS SDK version 4.8.6, which contains critical changes that prevent false crashes from being reported.

When does Adobe report a crash?

If your application is terminated without having first been backgrounded, the SDK reports a crash the next time your app is launched.

How does crash reporting work?

iOS uses system notifications that allow developers to keep track of and respond to different states and events in the application lifecycle.

The AdobeMobile iOS SDK has a notification handler that responds to the UIApplicationDidEnterBackgroundNotification notification. In this code, we set a value indicating that the user has backgrounded the app. On a subsequent launch, if we cannot find that value, we report a crash.

Why does Adobe measure crashes this way?

This approach of measuring crashes provides a high-level answer to the question, "Did the user exit my app intentionally?"

Crash reporting libraries provided by companies like Apteligent (formerly Crittercism) use a global NSException handler to provide more detailed crash reporting. Your app is not allowed to have more than one of these kind of handlers. We have chosen not to implement a global NSException handler to prevent build errors, knowing that our customers might be using other crash reporting providers.

What can cause a false crash to be reported?

The following scenarios are known to falsely cause a crash to be reported by the SDK:

  1. If you are debugging using Xcode, re-launching the app while it is in the foreground causes a crash.

    Note: You can avoid a crash in this scenario by backgrounding the app prior to re-launching from Xcode.
  2. If your app is in the background and sends Analytics hits via any call other than trackActionFromBackground, trackLocation, or trackBeacon, and the app is terminated while in the background (either manually or by the OS), the next launch will be a crash.

    Note: If the background activity happens beyond the lifecycleTimeout threshold, this might also result in additional false launches being reported.
  3. If your app is launched in the background (as a result of a background fetch, location update, etc.), and is terminated (usually by the OS) without ever coming to the foreground, the next launch (whether in the background or in the foreground) results in a crash.

  4. If you programmatically delete Adobe’s pause flag from NSUserDefaults while the app is in the background, the next launch or resume causes a crash.

How can I prevent false crashes from being reported?

The following practices can help you prevent false crashes from being reported:

  • In iOS SDK 4.8.6, code was added to better determine whether or not a new lifecycle session is actually desired. This code fixes false crashes #2 and #3 above.

  • Make sure you perform your development against non-production report suites. This should prevent false crash #1 from occurring.

  • Don't delete or modify any values that the AdobeMobile SDK puts in NSUserDefaults. If these values are modified outside of the SDK, the data reported will be invalid.

Parent topic: Analytics