Sentry catches the crash on its own. The part you have to arrange is a trace you can read.

What does Sentry's React Native SDK actually capture?

More than people assume, and less than the marketing around error tracking suggests. The errors arrive through an integration that hooks React Native's own global handler, ErrorUtils. Two options control it and both default to true, one for unhandled errors and one for unhandled promise rejections. Sentry notes that rejection behaviour varies by JavaScript engine and keeps a separate page for it. Native crash handling is a different switch, also true by default, so a crash in Objective C or Java is reported as well, and a second integration follows an error across that boundary and collects the debug images needed to read the native frames.

Frozen apps are covered separately from crashes, and the platforms do not agree. On Apple platforms app hang tracking is on by default, and the threshold, which Sentry calls the app hang timeout interval, is two seconds. On Android, ANR detection on the JVM side is described as always on by default. The NDK based hang detection is a different feature, off by default, with a timeout of 5000 milliseconds when you enable it. Sessions are on too, because automatic session tracking defaults to true, and that is what produces a crash free rate rather than a raw count of errors.

Breadcrumbs are where this gets interesting for anyone who inherited a codebase. The breadcrumbs integration records console calls by default. It records XHR requests by default, and on mobile it leaves fetch off so the two do not duplicate each other. It records every event sent to Sentry. On mobile the native layer adds touch, navigation and app lifecycle breadcrumbs on top. The practical consequence is worth saying plainly: anything a previous developer left in a console.log, an email address, an order payload, a token, is attached to the next error report that goes out of the app. That is a five minute audit and nobody does it.

The things people worry about are off by default. Sending personal data is false by default, which is what otherwise adds IP address, cookies and user data to events. Screenshots are off. The view hierarchy attachment is off. Capturing failed HTTP requests as errors is off. Performance tracing does nothing at all until you set a traces sample rate or a sampler function, and timing spans for user interactions need both an opt in option and your root component wrapped. So a default install reports crashes. It does not watch your users, and it will not tell you why a screen is slow until you ask it to.

Sentry, default integrations for React Native, read 17 October 2026

Why is the stack trace from a real phone unreadable?

Because on your laptop something else is doing the work. Sentry says symbolication in development is handled directly by the Metro development server, which still has the original code, so nothing has to be uploaded and the problem stays invisible. A release build has no Metro. Expo's documentation says Hermes is its default JavaScript engine, and that an export or an update produces Hermes bytecode bundles along with their source maps. So the trace coming back from a TestFlight tester points into bytecode, and the only thing that can turn it back into your file names is a source map that was uploaded for that exact build.

Sentry's own source map page states the requirement without hedging: to get unminified stack traces for JavaScript code, source maps must be generated and uploaded. It also says the React Native SDK handles that automatically for iOS with Xcode and for Android with Gradle, provided you do not use custom values, and the documented way to get there is its wizard, which configures the build tooling on both platforms. The page gives 5.11.0 as the minimum SDK version for those instructions, which matters if you were handed a project that has been sitting for a year.

Two switches explain most missing maps. One is an environment variable, SENTRY_DISABLE_AUTO_UPLOAD, which turns the upload off and which build pipelines sometimes set to keep builds quiet. The other is the Expo config plugin, whose disable option gets baked into the native projects when prebuild runs, so the setting can be sitting in your app config rather than in any build script. Matching a bundle to its map is handled by debug ids, which is why Sentry has you build the Metro config with its own helper, getSentryExpoConfig: it is what gives bundles and maps the same unique id.

One more thing to know before you upgrade anything. Expo documents that Hermes bytecode can change between versions, so an update built against one runtime is not safe to serve to another, which is what the runtime version field in your app config exists to prevent. That puts your error tracking and your upgrade schedule in the same conversation, because a bump to the framework changes both the bytecode and the maps that read it. Engine and tooling changes of that kind show up in the Expo SDK release notes, which is the only place worth reading them.

Sentry, source maps for React Native, read 17 October 2026

Who has to wire this up in a project you did not type?

You do, and it is an afternoon rather than a project. The package is @sentry/react-native, installed through the Expo installer so the version matches your SDK. Sentry's Expo setup page gives Expo SDK 50 as the floor, and says the older sentry-expo package covers SDK 49 and earlier and is deprecated. That one line saves a lot of confusion, because plenty of guides online still tell you to install sentry-expo, and following them in a current project gets you a package that does not belong there. The wizard handles the rest: dependencies, the Metro config, the init call, and the Xcode and Gradle build steps that do the uploading.

The auth token is what actually breaks on a handover. Sentry documents keeping it in a local environment file that is never committed, and says to add it as an EAS secret instead for EAS builds. Expo's guide says the same thing from its side: set the token in the build environment, marked sensitive, and source maps then upload with no further work. If your traces were readable last month and are minified now, check the token before you touch anything else. It is the piece most likely to have moved when somebody changed the pipeline or left the team.

Over the air updates are the one genuinely manual step, and it is the step everybody misses. Expo's guide has you run the upload yourself after publishing an update, with a command called sentry-expo-upload-sourcemaps pointed at the export directory, and shows the publish and the upload chained into a single command so there is no window in which you forget. The name still carries the old sentry-expo prefix, which is confusing given the package itself is deprecated, but it is what Expo's current guide tells you to run. The guide also gives a snippet that reads the update module and tags every event with the update id, whether the launch came from the embedded bundle, the update group and a debug url. Without those tags you can see that something crashed and have no idea which update was running.

Then decide where this lives permanently. The upload belongs inside whatever produces your release build, which means the question is not technical but organisational: who owns that pipeline now. Settle it before the first external tester, not after, because the builds that crash are the ones already in other people's hands, and the maps for them cannot be produced later. If the next thing on your list is publishing to the App Store, do the Sentry wiring first and submit second.

What does error tracking cost you, in money and in paperwork?

Sentry's pricing page, read on 17 October 2026, lists a free Developer plan for one user with 5k errors and a 30 day lookback, and a Team plan at $29 a month billed monthly, or $26 a month billed annually, for unlimited users with 50k errors and up to a 90 day lookback. Additional events are charged on top. The plan table does not print a period beside those allowances, so treat them as the figures to check against your own usage page rather than as a promise. For a first app the free plan is usually plenty, and the limit that bites first is not the error count but the lookback: on the free plan a crash from two months ago is simply gone.

The paperwork cost is the one people forget. A crash reporter sends data off the device, and both stores make you answer for data collected by code you did not write. That means the App Privacy questions in App Store Connect, where crash data is the usual answer, and the Data safety form in Play Console, where it is crash logs and diagnostics. The defaults are on your side here, since personal data, screenshots and the view hierarchy are all off until you switch them on. The exposure is breadcrumbs, because console calls are recorded by default, so the honest answer to what your app collects depends on what the last person to touch the code was logging.

Set against that, the thing error tracking saves you is the worst cost in mobile, which is a bug you cannot reproduce. A release without crash reporting is one where the only signal is a one star review saying the app closes. Next to the store fees and the build time in what it costs to publish an app, a free Sentry project and an afternoon of wiring is the cheapest line on the page.