From SDK to interface: totally redesigned crash reports

No one likes it when an app crashes. And that's putting it mildly. Crashes fray the nerves of users and developers alike. Errors in code degrade the user experience and, as a result, affect conversions. Crash analytics are essential for every product team, and the new AppMetrica reports will help you keep a finger on your app's pulse and speed up troubleshooting.

What's new in crash reports

The reports show the number of crashes, sort them by type and frequency, and provide detailed statistics for each crash. This was partly the case before, but now the completely redesigned interface boasts a bunch of extra features. Under the hood, we've added new mechanisms for delivering crash data from devices and automatically loading dSYM and mapping files, plus crash symbolization.

Let's take a closer look.

How crash data collection works

Basically, the process is divided into three stages, each of which has a component in AppMetrica:

1. An app crashes, and the AppMetrica SDK gets a log from the operating system.

If an app suddenly and unexpectedly closes, the operating system generates a crash log file with a stack trace. The AppMetrica SDK on the user's device receives it from the OS and sends it to the AppMetrica server.

2. The crash log is saved and processed on the server.

AppMetrica's backend receives crash data from the SDK and automatically decodes the stack trace. This is possible thanks to integration with operating system APIs and automatic loading of dSYM and mapping files. The crash log is saved in a readable form in the database.

All crashes are grouped by type and location, and then the data is matched to the rest of the information collected by AppMetrica. Metrics are calculated for the number of affected devices and sessions, % of the active audience affected, and other important aspects.

3. The developer receives reports in the interface.

To make the data easier to interpret, AppMetrica groups crashes, categorizes the information, and builds useful data slices and cross-sections.

How the new reports help you deal with crashes

The updated interface allows you to monitor app stability on a daily basis. You can investigate problems on three levels:

Top level on the app health dashboard

Dashboards with crash-free statistics, percentage of affected users, and other metrics will help you monitor your SLA and prioritize crashes in the queue.

The familiar stats are all still there, like the total number of crashes and the number of affected devices.

We also updated the table under the chart and added the following columns:

• First occurrence version — we are now recording which app version first experienced the crash, to help you pinpoint the cause. If a new feature was introduced in the latest version and the app started to crash, it's likely that the feature was released with bugs.
• Last occurrence version — helps clarify whether a crash has been fixed. If you don't see the crash in recent versions of the app, that's good news!

Reproducing a crash involves many factors. You can still filter and group crashes by app version, OS, and other segments, similar to the Audience report. You can also close crashes that have been fixed, just like in a task tracker. If a closed crash reoccurs in a new version, it will be reopened automatically.

Granular statistics for each crash

From the report, you can go to a specific problem and study it in detail. The crash profile is a dashboard that highlights the most important data:

Make use of the new metrics here:

• Background: even if the crash is occurring on a wide scale, you might want to take some things into consideration. Maybe users didn't notice if the app crashed in the background.
• Or maybe it only crashes for power users who have extensively modified the system using jailbreak or superuser rights. These devices are marked with the tag Rooted.

We're not saying that these cases don't warrant code fixes, but sometimes they lower the priority. :)

Internal view of a crash

The stack trace can be viewed from the crash profile. This is the most useful information for developers who are trying to fix the crash:

If the log doesn't provide enough information, user profiles might be helpful. They show what actions users performed before the app crashed. This information is invaluable to QA engineers if the error cannot be reproduced. To view the list of recent events, click View session events on the stack trace page.

All crash reports are already available for full use. In upcoming releases, the error report will be updated and a couple more features will appear, which we will announce separately.

How to switch over to the new reports

First, integrate the latest version of the AppMetrica SDK. Don't forget to connect the crash collection component, now that it's separate.

To make the stack trace readable, AppMetrica needs dSYM for iOS and mapping files for Android. You can upload them manually, or configure automatic upload using the Post API key. All functions related to crash decryption are located in the app settings. There you can also see which versions of the app don't have mapping files.

But AppMetrica will notify you of the missing decryption files in any case:

We redesigned the report at all levels and stages, simplifying many parts of your crash management routine. Crashes are now decoded automatically, and the interface allows developers and QA engineers to access much more useful information in just a couple of clicks. We hope that these large-scale changes will be extremely useful. :)

As always, we welcome feedback. Share your experience with us, on appmetrica@yandex-team.com or via our Facebook page.

App health is in your hands!

The AppMetrica Team