Firebase Crashlytics: How Crash Reporting Actually Works

Your app crashes on a stranger's phone in another country. They do not email you. They uninstall. Crashlytics is how you find out it happened, and what line of code was responsible.

It is free and unlimited, on every platform Firebase supports.

What happens at the moment of a crash

1. 1

   The app dies

   Something goes wrong badly enough that the operating system stops the app. Crashlytics has already installed a handler for exactly this moment.

2. 2

   A report is written to disk

   It cannot upload immediately — the app is in the middle of dying. Instead it writes a small report locally: the stack trace, device model, OS version, available memory, and how long the app had been running.

3. 3

   The next launch sends it

   When the user opens the app again, the report uploads. This is why crash counts lag a little behind reality, and why a crash on launch can take a while to show up.

4. 4

   Crashlytics groups it

   Identical crashes from thousands of users collapse into one issue with a count. You see "this crash, 4,812 users" rather than 4,812 separate reports.

Why iOS crashes arrive as gibberish

This is the most-searched Crashlytics problem, and the answer is not obvious.

When Xcode builds your app, it strips out human-readable names to make the binary smaller. Function names become memory addresses. A crash report from that build looks like this:

0   MyApp    0x0000000104a3c8f4 0x104a30000 + 51956
1   MyApp    0x0000000104a3b1a0 0x104a30000 + 45472
2   MyApp    0x0000000104a39c2c 0x104a30000 + 40012

Useless. The translation table lives in a separate file called a dSYM — debug symbols. Upload the dSYM and Crashlytics turns those addresses back into real names:

0   MyApp    CartViewController.applyDiscount(code:) + 84
1   MyApp    CartViewController.checkout() + 212
2   MyApp    CheckoutButton.tapped() + 40

Same crash. Now you know where to look.

Crashes, non-fatals, and ANRs

Crashlytics reports three different kinds of bad, and they are worth telling apart.

Non-fatals are the underused one. When you catch an error and recover gracefully, the user sees nothing — and neither do you, unless you record it.

try {
  await syncBasket();
} catch (error) {
  // The user gets a retry button rather than a crash.
  showRetry();

  // You still find out it happened.
  crashlytics().recordError(error);
}

Making reports easier to debug

A stack trace tells you where. These tell you why.

• Custom keys. Attach state to the report — which screen, which feature flags, whether the user was signed in. When a crash only happens for premium users, a key makes that obvious immediately.
• Log messages. A breadcrumb trail of the last actions before the crash. Enough to reconstruct what the person was doing.
• User identifiers. Attach an ID so you can connect a support email to a specific crash. Use an internal ID, not an email address — this data goes to a third party.

crashlytics().setCustomKey("screen", "checkout");
crashlytics().setCustomKey("plan", "premium");
crashlytics().log("User tapped Pay");
crashlytics().setUserId(internalUserId);

Setup, by platform

That last row surprises people who search for browser crash reporting in Firebase. There is not any.

Reading the numbers

The metric that matters is crash-free users — the percentage of people who used your app today without it dying. Not crash count, which moves with how many users you have.

Above 99% is healthy for most apps. Below 98% and something is wrong for roughly one user in fifty, which is enough to show up in your reviews.

Sort by users affected, not by how recent a crash is. The scariest-looking new crash is often one person on a rooted phone from 2015.