Understanding Crash Reports
Last week Apple began giving developers access to crash reports from end users. The availability of these reports is surprisingly good news for developers, as it now gives us access to valuable information that we otherwise might not have.
This newfound access is a bit of a mixed blessing, however. Some crash reports are difficult to decipher, and without an understanding of what the user was doing when the crash happened, can drive a developer mad.
A spectrum of crashes
For those not aware, every time an app on your iPhone crashes, it records a report of the crash, and sends this report (anonymously) to Apple when the device is sync’ed with iTunes. The report contains information about the operating system version, type of crash, and the location in the code where the crash occurred. As of last week, developers now have access to these crash reports via their iTunes Connect accounts.
Sounds good, right? A report containing details of the crash! Now go fix the bug you lazy developer!
For some types of crashes, it is in fact that easy. By examining the location of the crash, it becomes clear what caused it, and the developer knows exactly how to fix it. Unfortunately, many times it’s not that easy.
Investigating crash reports is a lot like detective work. You’ve got a crime scene, and some evidence about what happened. Sometimes the evidence clearly shows all you need to know. Other times, you need to use your detective skills to deduce what happened.
While the format of a crash report is always the same, the evidence contained in the report can vary in its usefulness. Continuing our criminal justice metaphor, there are a few different types of crashes that developers can run into:
Caught red-handed — You’ve found the cookie thief with his hand in the jar. You’ve got fingerprints. There is no mistake about who did it or how he did it. These are the simplest crash reports to deal with. By knowing the location of the crash, the cause is immediately obvious. Often times, these kinds of crashes are due to simple coding mistakes, and would cause a crash in the same place in the same way every time. These crashes are the easy ones, and putting a fix in place is usually just as quick as reading the crash report itself.
High-value suspect — You’ve got a hunch about who did it. The list of possible suspects is small and it’s easy to check for alibis. While these types of crash reports are not as obvious as the previous one, they provide some good hints about what might be causing the crash. Often times, they give the developer a clue he can use to try to reproduce the bug himself (Which is always a good first step to fixing a bug). And with time, once you’ve got a reproducible case, you’ve got your man, and a fix is often just a few keystrokes away.
X-File mystery — These are the spooky ones. Lights flashing in the sky. Footprints too big to be human. Weird shapes in corn fields. Ships and planes disappearing mysteriously without a trace. These crash reports are the developer’s worst nightmare. Yes, you can see exactly where the crash is happening, but it doesn’t seem possible. There is seemingly no explanation for how the program could crash where it appears to be crashing. You can stare at your code for days, and never see how to reproduce the crash. If you want to see a grumpy programmer, give him one of these types of crash reports. Much like the mysteries listed above, the real explanation (if one is ever found at all) is often something obvious that’s easy to overlook.
Retracing your steps
One thing that crash reports don’t capture, which is invaluable when trying to solve crash mysteries, is a description of what the user had been doing up until the point of the crash. Knowing the steps that the user took to cause the crash is often the difference between finding the root cause of the problem in a few minutes versus a few days. This is something to keep in mind when submitting crash reports to developers. The more detail the better. If you are able to get a concise set of steps that reproduces the problem every time, this is best thing you can give a developer when reporting a crash. It’s a dream come true when you’re battling a tough crashing bug.
This is where you can help as the recipient of a crash. While getting the crash report document from Apple is useful, understanding the history of actions that led to the crash is even better. And there’s no way a developer can get this information unless you give it to them.
It’s understandable that being the recipient of a crash is a frustrating experience. On top of losing time and work after a crash, the last thing you may want to do is spend more time composing an email to the developer explaining what happened. After all, isn’t it the developer’s fault for writing bad code? Shouldn’t they have gotten it right the first time?
Yes, absolutely.
Pitching in
There is no disputing that crashes (and bugs of any kind) are caused by bad code. Unfortunately, it’s nearly impossible to write bug-free code. Good programmers know how to minimize bugs, but even the best coders can never really say their software is 100% bug free.
The problem is exacerbated for one-person indie developers, some of who design, develop and publish their software in their free time during nights and weekends. We don’t have large development teams with dedicated quality-assurance testers. Many times we’re the only ones writing code. We depend on the generosity of beta testers (who are usually just enthusiastic customers) to sanity-check our software.
This is not meant to be an excuse, or a license to write buggy software. Of course, no one likes to have bugs in their apps, and we do our best to minimize them. But, under these circumstances, tradeoffs are often made that favor publishing our software early and often, at the risk of letting some defects slip through.
So, the next time one of your favorite apps crashes, consider emailing the developer. Don’t assume that they already know about the problem. Don’t vent about the crash in an App Store review. Do send them a crash report and a description of what you were doing when it happened.
No developer likes learning that their software is crashing, but they’ll love you for taking the time to help them fix it.