React Native integration guide

Add Bugsnag to your React Native apps to report JavaScript and native errors.

New to Bugsnag? Create an account

Note for Expo users

If you’re using Expo, unless you have ejected your app or are using the bare workflow, see the Expo guide. Otherwise, continue with the React Native guide below.

These docs are for the @bugsnag/react-native package, which supports React Native v0.60 and above.

If you’re using the previous bugsnag-react-native package, we recommend upgrading to the latest release, unless you’re using a version of React Native older than 0.60. Documentation for bugsnag-react-native can be found on our legacy pages.

Installation and configuration

The easiest way to add Bugsnag to your React Native project is to use our CLI (macOS and Linux only). Alternatively you can follow the manual setup guide.

# using npx (recommended)
npx @bugsnag/react-native-cli init
# using npm or yarn (if npx isn't available)
npm install --global @bugsnag/react-native-cli
# or
yarn add global @bugsnag/react-native-cli

# then
bugsnag-react-native-cli init

The CLI will walk you through:

  • Installing Bugsnag package dependencies
  • Adding your API key to the native configuration files
  • Initializing Bugsnag in the JS, Android and iOS parts of your app
  • Updating the build process to send source maps to Bugsnag for symbolicated stack traces

Capturing React render errors

An error boundary component is included which you can use to wrap your application. When render errors happen, they will be reported to Bugsnag along with any React-specific info that was available at the time.

To catch all render errors in your application and show a custom error screen to your users, follow this example:

const ErrorBoundary = Bugsnag.getPlugin('react').createErrorBoundary(React)

export default () =>
  <ErrorBoundary FallbackComponent={ErrorView}>
    <App />
  </ErrorBoundary>

class App extends React.Component {
  // Your main app component
}

class ErrorView extends React.Component {
  // This component will be displayed when an error boundary catches an error
}

When render errors happen, they will be reported to Bugsnag along with any React-specific info that was available at the time.

See React’s documentation on Error Boundaries to find out more.

In the dashboard, you’ll see errors reported with extra debugging info in a “React” tab. For example:

React error information in the the dashboard

Customizing the error boundary

The <ErrorBoundary /> component accepts some additional props:

  • onError() – this allows you to pass in an onError callback which runs only for errors caught by the error boundary.
  • FallbackComponent – by default the error boundary will attempt to re-render the child tree which may result in nothing being rendered at all. If you specify a <FallbackComponent/>, when an error happens Bugsnag will render this instead. This means you can display a user-friendly error state.
  • clearError() – resets the state of the error boundary which will cause a re-render the child tree instead of the <FallbackComponent/>.

If you use either React Navigation or React Native Navigation packages in your app, you can automatically capture your users’ navigation history.

See Navigation libraries for integration instructions.

TypeScript support

Type definitions are provided and will be picked up automatically by the TypeScript compiler when you import @bugsnag/react-native.

Monorepo support

If you’re using @bugsnag/react-native in a monorepo, you’ll need to configure the nodeModulesDir option in your build.gradle of the Android app to tell Bugsnag where your node_modules directory is. No further configuration is required for your iOS project.

Further configuration

Most of Bugsnag’s behavior in a React Native app is configured through the native Bugsnag libraries that are linked to your Android and iOS projects. This ensures that your desired behavior is present from startup and does not change when the JavaScript runtime starts.

Check out the configuration options reference for a list of available options.

Showing full stacktraces

Uploading source maps, Android mappings, and iOS debug symbol maps (dSYMs) enables you to see the original method names, file paths, and line numbers in stacktraces.

If you used npx @bugsnag/react-native-cli init to install and configure Bugsnag, it will have set up your application so that mapping files are uploaded automatically:

If you didn’t run init, or you answered “no” to the uploading mappings prompt, you can use the automate-symbolication command at a later stage:

npx @bugsnag/react-native-cli automate-symbolication

Alternatively, you can follow the manual steps in the showing full stacktraces guide.

If you’re using CodePush, you’ll need to upload maps manually with the @bugsnag/source-maps tool. See our examples for CodePush, or CodePush and Hermes.

Reporting unhandled errors

After completing installation and configuration, unhandled errors and promise rejections in JavaScript, as well as native Android and iOS crashes will be reported automatically and appear on your Bugsnag dashboard.

React Native’s In-app Error screen can interfere with the automatic capture of unhandled native crashes. If you want to send these unhandled errors to Bugsnag in the course of development, we recommend running your app in release mode.

Reporting out-of-memory terminations

On iOS platforms, Bugsnag automatically detects terminations of your app caused by the operating system due to high memory usage.

Out of Memory (OOM) detection is enabled by default as part of the installation and configuration steps. If you wish to disable it, see the enabledErrorTypes iOS configuration option.

