feat!: support new React Native architecture

[jokerttu]

Starting with React Native version 0.76, the New Architecture is enabled by default, introducing significant changes to the framework's internals. This PR updates the package to support the New Architecture and drops support for the legacy architecture.

Resolves #338

FEATURES:

• New React Native Architecture Support
  • Adds support for the new React Native architecture.
  • Uses codegen to generate the native interop layer for TurboModules and Fabric views.
• Navigation SDK Upgrades
  • Android: upgraded from 7.1.0 to 7.3.0
  • iOS: upgraded from 10.6.0 to 10.7.0

BREAKING CHANGES:

• Legacy Architecture Removed
  • Removes support for the legacy React Native architecture.
• API changes:
  • View Event Handlers as Props: Instead of using mapViewCallbacks and navigationViewCallbacks wrapper objects, event handlers are now passed directly as first-class view props.
  • View Flags as Props: View flags have been moved from viewControllers to view props. For example, the headerEnabled state can now be managed directly via a view prop, instead of calling navigationViewController.setHeaderEnabled(value).
  • Migrate from configuring listeners via one combined setter call to setting each listener via its own dedicated setter.
  • Updated the minimum Kotlin version to 2.2.10. Our recommended Android Gradle Plugin (AGP) is now 8.10.0 and Gradle is now 8.11.1.
  • Support for React Native versions below 0.79.x are dropped.

CHORE CHANGES:

• Converts Android example app code to Kotlin.
• Adds a code formatter for Kotlin files (used in the example app).
• Updates the README to document New Architecture support.
• Adds MIGRATING.md documentation file for migration process.

Support Checklist (WIP)

• Supports React Native 0.83.x
• Supports React Native 0.82.x
• Supports React Native 0.81.x
• Supports React Native 0.80.x
• Supports React Native 0.79.x
• Android Auto supports
• CarPlay supports
• Works with Expo framework

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I signed the CLA.
• I listed at least one issue that this PR fixes in the description above.
• I updated/added relevant documentation
• I added new tests to check the change I am making
• All existing and new tests are passing.

[lyonscrawl]

Hello @jokerttu, I'm wondering if this MR is still in progress, as it has been submitted for approval for about a month?

[jokerttu]

Hello @jokerttu, I'm wondering if this MR is still in progress, as it has been submitted for approval for about a month?

Yes, the process is still ongoing.
The new architecture has been implemented and is working in the example app. However, we are still in the middle of resolving issues with CarPlay support, particularly with multi-scene applications. Related issue: facebook/react-native#46184

[kylemassimilian]

Excited for new arch support. Thank you for working on this - It will help our team resolve compatibility issues quickly.

[petemusicpancake]

Any news on this? Maybe any planned dates for the release?

[eliabruni]

Hello, any news on this? Do you guys have plan to merge it at some point or it's not a priority? Thanks!

[jokerttu]

@eliabruni
This PR is soon to be replaced with refactored/updated version of the new architecture support.

[ArturoSalazarB16]

Hey Joonas! Reviewing this as-is is a bit challenging as there's different changes involved. Is it possible to split out PR's individually per change type? or at least have individual commits per change?

[illuminati1911]

LGTM. Make sure to test that the Android Auto and especially CarPlay still works on the new architecture. I remember there was some issues before with CarPlay.

[jokerttu]

@ArturoSalazarB16
I completely understand the challenge with reviewing this PR as a single large commit (as this is quite a big change)
Reasoning behind this single commit structure:

• Rebasing complications - We initially had some smaller improvements (like support for custom IDs for map objects) in separate commits. However, when rebasing the new architecture branch onto the latest main branch changes, which we have done multiple times, the merge conflicts became nearly impossible to resolve cleanly without an unreasonable amount of work. We ended up squashing everything to make the rebase manageable.
• New Architecture is inherently a large, cross-cutting change; The migration touches virtually every aspect of the application logic (native modules -> turbo modules, view managers -> fabric views, obj-c -> obj-cpp, event handling, etc.). Implementing features "the old way" first and then fixing them in separate commits would have resulted in intermediate commits that don't work at all, or a lot of unnecessary logic conversion work, which isn't helpful for review (or git history).
• Happy to split where it makes sense - I can extract some isolated changes into separate commits (e.g., formatting script updates, specific new features), but these would be relatively small compared to the core architecture changes. The fundamental nature of the New Architecture migration means the bulk of the changes are tightly coupled.

Also, would it be easier to review this by filtering out certain file types and checking them one by one? You can use GitHub's file filter in the "Files changed" tab to focus on specific extensions (e.g., .kt, .swift, .ts).

[jokerttu]

@illuminati1911

LGTM. Make sure to test that the Android Auto and especially CarPlay still works on the new architecture. I remember there was some issues before with CarPlay.

Used a lot of time to improve Carplay and Android Auto support for this PR, and both works just fine! 🎉