- Every app needs crash reporting before launch, because users rarely report crashes and app store reviews come too late.
- Crashlytics is no-cost for mobile apps and fits apps already using Firebase.
- Sentry covers the app, web front end and back end in one place and reports crash-free sessions and users per release.
- Without symbol files, mapping files or source maps, crash reports are unreadable, so upload them in every release build.
- Crash tools collect device and diagnostic data, so keep personal data out of logs and declare it correctly in the stores.
Should a mobile app use Crashlytics, Sentry or both?
If the app already uses Firebase and you mainly need crash reports and alerts, Firebase Crashlytics is the simple choice and is no-cost for mobile apps. Choose Sentry when you want one tool across the app, the web front end and the back end, with release health such as crash-free sessions per version. Running both is possible but adds setup and duplicate alerts, so do it only for a clear reason.
Whatever you choose, set it up before launch. Users rarely report crashes; they uninstall or leave a review. Our mobile app development team treats crash reporting as part of the first release, not a later add-on.
What does a crash reporter actually tell you?
- The stack trace: the exact line of code where the app failed.
- The device and system: model, operating system version and app version.
- The steps before the crash, from logs and breadcrumbs your code records.
- Custom keys you attach, such as the screen name or plan type, which make patterns visible.
- Grouping: thousands of crash events are grouped into a short list of issues, ranked by how many users they affect.
What is Firebase Crashlytics good at?
Google describes Crashlytics as a lightweight, realtime crash reporter for Apple, Android, Flutter and Unity apps. It groups related crash events into issues and sends realtime alerts for new, regressed and growing issues, per the Crashlytics documentation. You can add logs, custom keys and non-fatal errors, and when Google Analytics is also in the app, Crashlytics records breadcrumbs of user actions before each crash.
Cost is simple: the Firebase pricing page lists Crashlytics for mobile apps as no-cost on both the free and pay-as-you-go plans. If the app already uses Firebase for push notifications or analytics, adding Crashlytics is a small step.
What does Sentry add?
Sentry has SDKs for Android, Apple platforms, Flutter and React Native, and also for web front ends and back ends such as JavaScript, PHP with Laravel, Node.js and Python, as its platforms list shows. That means one place to follow a problem from a crash in the app to an error in the API behind it.
Its release health view tracks crash-free sessions, meaning the share of sessions not ended by a crash, and crash-free users, meaning the share of distinct users who did not experience one, along with how quickly each release is adopted (Sentry: release health). That makes it easier to decide whether to pause a staged rollout. Check Sentry's current plans against the number of events you expect before choosing it.
Why do symbol files and source maps matter?
Release builds are compiled, optimized and often obfuscated, so raw crash reports show memory addresses or scrambled names instead of your code. Each platform needs its own files uploaded with every release:
- iOS: debug symbol (dSYM) files. When they are missing, Crashlytics shows a missing dSYM alert, and the docs note Xcode often simply is not producing them (Firebase: dSYM files).
- Android: R8 or ProGuard mapping files. The Crashlytics Gradle plugin detects obfuscation and uploads the mapping file automatically (Firebase: mapping files).
- React Native: JavaScript source maps, which Sentry's setup wizard configures for Xcode and Gradle builds (Sentry: React Native source maps).
Make these uploads part of the automated release pipeline, then force a test crash in a release build and confirm the report is readable. Our guide to CI/CD for small teams covers the pipeline itself.
What data do crash tools collect, and what must you disclose?
Crashlytics always collects stack traces, application state and device and system information, and collects any custom keys, logs and free-text user IDs that developers attach, per Firebase's App Store data collection guide. Sentry's Apple SDK declares crash data, performance data and other diagnostic data in its privacy manifest (Sentry: Apple privacy manifest).
- Never log passwords, payment details, health data or full addresses in breadcrumbs or custom keys.
- Use an internal user ID rather than an email address if you need to link crashes to accounts.
- Declare crash and diagnostic data in the App Store privacy details and the Google Play Data safety form; the accuracy of those answers is the app owner's responsibility.
When does it make sense to run both?
Running both is reasonable when Firebase is already central to the app and the back end team already uses Sentry for the API. In that case, keep Crashlytics for app crashes and use Sentry for back end errors, or move the app to Sentry entirely; sending every crash to two tools mostly doubles the alerts. If you do run both in the app, confirm with a forced test crash that each still receives reports.
How should alerts and triage work after launch?
- Alert on new issues, regressed issues and sudden spikes, not on every single crash.
- Tag every report with the app version and build number, and release to a small share of users first where the stores allow it.
- Give each issue an owner and a decision: fix now, fix in the next release, or ignore with a reason.
- Watch the API as well as the app; our guide on monitoring a production web app covers the server side.
We set this up as part of the release process, together with the hosting and deployment work in our cloud and DevOps service.
Frequently asked questions
Do the app stores not already show crashes?
App Store Connect and Google Play Console do show some crash and stability data, which is worth checking. A dedicated tool adds the detail developers need to fix problems: readable stack traces, custom keys, logs of what happened before the crash, grouping into issues and alerts when something new or regressed appears.
Does adding a crash reporting SDK slow the app down?
Both tools are designed to be light, and reports are usually sent on the next launch rather than during the crash. Performance tracing is a separate feature that collects more data; enable it with a sample rate rather than for every session, and check the effect on a real low-end device before release.
Can we track errors that do not crash the app?
Yes. Both tools record non-fatal errors that your code catches and reports, such as a failed payment call or a screen that could not load. These are often more useful than crashes, because they show where users get stuck. Report them deliberately, with a clear name, so they do not drown the real crashes.
Who should receive crash alerts?
The developer or team on duty for the app, through a channel they actually watch, such as a team chat or email. Alert on new issues, regressed issues and sudden spikes, not on every single crash. Agree in advance who looks at an alert within a working day and who decides on a hotfix.
We use Flutter or React Native. Does that change the choice?
Both tools support Flutter and React Native. The extra step is making sure the Dart or JavaScript layer is readable too: React Native needs source maps uploaded, and obfuscated Flutter builds need their debug symbols. Test a forced crash in a release build, not a debug build, before you trust the setup.
Last updated