[Bug]: Expo 52 + RN 0.76 New Arch: OneSignal TurboModule not registered / push broken (5.4.x); 5.2.x NativeModules works

[arjunofframp]

What happened?

Description

One line summary

Expo SDK 52 + RN 0.76 (New Architecture): TurboModuleRegistry cannot resolve the OneSignal TurboModule in production/TestFlight builds; push and iOS notification settings are unreliable on react-native-onesignal 5.4.x, while 5.2.x (NativeModules) works for push.

Environment

Item	Version
react-native	0.76.x
expo	52.x
expo-dev-client	yes (development builds; not Expo Go)
newArchEnabled	true
onesignal-expo-plugin	2.4.x
react-native-onesignal	5.4.x when failing; 5.2.x as workaround
iOS	TestFlight + local expo run:ios
Build	EAS Build + expo prebuild

Details

Motivation / context

We are following the Expo + OneSignal setup (plugin first in plugins, mode for aps-environment, dev client, clean prebuild). After moving to 5.4.x (TurboModule path per #1675 / 5.4.0), we see:

1. TurboModuleRegistry.getEnforcing('OneSignal') (or get('OneSignal')) — native module not present when the JS bundle evaluates react-native-onesignal, or inconsistent registration across builds.
2. TestFlight / device: JS startup failures that surface as Expo ErrorRecovery.crash() (native stack shows ErrorRecovery.swift → tryRelaunchFromCache → abort), consistent with an uncaught exception during module load (e.g. missing TurboModule).
3. Push: unreliable or absent when on 5.4.x path; iOS Settings → App → Notifications often does not show the expected behavior until push/APNs path is healthy.
4. Workaround: Pinning react-native-onesignal 5.2.x restores NativeModules.OneSignal behavior and push works for us; But, custom events are not available on that line.

We are not claiming a minimal repro inside examples/demo yet — our app is Expo-managed with multiple native plugins (expo-build-properties useFrameworks: static, Firebase, etc.). We suspect interaction between TurboModule codegen registration and our Expo/EAS graph, but we have not found an existing GitHub issue that matches our exact symptoms.

Scope / what we need

• Confirmation whether Expo 52 + RN 0.76 + New Arch + static frameworks + EAS is a supported / tested combination for 5.4.x, or if there are known limitations and recommended Podfile / expo-build-properties / plugin order constraints.
• Guidance on debugging TurboModule registration for OneSignal (codegen pod, RCT_NEW_ARCH_ENABLED, ordering vs other TurboModules) when the binary clearly links OneSignal native SDKs but JS still sees a missing module.
• If useful, we can provide EAS build logs (prebuild + install pods), app.json / app.config plugin list, and a symbolicated crash sample.

Related

• #1675 — New Architecture / TurboModules discussion (closed with 5.4.0 note).
• 5.4.0 release — New Arch + clean rebuild guidance.

---

Checklist (reporter)

• Searched existing issues for Expo, TurboModule, getEnforcing, EAS, New Architecture
• Using development build / EAS (not Expo Go) for native OneSignal

Steps to reproduce?

1. Expo app, SDK 52, RN 0.76, newArchEnabled: true.
2. Add onesignal-expo-plugin (with mode) + react-native-onesignal ^5.4.x.
3. npx expo prebuild --clean → EAS iOS build (or local archive).
4. Install on device / TestFlight, launch app.
5. Observe: crash or broken JS load or OneSignal TurboModule unavailable at runtime; push / Settings behavior wrong.

What did you expect to happen?

Expected behavior

• react-native-onesignal loads without throwing when the native binary includes OneSignal.
• TurboModuleRegistry exposes OneSignal consistently on cold start.
• Push and permission flows match docs on New Architecture.

Actual behavior

• On 5.4.x: TurboModule missing or load-time failure → broken startup / recovery crash / no reliable push.
• On 5.2.x: Legacy bridge path works for push in the same product.

React Native OneSignal SDK version

5.4.3

Which platform(s) are affected?

• iOS
• Android

Relevant log output

Invariant Violation: TurboModuleRegistry.getEnforcing(...): 'OneSignal' could not be found. Verify that a module by this name is registered in the native binary.

Code of Conduct

• I agree to follow this project's Code of Conduct

[fadi-george]

Taking a look but we may need to specify higher RN versions.

[fadi-george]

Thanks for the report. 5.4.x's iOS TurboModule registers via the codegenConfig.ios.modulesProvider field, which was added in React Native 0.79 and is silently ignored on RN 0.76 (Expo SDK 52), so the fix is to upgrade to Expo SDK 53 or 54 (RN 0.79+).

We're also gonna bump the 5.4.x peer dep to >=0.79.0 so this gets caught at install time going forward.

[fadi-george]

Closing, will update the docs soon.