Table of Contents
- 1. The 3 Types of React Native Crashes You Need to Catch
- 2. Why React Native Crashes Are Invisible in Production
- 3. Setting Up Logtrics in Your React Native App
- 4. Source Maps: Making Production Stack Traces Readable
- 5. Capturing Native Crashes (iOS & Android)
- 6. AI Root Cause Analysis for React Native
- 7. Real-Time Crash Alerts & Notifications
- 8. Best Practices for RN Crash Reporting
- 9. FAQ
1. The 3 Types of React Native Crashes You Need to Catch
React Native's hybrid architecture means crashes come from three distinct surfaces, each requiring different capture strategies:
1. JavaScript Thread Exceptions
Unhandled errors thrown in your React components, reducers, saga middleware, or any JS business logic. In development, these show the red error screen. In production, the app silently crashes or shows a blank screen. Captured via ErrorUtils.setGlobalHandler.
2. Unhandled Promise Rejections
Async operations (fetch calls, database queries, async/await functions) that reject without a .catch(). These are a leading cause of "mysterious" production crashes. Captured via the unhandledRejection event listener.
3. Native Layer Crashes (iOS & Android)
Hard crashes in the native iOS/Android layer — memory violations, native module bugs, OOM errors. These bypass the JS thread entirely and require native crash reporters (PLCrashReporter on iOS, Breakpad on Android). Logtrics installs these automatically.
2. Why React Native Crashes Are Invisible in Production
During development, React Native wraps errors in a big red screen with a full stack trace. This completely hides from you what production users actually experience:
Development Mode
- → Red screen shows full stack trace
- → Source maps enabled by default
- → Error overlay blocks further use
- → Logs stream to Metro console
Production Mode
- → App crashes silently or freezes
- → Minified JS — no readable traces
- → User sees blank screen or restart
- → Zero visibility without a reporter
This is the production blind spot. A user on a specific Android device running your app version 2.3.1 hits a crash — and you have no idea it's happening. Without crash reporting, your only signal is a 1-star App Store review.
3. Setting Up Logtrics in Your React Native App
Installation is a single command. Logtrics automatically links native modules on iOS and Android:
# Install the SDK
npm install @logtrics/react-native
# iOS: install native pods
cd ios && pod install && cd ..
# Android: auto-linked via Gradle
Initialize Logtrics at the very top of your index.js or App.js — before any other imports:
import { AppRegistry } from 'react-native';
import Logtrics from '@logtrics/react-native';
import App from './App';
import { name as appName } from './app.json';
// Initialize BEFORE AppRegistry.registerComponent
Logtrics.init({
apiKey: 'your-api-key',
appVersion: '2.4.0',
environment: 'production',
enableNativeCrashReporting: true, // iOS + Android native
captureUnhandledRejections: true, // Promise rejections
});
AppRegistry.registerComponent(appName, () => App);
Wrap your root component in the Logtrics error boundary to catch React rendering errors:
import { LogtricsErrorBoundary } from '@logtrics/react-native';
export default function App() {
return (
<LogtricsErrorBoundary
fallback={<ErrorScreen />}
>
<NavigationContainer>
{/* your app */}
</NavigationContainer>
</LogtricsErrorBoundary>
);
}
That's it for basic setup. Logtrics now captures all 3 crash types automatically. Source map upload is the next critical step for readable traces.
4. Source Maps: Making Production Stack Traces Readable
Without source maps, a React Native production crash looks like this:
// Minified — unreadable
at t (index.android.bundle:1:233441)
at r (index.android.bundle:1:189234)
at Object.n (index.android.bundle:1:44872)
With source maps uploaded to Logtrics, the same crash becomes:
// Symbolicated — readable
at PaymentScreen.handleSubmit (src/screens/PaymentScreen.js:87:12)
at processApiResponse (src/api/payments.js:43:5)
at Object.call (src/store/sagas/checkoutSaga.js:112:8)
# Generate source map during bundle
react-native bundle \
--platform android \
--dev false \
--entry-file index.js \
--bundle-output android/app/src/main/assets/index.android.bundle \
--sourcemap-output android/app/build/sourcemaps/index.android.map
# Upload to Logtrics
npx logtrics-cli upload-sourcemap \
--api-key your-api-key \
--platform android \
--app-version 2.4.0 \
--sourcemap android/app/build/sourcemaps/index.android.map
Tip: Add source map upload to your CI/CD pipeline (GitHub Actions, Fastlane, Bitrise) so it runs automatically on every release build. Never deploy without uploading maps first.
5. Capturing Native Crashes (iOS & Android)
When enableNativeCrashReporting: true is set, Logtrics automatically installs native crash handlers. But you can also enrich native crash reports with additional context:
// Set breadcrumbs for native crash context
Logtrics.addBreadcrumb({
category: 'navigation',
message: 'Navigated to CheckoutScreen',
level: 'info',
});
// Set user context
Logtrics.setUser({
id: 'user_abc123',
email: '[email protected]',
plan: 'pro',
});
// Tag crash reports with custom metadata
Logtrics.setTag('feature_flags', 'new_checkout_flow');
Logtrics.setTag('ab_test', 'variant_b');
This context is attached to native crashes, so when an Android OOM occurs, you'll see which user it affected, what A/B variant they were in, and what navigation steps led to the crash.
6. AI Root Cause Analysis for React Native
React Native stack traces — even symbolicated ones — can be complex to interpret, especially with async chains, Redux middleware, and saga effects in the picture. Logtrics AI processes the entire crash event and generates a plain-English root cause summary:
Root cause: A null reference error in CheckoutSaga.js:112 when the payment API returns an empty data.transaction object on network timeout.
Context: Affects users on Android 13 with spotty connections. The saga does not handle the timeout response path — it assumes data.transaction.id always exists.
Suggested fix: Add a null check before accessing data.transaction.id and dispatch a PAYMENT_TIMEOUT action with a user-friendly error message instead of allowing the saga to throw.
Instead of digging through async traces and Redux action logs, you get the fix suggestion in 10 seconds.
7. Real-Time Crash Alerts & Notifications
Logtrics notifies you the moment a new crash type appears in production — before user reviews start rolling in. Configure alerts by crash severity, affected user percentage, or crash rate spike:
Email Alerts
New crash types and regression alerts
Slack / Discord
Instant team notifications on crashes
Webhooks
Custom integrations and PagerDuty
8. Best Practices for RN Crash Reporting
Always upload source maps before releasing
A crash report without source maps is nearly useless. Automate source map upload in your CI pipeline so it can never be skipped. Use APP_VERSION environment variables to keep build version and source map version in sync.
Add breadcrumbs before critical operations
Breadcrumbs are your navigation history before a crash. Add them before API calls, screen transitions, and user actions. When a crash occurs, you'll see exactly what the user did in the 30 seconds before it happened.
Set user context at login, clear it at logout
Call Logtrics.setUser() immediately after successful login. Call Logtrics.clearUser() on logout. This lets you filter crashes by user plan, region, or account type — critical for enterprise support.
Group crashes by root cause, not stack trace
The same underlying bug often produces slightly different stack traces across device models and OS versions. Logtrics uses AI to group crashes by semantic root cause rather than exact stack similarity — so you see 1 crash group instead of 47 variants.
Track crash-free user rate, not just crash count
A single power user hitting a crash 100 times a day looks terrible in crash counts but affects only 1 person. Monitor crash-free users % (target: >99.5%) as your primary SLO for app stability.
9. Frequently Asked Questions
How do I add crash reporting to a React Native app?
Install @logtrics/react-native, call Logtrics.init() at the top of index.js before AppRegistry.registerComponent, and wrap your root with LogtricsErrorBoundary. Run pod install for iOS. Done.
Why does my React Native app crash only in production?
Production builds disable the red error screen and run minified JS. Errors that trigger visible warnings in dev mode (network timeouts, type coercions) surface as hard crashes in production when they hit untested code paths, specific device hardware, or lower-memory Android devices.
What's the difference between JS crashes and native crashes in React Native?
JS crashes occur in your JavaScript/React code and are captured via ErrorUtils. Native crashes occur in the iOS/Android layer (OOM, native module bugs) and require platform-level crash reporters. Logtrics captures both automatically with a single SDK.
How do I read React Native production stack traces?
Upload your JS bundle source map to Logtrics. It automatically symbolicates minified stack traces back to your original source file names and line numbers. Without a source map, traces are unreadable in production.
Start Catching Every React Native Crash
Join 500+ mobile developers using Logtrics to catch, diagnose, and fix React Native crashes before they reach users.