Crash reporting that actually leads to fixes

01Why the headline number misleads

Crash-free sessions at 99.5% sounds excellent and means one in two hundred sessions ended in a crash. For an app with meaningful usage that is a large number of people, concentrated - crashes are rarely uniformly distributed.

Worse, the metric only counts hard crashes. An app that hangs, shows a permanent spinner, silently fails to save, or renders an empty screen is entirely broken from the user's perspective and perfectly crash-free.

Segment before drawing conclusions. A crash affecting one OS version or one device model can be invisible in the aggregate and catastrophic for that segment.

02Making reports actionable

A stack trace without context tells you where the process died, not why. The difference between a fixable report and an unfixable one is almost entirely the context attached.

• Attach breadcrumbs: the screens visited, the last few network calls and their status, and key state transitions before the crash.
• Record the app version, OS version, device model, available memory and whether the session was a fresh install. Memory-related crashes cluster on low-memory devices and are otherwise unreproducible.
• Ensure symbolication actually works for every release. Unsymbolicated production crashes are noise, and this breaks quietly when build settings change.
• Log non-fatal errors deliberately - caught exceptions, failed requests, failed saves. This is where the user-visible failures live.
• Tie reports to a user or session identifier so support tickets can be matched to actual crashes.

03Triage that does not drown the team

Crash lists sort by volume, which biases toward crashes in high-traffic screens and away from severe crashes in critical flows. A crash that stops ten people paying matters more than a cosmetic one hitting a thousand.

Weight by impact on the flow rather than count. In practice that means a small set of flows - authentication, payment, the core task - where any crash is high priority regardless of volume.

Watch for new crashes after each release specifically, rather than absolute volume. A newly introduced crash with modest volume is usually more urgent than a long-standing one, because it is a regression you can attribute and revert.

04Closing the loop

A crash fixed in code is not fixed for users until they update, and adoption of a release takes weeks. Track crash rate by app version rather than overall, or an improving aggregate will hide that the affected users are still affected.

For severe cases this is what remote configuration and forced upgrades are for. If you cannot disable a broken feature without shipping a release, every crash costs you the full store review and adoption cycle.