[iOS 26] App crashes on startup with TurboModule performVoidMethodInvocation - SIGABRT

[JoffreyTrebot]

Description

Description

React Native app crashes immediately on startup on iOS 26.1, but works perfectly on iOS 18.x. The crash occurs in ObjCTurboModule::performVoidMethodInvocation with a SIGABRT signal.

This appears to be related to the known issue discussed in reactwg/react-native-new-architecture#276, where performVoidMethodInvocation doesn't properly handle NSExceptions thrown by TurboModules.

Expected behavior

App should launch normally, as it does on iOS 18.x.

Actual behavior

App crashes with SIGABRT before reaching JavaScript execution.

Environment

• React Native: 0.81.5
• Expo SDK: 54.0.27
• New Architecture: Enabled (required by react-native-reanimated 4.x)
• iOS versions tested:
• iOS 26.1 (iPhone 17 Pro): ❌ CRASH
• iOS 18.6 (Simulator iPhone 16 Pro): ✅ WORKS
• Xcode: 17C48

Crash Log

Incident Identifier: F20BB16E-E4D2-4192-8527-AE827EF146D2
Hardware Model: iPhone18,1
Process: Krimp [6640]
Version: 1.1.3 (9)
OS Version: iPhone OS 26.1 (23B85)
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Termination Reason: SIGNAL 6 Abort trap: 6
Triggered by Thread: 7
Thread 7 Crashed:
0 libsystem_kernel.dylib pthread_kill + 8
1 libsystem_pthread.dylib pthread_kill + 268 (pthread.c:1721)
2 libsystem_c.dylib abort + 124 (abort.c:122)
3 libc++abi.dylib abort_message + 132 (abort_message.cpp:66)
4 libc++abi.dylib demangling_terminate_handler() + 280 (cxa_default_handlers.cpp:71)
5 libobjc.A.dylib objc_terminate() + 172 (objc-exception.mm:499)
6 libc++abi.dylib std::terminate(void ()()) + 16 (cxa_handlers.cpp:59)
7 libc++abi.dylib cxa_rethrow + 188 (cxa_exception.cpp:658)
8 libobjc.A.dylib objc_exception_rethrow + 44 (objc-exception.mm:399)
9 React invocation function for block in facebook::react::ObjCTurboModule::performVoidMethodInvocation(...) + 192
10 React std::1::_function::func<facebook::react::ObjCTurboModule::performVoidMethodInvocation(...)::$1, ...> + 88
11 libdispatch.dylib dispatch_call_block_and_release + 32 (init.c:1575)
12 libdispatch.dylib dispatch_client_callout + 16 (client_callout.mm:85)
13 libdispatch.dylib dispatch_lane_serial_drain + 740 (queue.c:3991)
14 libdispatch.dylib dispatch_lane_invoke + 388 (queue.c:4082)
15 libdispatch.dylib dispatch_root_queue_drain_deferred_wlh + 292 (queue.c:7265)
16 libdispatch.dylib dispatch_workloop_worker_thread + 692 (queue.c:6859)
17 libsystem_pthread.dylib pthread_wqthread + 292 (pthread.c:2696)
18 libsystem_pthread.dylib start_wqthread + 8

Analysis

The crash signature is identical to the one described in #276:

• Crash in performVoidMethodInvocation
• objc_exception_rethrow → __cxa_rethrow → abort

The fix in PR #50193 addressed performMethodInvocation, but the same issue exists in performVoidMethodInvocation for async void methods.

Key observation: The crash ONLY occurs on iOS 26.x. The same build works perfectly on iOS 18.x, suggesting iOS 26 introduces changes that cause native modules to throw NSExceptions during initialization that weren't thrown before.

Potential Root Cause

In `RCTTurboModule.mm`, when an async void TurboModule method throws an NSException, the code attempts to convert it to a JSError and rethrow it:
c
@try {
 [inv invokeWithTarget:strongModule];
} @catch (NSException *exception) {
 throw convertNSExceptionToJSError(runtime, exception);
}

For void async methods dispatched on a background queue, nothing can catch this rethrown exception, causing the app to terminate.

Workaround Attempted

• Updating packages to latest patch versions: Did not fix
• Removing unused native modules: Did not fix

Additional Context

• First crash log showed SecureStoreModule.searchKeyChain in the stack, but removing expo-secure-store did not fix the issue
• The crash happens very early (~200ms after launch), during TurboModule initialization
• Multiple crash logs available showing the same pattern

