iOS Crash Reporting

If you’re used to building Web apps, developing for mobile can be a bit of an eye-opener. Instead of being able to completely control a server-side environment, with an iOS app, you have customers running your software in a myriad of different combinations and configurations.

Between multiple generations of devices with radically different specs, varying network conditions, and users sometimes modifying the software via jailbreak, deploying your app for the first time gives a new meaning to the term “in the wild”.

When the errors do occur, the application may crash. For the user, this could either be a minor annoyance or worse: lost data. Not good…not good at all. If your app crashes all the time, prepare yourself for a lot of one-star reviews in iTunes and a significant delay in your plans for world domination.

Here at Foraker Labs, we want our software to be of the highest quality. To get there, we use tools like crash reporters to make sure we are immediately notified of any problems so we can act on them in future updates. Without the details on the crashes your users may be experiencing, you’re flying blind.

When the App Store originally debuted in 2008, the pickings were slim—not many options for gathering this data. Since then, we’ve been blessed with several choices, both free and commercial. Here are a few of the more popular packages:

  • Apple: iTunes Connect will aggregate crash reports that you can download from them. Unfortunately, these do not always include all of the information you as a developer might want, and they aren’t collected as frequently as other solutions.
  • AirBrake: If you’ve been building Ruby on Rails apps, you may already be familiar with AirBrake. The service from thoughtbot, previously known as Hoptoad, works across several platforms including the Web and Android. This can be an advantage if you’re working on a team with multiple projects that may not all be on iOS.
  • TestFlight: This popular service burst on the scene with a promise to make distributing beta apps easier. Since then, they’ve added their own API, including a crash reporter. If you’re already using TestFlight, this can be a convenient option; plus, the service is currently free.
  • PLCrashReporter: This app, from Landon Fuller, is an early entry that has been enhanced over time by the Open Source community. The library forms the basis of some other crash reporting solutions, including HockeyApp.

Interested in the nitty gritty technical details? Landon Fuller has a good post on the challenges of building a crash reporter for iOS.

Now, those of you that have worked with iOS crash reports before may have come across something looking like this:

Unsymbolicated Crash Report

This report is not “symbolicated”—it’s missing all of the file and line numbers for our app. Not very helpful. Most of the reporting tools will give you tips for setting up your builds to avoid this, but if you’re chasing a bug and this is all you have, you may still be able to get the details you’re looking for.

With each build, Xcode creates a “dSYM” file—these are the “debugging symbols” in the DWARF format that is the default for iOS. You’ll find these baked into the archives that Xcode creates for each distribution (and you might want to check these into your source control system for safe keeping, too).

By using the command line tool “atos” and this dSYM file, you can symbolicate the lines into something meaningful. For example, when I enter the archive directory via Terminal and run this:
atos -arch armv7 -o VegasMate.app/VegasMate 0x00031377

I now see this:
-[TripDetailViewController viewDidLoad] (in VegasMate) (TripDetailViewController.m:57)

Eureka! This is something I can use—this bug’s days are numbered.

Do yourself a favor and look into one of the crash reporting options out there for your app. Your users will thank you.

Tweet at Hunter

Share this post!