What is a crash free rate?

It is the share of sessions or users that did not experience a crash in a given period or release. Teams use it as a headline health metric and compare it across versions to judge whether a release is safe.

Which crash reporting tool should a startup use?

Firebase Crashlytics is free and widely used, while Sentry offers strong error context and performance data across mobile and web. Pick one that supports your framework, such as native, Flutter, or React Native, and that your team will actually check.

Why do my crash reports show unreadable stack traces?

Release builds are obfuscated or stripped of symbols. Upload dSYM files for iOS, and mapping files or native symbols for Android, as part of every release build so reports are translated back to readable code.

What is a staged rollout?

It means releasing a new version to a small percentage of users first, watching crash and error metrics, and increasing the percentage only if the numbers look healthy. Both Google Play and App Store Connect support it.

Should I track non fatal errors too?

Yes. Failed API calls, handled exceptions, and slow screens often hurt users long before they cause a crash. Log them as non fatal events with useful context so you can see patterns.

Mobile App Crash Reporting and Release Health Guide for Startups

For a mobile app, a crash is the most expensive kind of bug. The user does not see an error message, they see the app vanish. Many will not report it. They will simply open something else, and some will leave a one star review that stays on your store listing for years. Unlike a website, where you can fix a bug and every visitor gets the fix on the next load, a mobile fix needs a new build, a review, and users who actually update.

That is why mobile teams need crash reporting and release health monitoring from the very first public build. This guide explains what to track, how to set up readable crash reports, how to roll out releases safely, and how a small team can build a calm, repeatable routine around it.

Crash reporting versus release health

Crash reporting captures individual failures: the stack trace, the device, the operating system version, and what the user did beforehand. Release health looks at the bigger picture: for each version of your app, what share of sessions end cleanly, how many users are affected, and whether things are getting better or worse.

You need both. Crash reports tell you what to fix. Release health tells you whether a new version is safe to keep rolling out and whether your fixes worked.

The metrics worth watching

Crash free sessions: the percentage of sessions without a crash. Good for spotting trends per release.
Crash free users: the percentage of users who did not crash. This is closer to how users feel, since one unlucky user crashing repeatedly looks different from many users crashing once.
Affected users per issue: helps you prioritise. A crash that hits many users on a core screen outranks a rare one in settings.
App not responding (ANR) rate on Android: freezes that may not crash the app but feel just as bad.
Adoption of the latest version: tells you how long old, buggy versions will keep generating reports.
Non fatal error rate: handled exceptions and failed network calls that degrade the experience.

Choose a target for crash free users that suits your product, write it down, and review it before each release. A number nobody has agreed on cannot block a bad build.

A real-world example

Here is an illustrative scenario. A food delivery startup ships version 2.4 of its app on a Friday. Reviews begin to mention "app closes when I tap pay". Without crash reporting, the team has to reproduce the problem by guessing which phone models and Android versions are involved. They lose a weekend and a chunk of orders.

Now imagine the same team with crash reporting and a staged rollout. The release goes to a small slice of users first. Within hours, the dashboard shows a new crash cluster on one Android manufacturer's devices, tied to a payment screen library call. The team pauses the rollout, ships a patch the next day, and the vast majority of users never see the broken version. The difference is not better engineers. It is better visibility and a smaller blast radius.

Step by step: setting up crash reporting properly

Pick a tool and install it in the first build. Firebase Crashlytics and Sentry both support native iOS, native Android, Flutter, and React Native. Initialise it as early as possible in app start so that start up crashes are captured.
Upload symbols on every release build. Without dSYM files (iOS) or mapping and native symbol files (Android), stack traces are unreadable. Automate the upload in your build pipeline so no one has to remember.
Tag every report with the app version and build number. This is what makes per release comparison possible.
Add useful context. Attach the anonymous user ID, the current screen, feature flag states, and a trail of recent actions (often called breadcrumbs). Avoid personal data such as names, phone numbers, or payment details.
Log non fatal errors. Wrap network calls and critical flows so failures are reported with the endpoint, status code, and a request ID that links to your server logs.
Set up alerts that mean something. Alert on new issues in the latest release, on a sudden rise in crash rate, and on issues that affect many users. Send them to a channel the team actually reads. Our guide on error monitoring, alerts, and triage explains how to keep alerts useful without overwhelming people.
Run a test crash. Before launch, force a crash in a release build and confirm it shows up readable in the dashboard. Many teams discover broken symbol uploads only after a real incident.
Create a triage routine. Review new issues daily during a launch week and weekly afterwards. Assign an owner, set a priority, and link the issue to your tracker.