Related Issues

• RCTTurboModule.mm problematic crash handling reactwg/react-native-new-architecture#276
• Convert to JSException only NSException from sync methods #50193 - Previous fix for performMethodInvocation

⚠️ IMPORTANT: This is a Release-build only bug. Debug builds work fine.

Steps to reproduce

⚠️ This is a RELEASE-BUILD ONLY bug. Debug builds work fine on iOS 26.1.

To reproduce the crash:

1. Clone https://github.com/JoffreyTrebot/rn-ios26-turbomodule-crash
2. Run npm install
3. Build a Release version:
   • Using EAS: eas build --platform ios --profile production
   • Or using Xcode: Archive with Release configuration
4. Install the Release build on an iOS 26.1 device (via TestFlight or direct install)
5. Launch the app
6. Result: App crashes immediately (~200ms after launch) with SIGABRT in performVoidMethodInvocation

What works (for comparison):

• Debug build (npx expo run:ios) on iOS 26.1 → ✅ Works
• Debug build (npx expo run:ios) on iOS 18.6 → ✅ Works
• Release build on iOS 18.x → ✅ Works
• Release build on iOS 26.1 → ❌ CRASH

Key observation:

The crash ONLY occurs when:

1. Build type = Release (TestFlight/Production)
2. iOS version = 26.x

This suggests the issue is related to Release-mode compiler optimizations interacting with iOS 26's changes to native module/exception handling.

React Native Version

0.81.5

Affected Platforms

Runtime - iOS

Areas

TurboModule - The New Native Module System

Output of npx @react-native-community/cli info

System:
 OS: macOS 26.1
 CPU: (8) x64 Apple M1 Pro
 Memory: 44.41 MB / 32.00 GB
 Shell:
 version: 3.2.57
 path: /bin/bash
Binaries:
 Node:
 version: 20.19.5
 path: /usr/local/bin/node
 Yarn:
 version: 1.22.18
 path: /usr/local/bin/yarn
 npm:
 version: 11.6.4
 path: /usr/local/bin/npm
 Watchman: Not Found
Managers:
 CocoaPods:
 version: 1.16.2
 path: /usr/local/bin/pod
SDKs:
 iOS SDK:
 Platforms:
 - DriverKit 25.1
 - iOS 26.1
 - macOS 26.1
 - tvOS 26.1
 - visionOS 26.1
 - watchOS 26.1
 Android SDK:
 API Levels:
 - "28"
 - "29"
 - "30"
 - "31"
 - "32"
 - "33"
 - "34"
 Build Tools:
 - 28.0.3
 - 29.0.2
 - 30.0.2
 - 34.0.0
 System Images:
 - android-29 | Google Play ARM 64 v8a
 - android-30 | Google APIs Intel x86 Atom
 - android-30 | Google Play ARM 64 v8a
 - android-31 | Google Play ARM 64 v8a
 - android-33 | Google Play ARM 64 v8a
 - android-35 | Google APIs ARM 64 v8a
 - android-VanillaIceCream | Google Play ARM 64 v8a
 Android NDK: Not Found
IDEs:
 Android Studio: Not Found
 Xcode:
 version: 26.1.1/17B100
 path: /usr/bin/xcodebuild
Languages:
 Java:
 version: 17.0.13
 path: /usr/bin/javac
 Ruby:
 version: 2.6.10
 path: /usr/bin/ruby
npmPackages:
 "@react-native-community/cli": Not Found
 react:
 installed: 19.1.0
 wanted: 19.1.0
 react-native:
 installed: 0.81.5
 wanted: 0.81.5
 react-native-macos: Not Found
npmGlobalPackages:
 "*react-native*": Not Found
Android:
 hermesEnabled: Not found
 newArchEnabled: Not found
iOS:
 hermesEnabled: Not found
 newArchEnabled: Not found

info React Native v0.83.0 is now available (your project is running on v0.81.5).
info Changelog: https://github.com/facebook/react-native/releases/tag/v0.83.0
info Diff: https://react-native-community.github.io/upgrade-helper/?from=0.81.5&to=0.83.0
info For more info, check out "https://reactnative.dev/docs/upgrading?os=macos".

Stacktrace or Logs

Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Termination Reason: SIGNAL 6 Abort trap: 6
Triggered by Thread: 7

