Analyzing Crash Reports

When an iOS or a Mac app crashes, the system creates a crash report that’s very useful for understanding what caused the crash. Crash reports describe the conditions under which the app terminated, in most cases including a complete stack trace for each executing thread.

After you distribute your app, routinely collect and analyze any crash reports.

Collecting Crash Reports

You may receive crash reports from multiple sources throughout the lifetime of your app. For iOS apps, you can solicit crash reports from beta testers, as described in “Soliciting Crash Reports from Testers.” Similarly, you can collect crash reports for Mac apps during testing. You can also download crash reports from iTunes Connect for an app that’s released, as described in “Viewing Crash Reports.”

Analyzing Crash Reports

You analyze crash reports using Xcode. To add crash reports to the Devices organizer, drag the crash reports to the Device Logs group in the Library section. You can then view information about the crash such as the stack trace for each execution thread. Xcode automatically symbolicates crash logs that you import into the Devices organizer. Xcode replaces memory addresses with human-readable function names and line numbers.

For Mac apps, be sure to analyze a crash report using a guest account with a fresh install of the version of OS X that matches the crash report. Don’t analyze a crash report using a developer or admin system account, because the problems you want to analyze may not occur.

For how to interpret an iOS crash report, read Understanding and Analyzing iOS Application Crash Reports.

Make sure that test the exact same build that crashed. You should save all the archives that you distribute for testing and submit to the store. For how to verify if your archive in Xcode matches a crash report, read How to Match a Crash Report to a Build. Later, follow these same steps to determine if you’re testing the same build that you submitted to the store.