Debugging Production Expo Crashes with Sentry

Key facts, with sources

• 71% of State of React Native 2024 respondents reported using Expo's EAS Build, ahead of manual builds with Xcode (59.7%) and Android Studio (54.5%). (InfoQ)
• Expo SDK 52, released November 12, 2024, enabled the New Architecture by default for all new projects, and Expo Go for SDK 52 and higher supports only the New Architecture. (Expo Changelog)
• The official React Native documentation now recommends starting new apps with a framework, naming Expo, rather than initializing a bare project. (React Native documentation)
• EAS build caching can speed up subsequent Android and iOS builds by up to 30% and is available to all users at no additional cost as of the SDK 57 cycle. (Expo Changelog)
• Doctolib runs Expo tooling without EAS to scale developer experience on a healthcare app serving 90 million users, showing Expo's open-source tools work independently of its paid cloud services. (Doctolib Engineering (Medium))

Why production Expo crashes are opaque by default

Production JS bundles are minified, and under Hermes your stack traces reference compiled bytecode positions rather than your source. Without source maps uploaded and matched to the exact bundle, a fatal error renders as a single mangled frame — useless for diagnosis. Native crashes are worse: they never reach the JS layer at all, so a JS-only error handler misses them entirely, and to you they look like users silently churning.

This is why I treat crash reporting as launch-blocking infrastructure, not post-launch polish. The first week after launch is exactly when you have the most unknown crash surface and the least tolerance for flying blind. Setting up symbolication after a bad release means the crashes that hurt you most are the ones you'll never decode.

Install and initialize

The current path is the official @sentry/react-native SDK, which supports Expo directly — the older sentry-expo wrapper is deprecated. Install it, add the config plugin to app config, and initialize as early as possible in the app lifecycle: for expo-router apps that means the root layout, wrapped with Sentry's helper so render errors during startup are captured too.

Initialize outside any component and before navigation mounts. A surprising number of missed crashes trace back to Sentry initializing after the code that crashed.

import * as Sentry from '@sentry/react-native';
import * as Updates from 'expo-updates';

Sentry.init({
  dsn: process.env.EXPO_PUBLIC_SENTRY_DSN,
  tracesSampleRate: 0.1,
  environment: __DEV__ ? 'development' : 'production',
});

Sentry.setTag('updateId', Updates.updateId ?? 'embedded');
Sentry.setTag('updateChannel', Updates.channel ?? 'none');

// Root component (e.g. expo-router root layout):
export default Sentry.wrap(App);

Source maps: the step that makes traces readable

The config plugin integrates source map upload into the build, and it needs credentials: your Sentry org, project, and an auth token. The token must not live in source control — put it in EAS secrets so cloud builds can upload symbols, and in local env for local release builds. Once wired, every EAS build uploads the artifacts Sentry needs to symbolicate that binary's crashes automatically.

The recurring failure mode is partial setup: builds work, crashes arrive, but traces stay minified because the token was missing in CI and the upload silently didn't happen. After your first release build, force a test crash and confirm you see your actual file names and line numbers before trusting the pipeline.

{
  "expo": {
    "plugins": [
      [
        "@sentry/react-native/expo",
        {
          "organization": "your-org",
          "project": "your-mobile-app"
        }
      ]
    ]
  }
}

Correlating crashes with OTA updates

EAS Update changes the debugging question from 'which app version crashed' to 'which JS bundle crashed' — one binary version can be running several different bundles across your fleet. That's what the update tags in the init snippet solve: with the update ID and channel attached to every event, you can filter Sentry by a specific OTA release and see immediately whether a crash spike started with an update you shipped an hour ago.

This turns OTA incident response into a tight loop: spike appears filtered to the new update ID, you run a channel rollback, and you watch the spike die out as clients revert. Without the tags you're correlating timestamps and guessing. For any app using OTA updates seriously, I consider this correlation mandatory, not optional telemetry.

Triage habits that make the data useful

Collection is half the job; the other half is a feed someone actually reads. Breadcrumbs — navigation events, network requests, taps — come largely free with the SDK and routinely matter more than the stack trace, because they tell you what the user did to get there. I add manual breadcrumbs around payment, sync, and other flows where post-incident forensics are likely. Set explicit user context (an ID, not PII) so you can answer 'is this one broken device or everyone' at a glance.

Know the gaps, too: crashes before Sentry initializes, OS-level kills like out-of-memory terminations, and some startup native failures may not appear, so App Store Connect and Play Console crash data remain worth a periodic cross-check. My working ritual is simple — after every release, binary or OTA, watch fresh issues for a day, and treat any new crash signature above a trickle as a rollback trigger rather than a ticket for next sprint.

When to hire senior help

Senior help pays off when deciding between managed and prebuild workflows, setting up EAS-based CI/CD and OTA update channels, or untangling a project that was ejected prematurely. An experienced Expo engineer can usually configure build, submit, and update pipelines in days, a task that costs first-time teams weeks of trial and error. If your stack includes React Native + Python + AI, a senior engineer who owns the full product beats coordinating multiple juniors.

Bottom line

Dhairya Senjaliya ships Mobile — Expo Development projects worldwide — book a scoping call to discuss your specific situation.

Common pitfalls to avoid

• ✕Ejecting to the bare workflow at the first native requirement instead of using config plugins and development builds, permanently giving up managed upgrades
• ✕Testing only in Expo Go and misconfiguring runtime versions for expo-updates, so an OTA update ships JavaScript that crashes against mismatched native binaries
• ✕Burning EAS build minutes on every commit in CI without caching or local builds, turning a convenience service into a surprise line item
• ✕Skipping several SDK upgrades in a row, then being forced into a large breaking migration when app store target API level deadlines arrive

Frequently asked questions

Sources

• InfoQ
• Expo Changelog
• React Native documentation
• Expo Changelog
• Doctolib Engineering (Medium)