Thread 7 Crashed:
0 libsystem_kernel.dylib __pthread_kill + 8
1 libsystem_pthread.dylib pthread_kill + 268 (pthread.c:1721)
2 libsystem_c.dylib abort + 124 (abort.c:122)
3 libc++abi.dylib __abort_message + 132 (abort_message.cpp:66)
4 libc++abi.dylib demangling_terminate_handler() + 280 (cxa_default_handlers.cpp:71)
5 libobjc.A.dylib _objc_terminate() + 172 (objc-exception.mm:499)
6 libc++abi.dylib std::__terminate(void (*)()) + 16 (cxa_handlers.cpp:59)
7 libc++abi.dylib __cxa_rethrow + 188 (cxa_exception.cpp:658)
8 libobjc.A.dylib objc_exception_rethrow + 44 (objc-exception.mm:399)
9 React invocation function for block in facebook::react::ObjCTurboModule::performVoidMethodInvocation(facebook::jsi::Runtime&, char const*, NSInvocation*, NSMutableArray*) + 192
10 React std::__1::__function::__func<facebook::react::ObjCTurboModule::performVoidMethodInvocation(...)::$_1, ...> + 88
11 libdispatch.dylib _dispatch_call_block_and_release + 32
12 libdispatch.dylib _dispatch_client_callout + 16
13 libdispatch.dylib _dispatch_lane_serial_drain + 740
14 libdispatch.dylib _dispatch_lane_invoke + 388
15 libdispatch.dylib _dispatch_root_queue_drain_deferred_wlh + 292
16 libdispatch.dylib _dispatch_workloop_worker_thread + 692
17 libsystem_pthread.dylib _pthread_wqthread + 292
18 libsystem_pthread.dylib start_wqthread + 8

Key facts:
- Crash happens ONLY on iOS 26.1
- Same build works perfectly on iOS 18.6
- Crash occurs ~200ms after app launch during TurboModule initialization
- Related to issue discussed in reactwg/react-native-new-architecture#276

MANDATORY Reproducer

https://github.com/JoffreyTrebot/rn-ios26-turbomodule-crash

Screenshots and Videos

No response

[qiichos]

@JoffreyTrebot
I ran into the exact same issue described here and wasted 5 hours...😭
In my case, I was able to get past it by properly configuring environment variables in EAS.

It might not be the same situation as yours, but it could be worth double-checking how env vars are set in your EAS configuration (e.g. eas.json, build profiles, or secrets).

Here’s the official documentation that helped me resolve it:
👉 https://docs.expo.dev/eas/environment-variables/

Hope this helps, and thanks for opening the issue 🙏

[jestjosh]

@JoffreyTrebot I feel your pain, hope this gets fixed soon.

[miinos]

Had the same issue. You may have simply forgotten to upgrade your Node.js version. Since React Native 0.81, Node v20 is the minimum required. Also check your .xcode.env.local file to make sure it points to the correct Node version.

[AdzeB]

Any update on this bug because I am also getting this issue

[AdzeB]

@JoffreyTrebot try to disable react compiler if it's toggled on...

expo/expo#41824

[vineyardbovines]

Anyone figure out a resolution? So far I've tried:

• ❌ Updating Node version to LTS
• ❌ Checking environment variable loading
• ❌ Disabling react compiler

to no avail. @JoffreyTrebot's writeup in the repro is exactly what I've seen.

[ryanwhittaker]

Been running into the same issue as well, reproducing it exactly like Joffrey is.

Node version updated, environment variables configured properly, all up to date. iOS 26.2 still crashing.

Big headache as apple is now testing on 26.2 for app submissions as well. Haven't figured out a solution myself either.

EDIT:
Quick note, I've temporarily fixed my build from this error:

In my specific case even iOS 18 was crashing from the same errors above, where I figured it'd be working fine. This led me to a couple other solutions that I should have tried very early on.

Overall the issue wound up being solved by simply building react native from source within Expo, as seen in this solution:
expo/expo#39233 (comment)

Although this has a solution merged in September, I was running into this issue still to date from SDK 54.

[jeffthompson1971]

I've been chasing this for a week, nothing works. Only thing I can do is push an OTA right after the app is downloaded, any OTA - because the issue as I have found is you just have to have it use jsc and not hermes bytecode, once i push any OTA the crash is gone. some of my analysis:
Technical Details
Why This Matters
React Native apps can use two JavaScript engines:

Hermes - Compiles JavaScript to bytecode for faster startup (default in Expo)
JavaScriptCore (JSC) - Standard JavaScript interpreter (slower startup, more stable)
The Hermes Compiler Bug
The Hermes bytecode compiler on EAS Linux servers had an issue:

Compiled bytecode incorrectly optimized TurboModule calls
Caused random crashes when calling native modules
Only affected EAS builds, not local Mac builds
Didn't affect OTA updates (they use plain JS, not bytecode)
Why Local Builds Worked
Local builds: Hermes compiler runs on macOS → works fine
EAS builds: Hermes compiler runs on Linux → has bug
Architecture difference: Same compiler, different platform, different output
This is why we couldn't reproduce the crash locally even with --configuration Release - the Mac Hermes compiler was fine.

Why OTA Updates Fixed It
TestFlight build: Ships with Hermes bytecode (.hbc files)
OTA update: Ships plain JavaScript (.js files) - no bytecode involved
Result: OTA bypasses the buggy bytecode by delivering source code
This is why the pattern was:

Fresh TestFlight install → crash (using bytecode)
After OTA downloads → no crash (using plain JS)
JSC vs Hermes Trade-offs
JSC (our current fix):

✅ No bytecode compiler bugs
✅ Stable and well-tested
✅ Same behavior across platforms
❌ ~10-15% slower app startup time
❌ Larger bundle size
Hermes (when it works):

✅ Faster app startup (~30-50% improvement)
✅ Smaller bundle size
✅ Better memory usage
❌ Bytecode compiler bugs (like this one)
❌ Platform-dependent compilation
Related Files
apps/kmf-shield/app.json - Contains the fix: "jsEngine": "jsc" on line 7
scripts/eas-deploy.sh - Build script
apps/kmf-shield/eas.json - EAS build configuration
docs/crash-prevention-guide.md - General crash prevention strategies
Lessons Learned
OTA masking crashes doesn't mean the code is fixed - it means OTA uses a different execution path (plain JS vs bytecode)
Hermes bytecode compilation is platform-dependent - Mac vs Linux compilers can produce different results
Test fresh installs thoroughly - Don't rely on OTA to hide problems
Watch for engine-specific issues - Hermes vs JSC can behave differently
Environment variables don't always work - Check the actual build artifacts to verify
Source code can be correct but still crash - Compiler bugs are a thing

[kleverdigital]

Hey! I ran into this exact same issue and fixed it.

The crash happens because iOS 26 requires you to explicitly specify the keychainService parameter when using expo-secure-store.

iOS 26 changed how Keychain access works. Without the explicit keychainService parameter, expo-secure-store throws an NSException during initialization that crashes the app. Adding this parameter tells iOS exactly which keychain service to use.

I used:

const KEYCHAIN_OPTIONS = {
keychainService: 'com.yourcompany.yourapp' // Use your bundle identifier
};

// Then use it in all SecureStore calls:
await SecureStore.setItemAsync('key', 'value', KEYCHAIN_OPTIONS);
await SecureStore.getItemAsync('key', KEYCHAIN_OPTIONS);

[noshitsherlock]

For me the error was threefold, 1: environment variables missing in EAS, 2: Passing in the keychain parameter and last but not least (can also be the original error? Did test them out seperate). Expo provides a scheme for you. In a standalone/TestFlight build, you must define one.

So open app.json and add scheme under expo made it work! 🎉 Example below.

{
"expo": {
"name": "AppName",
"slug": "appname",
"scheme": "appname",
"ios": {
"bundleIdentifier": "com.something.AppName"
}
}
}

[noyyyy]

For me the error was threefold, 1: environment variables missing in EAS, 2: Passing in the keychain parameter and last but not least (can also be the original error? Did test them out seperate). Expo provides a scheme for you. In a standalone/TestFlight build, you must define one.

So open app.json and add scheme under expo made it work! 🎉 Example below.

{ "expo": { "name": "AppName", "slug": "appname", "scheme": "appname", "ios": { "bundleIdentifier": "com.something.AppName" } } }

Although I don't understand the tech details, adding schema works for me. Thanks!

[Faradey27]

Had similar problem, in my case issue was in react-native-fast-image which does not support new architecture, migration to expo-image solved the problem