Crash reporting
Crash reporting for an Expo app, compared: Sentry, or none - Expo Go support and what each option installs.
Hey - here's how crash reporting works in ReadyNative.
This category owns the errors you didn't see coming: the one call you make for handled errors, and the app-wide boundary that keeps a render error from turning into a white screen.
@/lib/crash always exists, whichever option you pick: crash.capture(err, ctx) reads the same in both, and crash/none is a no-op that only logs in dev. Calls you write against the shim keep working when you switch options, and a missing DSN never crashes the app - it just means nothing is sent.
Pick Sentry for the reports: JS and native crashes, breadcrumbs, source-mapped stack traces, and an error boundary whose fallback is the app's own ErrorState with Retry. Pick none while you're building alone and nobody else can hit a bug you can't reproduce - it's one command to switch later, and the calls you already wrote keep compiling.
This category is part of ReadyNative Pro.
Options
One option per category - --crash <option> picks it:
bun run setup --crash sentry