Crash-free sessions: the metric that predicts app reviews

If you can only watch one of the mobile app quality metrics, watch crash-free sessions. It is the share of user sessions that ended without the app dying, and it tracks app store ratings and thirty-day retention more closely than any feature metric we have seen. A crash is the one experience every user understands and remembers, and it is the one they write about. This article explains how to measure crash-free rate properly, which companion metrics to put beside it, how to wire mobile app monitoring in from the first beta, and what to do when the number drops.

Why crash-free rate predicts reviews

Users rarely review an app because a feature is elegant. They review it because it lost their work, froze at checkout or vanished mid-form. A crash converts a mildly satisfied user into a one-star reviewer in under a minute, and the review outlives the fix. The same crash also sits in the store's own vitals: both Apple and Google surface stability data to developers, and Google's Play Console flags apps that exceed its bad-behaviour thresholds and reduces their visibility. Stability is therefore a distribution problem as well as an experience problem.

The threshold that matters in practice is high. At 99.5% crash-free sessions, one in two hundred sessions still dies; for an app with heavy daily use that is a crash per user every few weeks. Consumer apps with strong ratings generally sit well above that line, and any mobile team should treat a drop below it after a release as a rollback signal.

The quality metrics that belong on one dashboard

Measuring crash-free rate properly

Sessions, not events

Count sessions, not crash events. A single user in a crash loop can generate hundreds of events and make a minor bug look like an outage, while a bug that hits every user once looks small on an event count. Sessions normalise for that. Track crash-free users alongside, because a bug that touches a small share of sessions but most users is the more urgent one.

Segment before you average

A single global number hides everything useful. Break it down by release version, OS version, device class, country and the screen where the crash happened. Most stability problems live in one of those cells: a specific Android manufacturer's build, an older iOS version, a low-memory device tier, or one screen with a heavy image list. The global number tells you something is wrong; the segments tell you what.

Symbolicate or you are guessing

A crash report without symbol files is a list of memory addresses. Upload symbol files and source maps for every build as part of the release pipeline, including React Native's JavaScript bundle, so a stack trace points at a line your engineers can read. This is a one-hour setup that teams skip and then regret at the first serious incident.

Mobile app monitoring from the first beta

Crash reporting must be in the first build that leaves the developer's laptop. Beta testers are the cheapest source of real-device crashes you will ever get, and a beta with no telemetry is a wasted month. The setup is small: a crash reporting SDK, symbol upload in the build, an alert when crash-free sessions for a release drop below a threshold, and a weekly review where the top three crashes by users affected are assigned. The instrumentation we build into every React Native mobile product follows exactly that list.

• Alert on the release, not the app: a new build with a low crash-free rate should page someone within the hour
• Track staged rollout percentages so a bad build can stop at 5% rather than reach everyone
• Feed handled errors to the same tool as crashes, tagged by screen, so silent failures are visible
• Record the network state and the last three navigation events with each crash report
• Review the top crashes by users affected every week, in the same meeting as the roadmap

Stability and the release process

The number is only useful if it changes what you do. Two rules make that happen. First, staged rollouts on both stores, with a go/no-go at each stage based on that build's crash-free rate against the previous build. Second, an explicit rollback path: a server-side feature switch for the risky change, and a halted rollout plus an expedited fix build for a crash. Apple's App Store guidance on app performance treats crashes as a review failure, so the same discipline that keeps ratings up also keeps submissions moving.

Teams that ship weekly and watch this metric tend to find that most crash spikes come from a small set of causes: a third-party SDK update, an unhandled null from a changed API response, an out-of-memory on image-heavy screens on low-end devices, and native module mismatches after a framework upgrade. Each of those has a standard guard, and the API and integrations work on the backend side is often where the second cause is fixed for good.

Where React Native changes the picture

A React Native app has two crash surfaces: native crashes in the platform layer and JavaScript exceptions in the bundle. They need to be captured together and correlated, because a JavaScript error that unmounts the root view feels like a crash to the user even though the process survived. Error boundaries around each major screen, a global handler that reports and recovers, and source-map upload for every bundle are the three things that make the JavaScript side measurable. With those in place the framework choice makes little difference to achievable stability.

A worked example

A last-mile logistics operator's driver app had a rating that fell with every release, and the team could not say why. Crash reporting had been added late and without symbol upload, so the reports were unreadable. Once symbolication and per-release alerts were in place, the pattern was obvious: a single Android device family common among drivers ran out of memory on the proof-of-delivery photo screen, and a background sync retried aggressively on poor networks and hung the UI. Both were fixed within two releases, staged rollouts caught a regression in the third, and the review tone changed within a quarter. The dispatch platform and driver app case study describes the wider build.

Team and timeline

Instrumenting an existing app is a one to two week job for one mobile engineer: SDK, symbol upload, dashboards, alerts and the weekly review format. For a new build it is part of the first sprint and not a separate line. Where the app itself is the problem, a Care Plan covers the ongoing crash review and fix cycle from $1,000 / ₹68,000 a month, and a stability-focused engagement to rework the worst screens is scoped against the pricing page starting points for React Native work at $17,500 / ₹11.2L. Your side names one product owner who attends the weekly review and can approve an expedited release.

Before you start: a checklist

• Crash reporting SDK in the first beta build, not the first store build
• Symbol and source-map upload automated in the release pipeline
• Dashboards segmented by release, OS version, device class and screen
• An alert threshold per release with a named person who receives it
• Staged rollout enabled on both stores with a go/no-go at each stage
• A server-side switch for every risky change so rollback needs no release
• A weekly review of the top crashes by users affected
• A device lab or cloud device farm that includes the low-end phones your users own

Questions clients ask

• Is 99% crash-free good enough? For an internal tool, perhaps. For a consumer or field app used daily, it means regular crashes per user and the reviews will show it.
• Which tool should we use? Any mainstream crash reporter works; the discipline around it matters more than the vendor.
• Do handled errors count? Not in the crash-free rate, but track them, because silent failures cost retention too.
• How fast should we fix a crash spike? Halt the rollout the same day, and ship a fix or a switch-off within the week.
• Does this apply to Flutter or native apps? Yes; only the JavaScript-specific steps change.

Related reading

See app store and Play Store submission for how stability affects review, offline-first mobile apps for the sync failures that masquerade as crashes, and what a Care Plan should include for the ongoing side.

Measure crash-free sessions per release from the first beta, segment it, alert on it and let it stop a rollout; the ratings will follow.