add support for new architecture

[jasonpraful]

Changes

Adds support for React native's new architecture with Backwards compatibility.

New Architecture

• Android: Split native module into newarch and oldarch with conditional compilation based on the newArchEnabled flag.
• iOS: Added conditional compilation using RCT_NEW_ARCH_ENABLED macro to switch between TurboModule and Bridge implementation.
• JS: Added NativeIntercomSpec.ts

Usage

No changes for existing users on old architecture. Enable new architecture with:

• Android: Set newArchEnabled=true in gradle.properties.
• iOS: RCT_NEW_ARCH_ENABLED=1 pod install

Testing

• Create new expo/react native app.
• Use a local registry (like verdaccio) to build and publish package locally
• Install package in new app.
• Follow instructions in README for SDK setup.

Other minor changes

• Upgraded repo to Node 22.14
• Migrated to yarn 3.6.1
• Added proper ESM and CJS dual package exports config.

Next Steps

A follow-up PR will be raised which adds an Expo example app with the new architecture.

References

• https://github.com/reactwg/react-native-new-architecture
• https://github.com/reactwg/react-native-new-architecture/blob/main/docs/backwards-compat-turbo-modules.md

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	npm/​@​react-native/​gradle-plugin@​0.74.0 ⏵ 0.81.1			+1
	npm/​metro-cache-key@​0.79.1 ⏵ 0.83.1			-2
	npm/​aggregate-error@​4.0.1
	npm/​indent-string@​5.0.0
	npm/​metro-minify-terser@​0.79.1 ⏵ 0.83.1			-1
	npm/​unique-slug@​5.0.0
	npm/​metro-babel-transformer@​0.79.1 ⏵ 0.83.1
	npm/​ob1@​0.79.1 ⏵ 0.83.1			-1
	npm/​unique-filename@​4.0.0
	npm/​is-plain-obj@​1.1.0
	npm/​@​babel/​plugin-transform-strict-mode@​7.27.1
	npm/​arrify@​1.0.1
	npm/​chownr@​3.0.0
	npm/​metro-transform-worker@​0.79.1 ⏵ 0.83.1			+1
	npm/​metro-cache@​0.79.1 ⏵ 0.83.1			+1
	npm/​metro-runtime@​0.79.1 ⏵ 0.83.1
	npm/​min-indent@​1.0.1
	npm/​metro-transform-plugins@​0.79.1 ⏵ 0.83.1
	npm/​metro-symbolicate@​0.79.1 ⏵ 0.83.1
	npm/​@​types/​minimist@​1.2.5
	npm/​metro-config@​0.79.1 ⏵ 0.83.1
	npm/​is-path-cwd@​3.0.0
	npm/​abbrev@​3.0.1
	npm/​@​ark/​util@​0.47.0
	npm/​metro-resolver@​0.79.1 ⏵ 0.83.1
	npm/​metro-source-map@​0.79.1 ⏵ 0.83.1
	npm/​@​react-native/​assets-registry@​0.74.0 ⏵ 0.81.1			+1
	npm/​@​react-native/​babel-plugin-codegen@​0.74.89 ⏵ 0.81.0			+1
	npm/​hermes-estree@​0.15.0 ⏵ 0.29.1			+3
	npm/​@​types/​semver@​7.7.1 ⏵ 7.7.0	+1
	npm/​undici-types@​7.10.0
	npm/​scheduler@​0.26.0
	npm/​@​react-native/​normalize-colors@​0.74.1 ⏵ 0.81.1			+1
See 66 more rows in the dashboard

View full report

[socket-security]

Warning

Review the following alerts detected in dependencies.

According to your organization's Security Policy, it is recommended to resolve "Warn" alerts. Learn more about Socket for GitHub.

Action	Severity	Alert  (click "▶" to expand/collapse)
Warn		npm/glob@7.1.6 has a License Policy Violation. License: CC-BY-SA-4.0 (package/LICENSE) From: yarn.lock → npm/glob@7.1.6 ℹ Read more on: This package | This alert | What is a license policy violation? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: Find a package that does not violate your license policy or adjust your policy to allow this package's license. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/glob@7.1.6. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.

View full report

[uddish]

@jasonpraful
Were you able to test push notifications and deeplinks in the new architecture?

[brianpburns]

Nice job man! Some good cleanup outside of the arch update as well.

I think completely splitting the new and old architecture versus the inheritance approach I was testing is a much better call. It'll be much easier to deal with going forward.

I see you tackled the event listener updates in a separate PR as well. I figured that would be a breaking change.

I imagine you're going with the opt-in flow for now and it'll likely be an opt-out flow once stable?

[jasonpraful]

I imagine you're going with the opt-in flow for now and it'll likely be an opt-out flow once stable?
Yep, once users have adapted and the consumers from old architecture drops we will remove support for it entirely.