What Data Do You Need to Know From Crash Reports?

Why you need solid crash reports

At one point or another, all mobile app users have been affected by a frozen frame followed by a crash soon after. Apps crash at an average rate of less than 2%, but still, they greatly affect user experience. A study on user expectations of mobile apps found that 80% of users will uninstall an app that crashes only three times or less. This means that users are unforgiving when it comes to app crashes. And since crashes are an inevitability, the more users adopt an app, it’s essential for developers to know why their apps are crashing. To do so, you would need a crash report, but what exactly are crash reports?

In this post, we’ll walk you through the essential component of crash reports and the added value/functionality you’ll get from your Instabug crash reports.

The essential ingredients of a crash report

There is a lot of data and operations involved at any given time of an app’s operation. When a crash occurs, the data you receive in crash reports have to be useful. Developers need to use the information to assess why the crash happened. So what exactly should the crash report include?

App version: Apps are constantly being updated and iterated on. One of the first steps you should take to assess the severity of a crash is to find out the version of the app that is crashing. You could have already resolved the root cause behind the crash in an updated version of your app.

Device: Knowing what device your app crashed on is also essential. Every device behaves differently due to the hardware underneath, which could affect your app’s performance. You could easily discover a recurring issue on a certain device with crash reports.

OS version: Similar to the device, instead of the hardware environment the app is running on, it’s the software environment. Older versions of an OS or even different OSs can behave differently when it comes to an application.

App view: It’s not enough to know that your app crashed on a certain device and app version. Knowing where in the app did the crash occur is essential to know why the problem happened. Knowing the exception or error that occurred on the certain app view that crashed will tell you what happened. This will add more context to the environment where the crash happened.

Stack trace: Similar to the app view, the stack trace offers a look into the core of the app itself. Stack traces allow you to track the sequences of functions called up until the point the stack trace is generated. In this case, a stack trace will be called at the point of a crash occurring, so having a stack trace sent back with the crash report is very helpful in the debugging process.

Instabug’s crash reports

The essential data sent with crash reports sometimes won’t tell you the entire story. Instabug’s crash reporting tool gives these details, plus a lot more contextual insights that you can use to reduce your app’s crash rate.

Occurrences: It is likely that most crashes will occur more than once. Instead of having a report for every single crash occurrence, it’s better to collect the same crashes together. One crash involves the actual error or exception that occurred and could encompass many crash occurrences over various devices and OS versions. Being able to group all the crash occurrences under one crash report provides a better representation of the data. You can catch a pattern in crashes from a visualized time graph, for example. This wouldn’t be clear by observing each individual occurrence’s data alone. Instabug’s crash reporting tool and dashboard allow tracking and representation of occurrences and crashes.

Tags: Being able to tag different crashes helps you catalog and organize crashes. Tagging your crashes also helps when you’re prioritizing your backlog when you’re dealing with a larger amount of crashes.

Crash severity: Now that all the data has been sent back with the crash report, you will need a quick way to determine how important each crash is. Instabug calculates the severity of each crash to provide an easily digestible metric to help prioritize crashes. Dealing with very severe, urgent crashes affecting many users would take priority, as opposed to an obscure crash that is not likely to occur again.

The complete picture

It’s well established just how bad crashes are for an app whichever way you look at it. The challenge is keeping crash rates as low and possible and knowing how to fix these crashes when they inevitably occur. Your crash reports need to give you more than the brief surface-level data. Knowing in detail what led to the crash will give you a strong insight into why the app crashed. Also being able to track and categorize various occurrences of crashes and assess the severity of different crashes will make you best prepared to solve these issues.