Troubleshooting
When the module is not registered, pods fail, or native crashes are not being captured, start here. This page focuses on the checks that usually explain those problems, especially the difference between debug behavior and release behavior in React Native. It should help you narrow the issue before you open a bug report or start changing working code.
Before you open an issue
- confirm the React Native version
- note the iOS and Android versions you tested
- state whether the problem happens in debug, release, or both
- include exact reproduction steps
- include logs, stack traces, or build errors
Debug vs Release
JavaScript handlers can be tested in development if you enable them. Native crash behavior is a release-mode concern first, because debug tooling can intercept or change the failure path.
Common issues
- module not registered or
TurboModuleRegistry.getEnforcingerrors pod installor native build failures- JavaScript crashes captured but native crashes not captured
- native handler works in debug assumptions but fails in release validation
- another SDK handler no longer runs after registration
Installation issues
CocoaPods could not find the pod
[!] CocoaPods could not find compatible versions for pod "GlobalExceptionHandler"
Try:
sudo gem install cocoapods
cd ios
rm -rf Pods Podfile.lock
pod deintegrate
pod install
cd ..
Then revisit Installation.
Android build dependency failure
Could not determine the dependencies of task ':app:compileDebugJavaWithJavac'
Check your Kotlin version in android/build.gradle, then clean:
buildscript {
ext {
kotlinVersion = "1.8.0"
}
}
cd android
./gradlew clean
./gradlew cleanBuildCache
cd ..
TurboModule is not registered
TurboModuleRegistry.getEnforcing called for module 'GlobalExceptionHandler' but it is not registered
This usually points to a cache or build mismatch in a new architecture project.
- npm
- Yarn
- pnpm
- Bun
npx react-native start --reset-cache
yarn dlx react-native start --reset-cache
pnpm dlx react-native start --reset-cache
bun x react-native start --reset-cache
Then rebuild the native app from scratch:
- npm
- Yarn
- pnpm
- Bun
# iOS
cd ios && rm -rf Pods && pod install && cd ..
npx react-native run-ios
# Android
cd android && ./gradlew clean && cd ..
npx react-native run-android
# iOS
cd ios && rm -rf Pods && pod install && cd ..
yarn dlx react-native run-ios
# Android
cd android && ./gradlew clean && cd ..
npx react-native run-android
# iOS
cd ios && rm -rf Pods && pod install && cd ..
pnpm dlx react-native run-ios
# Android
cd android && ./gradlew clean && cd ..
npx react-native run-android
# iOS
cd ios && rm -rf Pods && pod install && cd ..
bun x react-native run-ios
# Android
cd android && ./gradlew clean && cd ..
npx react-native run-android
If your project uses TurboModules, the cache reset and clean rebuild steps above are the first things to retry.
Runtime issues
JavaScript handler does not run in development
Pass true as the second argument:
setJSExceptionHandler((error, isFatal) => {
console.log(error, isFatal);
}, true);
Native handler seems broken in debug mode
Debug builds can interfere with native crash handling. Validate native crash behavior in release builds instead.
- npm
- Yarn
- pnpm
- Bun
npx react-native run-android --variant=release
yarn dlx react-native run-android --variant=release
pnpm dlx react-native run-android --variant=release
bun x react-native run-android --variant=release
If you test only in debug mode, you can get false negatives for native crash handling.
App does not restart after a crash
Android restart-oriented flows usually need forceAppToQuit: true for predictable cleanup:
setNativeExceptionHandler((errorString) => {
console.log(errorString);
}, {
forceAppToQuit: true,
});
On iOS, programmatic restart is not a supported recovery strategy.
Another SDK handler stopped running
If an analytics SDK or native library already set a native exception handler, enable chaining:
setNativeExceptionHandler((errorString) => {
console.log(errorString);
}, {
forceAppToQuit: true,
callPreviouslyDefinedHandler: true,
});
If the older handler still does not run, verify which library initializes last.
When should forceAppToQuit be false?
Only in advanced cases, such as:
- custom native recovery logic
- navigation-driven recovery flows
- carefully tested Android-specific restart patterns
See Native Crash Handling before changing the default.
Testing issues
simulateNativeCrash does nothing
Check these first:
- You are on iOS or Android, not web.
- You are using a supported crash type.
- You are testing in an environment where native crashes can actually execute.
Use Simulate Native Crash in React Native for the full validation flow.
Two common mistakes:
- calling it only in debug mode and expecting release behavior
- using a crash type that does not make sense for the current platform or test path
Test crash code leaked into production
Guard crash triggers with __DEV__:
import { CrashType, simulateNativeCrash } from 'react-native-global-exception-handler';
if (__DEV__) {
global.triggerNativeCrash = () => {
simulateNativeCrash(CrashType.nsexception);
};
}
Analytics issues
Errors are not reaching Sentry or Crashlytics
- verify the monitoring SDK is initialized first
- keep the exception handler lightweight
- validate both JavaScript and native paths separately
Minimal verification example:
setJSExceptionHandler((error, isFatal) => {
console.log('JS handler fired', error.message, isFatal);
}, true);
setNativeExceptionHandler((errorString) => {
console.log('Native handler fired', errorString);
}, {
forceAppToQuit: true,
});
If the console logs never appear in the expected environment, fix that first before debugging the monitoring provider.
Use the provider guides: