App crashes immediately at launch

[revh]

Bug Description

App crashes immediately at launch (before splashscreen appears) with a segmentation fault in hermesvm's garbage collector.

Environment

• App: [APP_NAME]
• Version: [APP_VERSION]
• Build: TestFlight
• Device: iPhone15,4
• OS: iPhone OS 26.3.1 (User build, not beta)
• Build Tools: AppStoreTools 17E187
• Hermes git revision: N/A
• React Native version: expo 55.0.18, React native 0.83.2
• Platform: arm64-v8a (iPhone)

Steps To Reproduce

1. Use a device without a SIM card (eSim removed)
2. Connect to WiFi
3. Launch the app
4. App crashes immediately

code example:

N/A

Expected Behavior

App should launch normally and display the splashscreen even without a SIM card present.

Additional Notes

• App was working fine previously on this device (iPhone 15)
• The exactly same app/build is working fine on the new device (iPhone 17e)
• This iPhone was previously used for testing but I recently switched to the new device
• The app was opened while connected to WiFi (no eSIM present)
• Crash occurred immediately at launch, before the splashscreen could display

Crash Details

crashlog_REDACTED.txt

feedback_REDACTED.txt

Crash Stack Trace

• [?] The issue is reproducible with the latest version of React Native.

[tmikov]

The crash log you provided clearly shows the problem - the Hermes runtime is being incorrectly accessed simultaneously from two threads:

• Thread 8 (libdispatch worker): Allocating a JS object.
• Thread 10 (JS thread): Concurrently executing JS (string concatenation).

The Hermes runtime is single-threaded and does not support concurrent access from multiple threads. This crash is a consequence of that contract being violated.

The crash happens ~0.5s after launch, consistent with initialization-phase failures.

Likely cause

Looking at the Thread 8 call stack, the allocation originates from ObjCTurboModule::performVoidMethodInvocation, which catches an NSException and calls convertNSExceptionToJSError. This creates a JS object on the dispatch queue thread rather than the JS thread. This is our best guess for where the thread-safety violation is introduced, but the actual root cause may be further up the chain — for example, the TurboModule invocation itself may have been dispatched to the wrong queue.

Conclusion

This is not a Hermes bug, but in issue either in RN/expo or the specific TurboModule.

[SimonLuzardo]

Working fix available
I've implemented a PAC fix for Hermes v0.14.1 that resolves this crash on iOS 26 physical devices.
Fix: Modified PointerBase.h to use Apple's ptrauth intrinsics (HERMES_PAC_SIGN_DATA, HERMES_PAC_AUTH_DATA) in basedToPointerNonNull and pointerToBasedNonNull.
Tested: iPhone 17 Pro Max, iOS 26.4, React Native 0.83.4 + Expo SDK 54. Production app running successfully.
Repo: https://github.com/SimonLuzardo/hermes-ios26-pac-fix

[tmikov]

@SimonLuzardo as far as we know, the crash was nor caused by PAC, so there is no need for a "PAC fix".

[alexlencz]

Adding a reproduction report to support this issue.

We are also hitting this crash on physical iOS 26 devices with Expo SDK 55 (React Native 0.83.4,
Hermes V2). We went through an exhaustive debugging process across 21 EAS builds today and can
confirm this is a pure upstream issue.

Key finding: Build 20 — a completely minimal app with only <Stack /> in _layout.tsx,
zero custom code, no third-party services — still crashes on launch with
hermesvm::HadesGC::writeBarrierSlow. No app binary frames appear anywhere in the stack.
This confirms the crash is entirely within Hermes internals and is unreachable by app-level
code changes.

JSC workaround: Confirmed impossible in SDK 55 managed workflow. The jsEngine field is
not valid in the SDK 55 app.json schema.

Android: Unaffected. Same codebase, same SDK 55, zero crashes on Android.

We have a production app blocked from iOS launch. Questions for the Hermes team:

1. Is a fix in progress for PAC compatibility on iOS 26 physical devices?
2. Is there a patched Hermes build or canary we can test against?
3. Is there any workaround at the React Native / Expo layer while a fix is in progress?

Happy to provide full crash logs or test any canary builds. We have a physical iOS 26 device available.

[tmikov]

EVERYONE: READ THE ISSUE BEFORE POSTING! THE EXPLANATION IS HERE:
#1957 (comment)
#1966 (comment)

I am locking this issue because I am tired of this nonsense.