OOMs are sent to your Bugsnag dashboard when the app next launches. They will not be reported when the debugger is attached.

Reporting ANRs and fatal app hangs

When your app fails to respond to interactions in real time it causes user frustration and can lead them to abandon your app altogether.

Android

When the main thread of an Android app is blocked for too long, it appears unresponsive and the Android OS creates an Application Not Responding (ANR) error, presenting the user with a dialog option to force quit the app.

ANR detection is enabled by default as part of the installation and configuration steps. If you wish to disable it, see the enabledErrorTypes Android configuration option.

iOS

When the main thread of an iOS app is unresponsive for a period of time it will appear to have frozen and may be terminated by the system watchdog as described in Apple’s documentation.

Detection of these “fatal” app hangs are enabled by default as part of the installation and configuration steps. If you wish to disable it, see the enabledErrorTypes iOS configuration option. You can also report non-fatal app hangs (i.e. hangs that did not result in the app being killed) by configuring a minimum threshold hang duration.

See the Reporting app hangs guide for more information.

Reporting handled errors

Sometimes it is useful to manually notify Bugsnag of a problem. To do this, call Bugsnag.notify(). For example:

try {
  something.risky()
} catch (e) {
  Bugsnag.notify(e)
}

When reporting handled errors, it’s often helpful to send custom diagnostic data or to adjust the severity of particular errors. You can also report native errors from your iOS and Android projects.

For more information, see reporting handled errors.

Sending diagnostic data

Automatically captured diagnostics

Bugsnag will automatically capture and attach the following diagnostic data:

  • Full stack traces for all threads.
  • App state including running time and time in foreground.
  • Build information including name, version/build and release stage.
  • Device specification including model, OS version and total memory.
  • System state including orientation, free memory, available disk space and battery level.

For more information see Automatically captured data.

Attaching custom diagnostics

It can often be helpful to attach application-specific diagnostic data to error reports. This can be accomplished by setting a callback which will be invoked before any reports are sent to Bugsnag.

The following adds a map of data to the “company” tab on the Bugsnag dashboard for all captured events:

Bugsnag.start({
  onError: function (event) {
    event.addMetadata('company', {
      name: "Acme Co.",
      country: "uk"
    })
  }
})

You can also attach metadata that comes from native code in your iOS and Android projects using the addMetadata functions on the native Bugsnag client.

For more information, see Customizing error reports.

Identifying users

In order to correlate errors with customer reports, or to see a list of users who experienced each error, it is helpful to capture and display user information on your Bugsnag dashboard.

You can set the user information of an error report using the user configuration property when Bugsnag starts or via an onError callback.

Bugsnag.start({
  onError: function (event) {
    event.setUser('3', 'bugs.nag@bugsnag.com', 'Bugs Nag')
  }
})

If your user data is located in native code, you can also set this information using the setUser function on the native Bugsnag client.

For more information, see Adding user data.

Logging breadcrumbs

In order to understand what happened in your application before each crash, it can be helpful to leave short log statements that we call breadcrumbs. A configurable number of breadcrumbs are attached to each error report to help diagnose what events led to the error.

Automatically captured breadcrumbs

By default, Bugsnag captures common events including:

  • Low memory warnings
  • Device rotation
  • Menu presentation
  • Screenshot capture (not the screenshot itself)
  • Undo and redo
  • Table view selection
  • Window visibility changes
  • Non-fatal errors
  • Log messages
  • User navigation (when enabled through our navigation plugins)

Attaching custom breadcrumbs

You can use the leaveBreadcrumb method to log potentially useful events in your own applications:

Bugsnag.leaveBreadcrumb('Button clicked')

Bugsnag will keep track of the time and order of the breadcrumbs and show them on your dashboard. Additional data can also be attached to breadcrumbs by providing the optional metadata parameter.

You can leave breadcrumbs in your iOS and Android projects too using the leaveBreadcrumb function on the native Bugsnag client.

For more information and examples for how custom breadcrumbs can be integrated, see Customizing breadcrumbs.

Session tracking

Bugsnag tracks the number of “sessions” that happen within your application. This allows you to compare stability scores between releases and helps you to understand the quality of your releases.

Sessions are captured and reported by default. This behavior can be disabled using the autoTrackSessions configuration option.

Bugsnag will automatically report a session each time the app is launched or enters the foreground for the first time in 30 seconds.

For more information about controlling session tracking, see Capturing sessions.

Identifying crashes at launch

By default Bugsnag will identify crashes that occur whilst your app is launching, allowing you to prioritize fixing high-impact launch crashes.

Additionally you can use Bugsnag to detect recurrent launch crashes: allowing you to take evasive action in your app, such as resetting data or turning off application features.

Follow the Identifying crashes at launch guide for Android and iOS to configure this functionality.

Next steps