feat: [SDK-4157] add React Native New Architecture support (TurboModules)

[fadi-george]

Description

One Line Summary

Migrate the SDK to React Native's New Architecture using TurboModules, Fabric, and Bridgeless Mode, dropping legacy Bridge support.

Details

Motivation

React Native 0.76+ enables the New Architecture by default. The SDK needed native TurboModule support to work correctly with apps using TurboModules, Fabric renderer, and Bridgeless Mode. This is tracked in #1675 and SDK-4157.

Implementation follows the official Turbo Native Modules guide from the React Native working group, including the event emitter pattern using CodegenTypes.EventEmitter.

Scope

This is a breaking change (v6.0.0). The minimum React Native version is now 0.76.0.

What changed:

• Added NativeOneSignal.ts TurboModule spec with codegen configuration
• Android: RNOneSignal.java extends codegen-generated NativeOneSignalSpec, package registration uses BaseReactPackage
• iOS: Renamed .m to .mm, module extends NativeOneSignalSpecBase, implements getTurboModule: for JSI registration
• Event system migrated from NativeEventEmitter to CodegenTypes.EventEmitter with direct onXxx subscriptions
• Removed all #ifdef RCT_NEW_ARCH_ENABLED conditionals (legacy arch no longer supported)
• Removed 4 deprecated sync methods (getPushSubscriptionId, getPushSubscriptionToken, getOptedIn, hasPermission)
• Public API methods (addTags, addAliases, addTriggers) now use Record<string, string> types
• Removed runtime type coercion/validation (TypeScript enforces at compile time)
• Hot reload cleanup via globalThis to prevent duplicate event subscriptions

What is not affected:

• All existing public API method signatures remain the same (except removed deprecated methods)
• Native SDK versions are unchanged
• Push notification delivery, IAM, outcomes, sessions behavior unchanged

Testing

Unit testing

All 246 unit tests pass. Tests updated to mock TurboModuleRegistry and codegen-generated event emitters instead of NativeModules and NativeEventEmitter.

Manual testing

Tested on iOS simulator and Android emulator with the demo app covering initialization, push permission, notifications (foreground/background/click), login/logout, tags, aliases, email/SMS, IAM triggers, outcomes, and event observers.

cd into examples/demo and run either bun run ios or bun run android.

Affected code checklist

• Notifications
  • Display
  • Open
  • Push Processing
  • Confirm Deliveries
• Outcomes
• Sessions
• In-App Messaging
• REST API requests
• Public API changes

Checklist

Overview

• I have filled out all REQUIRED sections above
• PR does one thing
• Any Public API changes are explained in the PR details and conform to existing APIs

Testing

• I have included test coverage for these changes, or explained why they are not needed
• All automated tests pass, or I explained why that is not possible
• I have personally tested this on my device, or explained why that is not possible

Final pass

• Code is as readable as possible.
• I have reviewed this PR myself, ensuring it meets each checklist item

---

This change is 

[abdulraqeeb33]

@fadi-george how sure are we that this works well for us? with the entire architecture update
would it support older devices?
would it be a breaking change?
Do we have to upgrade libraries to accommodate this change?

[fadi-george]

@fadi-george how sure are we that this works well for us? with the entire architecture update would it support older devices? would it be a breaking change? Do we have to upgrade libraries to accommodate this change?

Device support would be depedent on the Android SDK so still Android 6.0+ (API 24).

[burghausen8]

@fadi-george Quão seguros estamos de que isso funcionará bem para nós? Com ​​a atualização completa da arquitetura, haverá suporte para dispositivos mais antigos? Será uma alteração que quebrará a compatibilidade? Precisaremos atualizar as bibliotecas para acomodar essa mudança?

@fadi-george how sure are we that this works well for us? with the entire architecture update would it support older devices? would it be a breaking change? Do we have to upgrade libraries to accommodate this change?

We encountered an issue in our app related to the OneSignal integration. We were previously using version ^5.2.2, and after generating a new build, the app started crashing with the following error:

TypeError: this.RNOneSignal.onPermissionChanged is not a function (it is undefined), js engine: hermes

To resolve the issue, we had to pin the dependency to version 5.3.6, which restored the expected behavior.

[fadi-george]

@fadi-george Quão seguros estamos de que isso funcionará bem para nós? Com ​​a atualização completa da arquitetura, haverá suporte para dispositivos mais antigos? Será uma alteração que quebrará a compatibilidade? Precisaremos atualizar as bibliotecas para acomodar essa mudança?

@fadi-george how sure are we that this works well for us? with the entire architecture update would it support older devices? would it be a breaking change? Do we have to upgrade libraries to accommodate this change?

We encountered an issue in our app related to the OneSignal integration. We were previously using version ^5.2.2, and after generating a new build, the app started crashing with the following error:

TypeError: this.RNOneSignal.onPermissionChanged is not a function (it is undefined), js engine: hermes

To resolve the issue, we had to pin the dependency to version 5.3.6, which restored the expected behavior.

@burghausen8 Im looking into this old arch issue but if you use new arch, it should be fine.