Staged rollouts: your safety net

Both Google Play and the App Store let you release gradually. On Google Play you choose a percentage of users. On iOS, phased release spreads an update over several days to automatic updaters. The practice is simple and powerful.

A sensible rollout routine

Start with a small percentage of users, enough to produce meaningful data for your traffic.
Wait until the new version has real sessions, then compare its crash free rate against the previous version.
Increase the percentage in steps if metrics hold. Pause or halt if they do not.
Keep the ability to ship a hotfix quickly, including an expedited review request when the issue is serious.

Before any rollout, a good beta process catches the obvious problems. If you have not set one up, our article on mobile app beta testing with TestFlight and Play Console walks through it.

Handling users who stay on old versions

A fix is only useful if people install it. Some users keep auto update off and may run a broken version for months. Plan for this on day one. Version gating lets you prompt users to update, or require it when an old version is dangerously broken or incompatible with your server. We cover the design and trade offs in our guide to force update and version gating for mobile apps. Pair it with API versioning so that older clients keep working while you roll out changes.

Common causes of mobile crashes

Memory pressure on low end devices, especially from large images or unbounded lists.
Null or unexpected data from the backend that the app did not anticipate.
Threading mistakes such as updating the interface from a background thread.
OS version differences where an API behaves differently or is missing on older releases.
Third party SDK bugs in analytics, ads, or payments libraries that you did not write.
Permissions that are denied or revoked while the app runs.

If a large share of your users are on budget Android phones, test on real low end hardware. Emulators rarely reproduce memory and storage limits faithfully.

Key benefits of doing this well

Better store ratings because crashes are fixed before they accumulate in reviews.
Faster debugging thanks to device details, breadcrumbs, and readable stack traces.
Confident releases with a data driven decision to continue or halt.
Clearer priorities based on how many users each issue affects.
Calmer teams who find out about problems from dashboards, not angry messages.

Privacy and compliance notes

Crash reports can accidentally collect sensitive information, such as a phone number in a log message. Scrub or avoid logging personal data, review what your SDK captures by default, and mention crash and diagnostic collection in your privacy policy and app store data declarations. If you serve users in India, align your practices with the requirements of the DPDP Act as your legal advisers recommend.

A starter checklist

Crash reporting SDK initialised at app start.
Symbol upload automated in the release pipeline.
Version and build tagged on every event.
Alerts for new issues and crash spikes in the newest release.
Staged rollout enabled for every production release.
A named owner for weekly triage.

If you are planning a new app or want an existing one made more reliable, our team can help through our mobile app development services.

Building a release routine your whole team follows

Tools only help when people use them consistently. Agree on a simple release routine and put it in writing. Before each release, check the crash free rate of the current version and confirm there are no unresolved high impact issues. On release day, start the staged rollout, assign one person to watch the dashboard for the first few hours, and post a short update in your team channel. After a few days, review what was found, close fixed issues, and note anything that the beta test missed so you can improve it next time.

Keep the routine light. A short checklist that gets used every time is far more valuable than a detailed process that is abandoned after a month. Over a few releases, the habit becomes automatic, and your team spends less energy worrying about what might be broken and more on improving the product.

Conclusion

You cannot prevent every crash, but you can control how quickly you learn about them and how many users they reach. Install crash reporting before your first public release, make sure stack traces are readable, track crash free users per version, and roll out gradually so a bad build is stopped while it is still small. Combine that with version gating and a regular triage habit, and your app's reliability becomes something you manage deliberately instead of something you discover through one star reviews.

Frequently Asked Questions

What is a crash free rate?: It is the share of sessions or users that did not experience a crash in a given period or release. Teams use it as a headline health metric and compare it across versions to judge whether a release is safe.
Which crash reporting tool should a startup use?: Firebase Crashlytics is free and widely used, while Sentry offers strong error context and performance data across mobile and web. Pick one that supports your framework, such as native, Flutter, or React Native, and that your team will actually check.
Why do my crash reports show unreadable stack traces?: Release builds are obfuscated or stripped of symbols. Upload dSYM files for iOS, and mapping files or native symbols for Android, as part of every release build so reports are translated back to readable code.
What is a staged rollout?: It means releasing a new version to a small percentage of users first, watching crash and error metrics, and increasing the percentage only if the numbers look healthy. Both Google Play and App Store Connect support it.
Should I track non fatal errors too?: Yes. Failed API calls, handled exceptions, and slow screens often hurt users long before they cause a crash. Log them as non fatal events with useful context so you can see patterns.