BabylonJS / BabylonReactNative

Build React Native applications with the power of Babylon Native
MIT License
359 stars 57 forks source link

React Native New Architecture #595

Open CedricGuillemet opened 11 months ago

CedricGuillemet commented 11 months ago

Add support for RN new architecture

Forum thread : https://forum.babylonjs.com/t/react-native-new-architecture/42859/6

and links/doc here:

https://forum.babylonjs.com/t/react-native-new-architecture/42859/6?u=cedric

ChaimActionShip commented 5 months ago

Are there any updates on the new architecture?

CedricGuillemet commented 5 months ago

Are there any updates on the new architecture?

No update. This task is still on our radar but no ETA yet.

ryantrem commented 5 months ago

Curious though @ChaimActionShip, why do you ask? Are you wanting to use Babylon in a React Native app that uses the new architecture? I haven’t tried it, but I suspect the legacy module interop would work: https://github.com/reactwg/react-native-new-architecture/discussions/135

Babylon React Native only uses the React Native legacy bridge for initialization. Everything else already use JSI, same as TurboModules. Directly supporting the new architecture would definitely be better, but I wouldn’t expect it to impact performance for Babylon.

matthargett commented 4 months ago

FWIW, we are targeting new architecture and bridgeless mode as the primary configuration for React Native visionOS. Getting BRN working in these scenarios on AOSP-based platforms (Quest, Vive XR, Pico 4) would help slice off the functionality in a more incremental way.

It may make sense to first wait for Saad to finish bringing visionOS support to RNTA, and for Lorenzo to bring RNTA into BRN. Discovering showstoppers earlier would help with planning estimates, but I'm not sure how much more parallelism will be worth the outcome.

RNTA visionOS work here: https://github.com/microsoft/react-native-test-app/pull/1803

ryantrem commented 4 months ago

we are targeting new architecture and bridgeless mode as the primary configuration for React Native visionOS

Can you explain this a bit more? Do you mean for React Native in general when running on VisionOS (e.g. contributions to React Native itself), or are you referring to an app you are developing for VisionOS, or something else? Just want to make sure I understand the context.

matthargett commented 4 months ago

we are targeting new architecture and bridgeless mode as the primary configuration for React Native visionOS

Can you explain this a bit more? Do you mean for React Native in general when running on VisionOS (e.g. contributions to React Native itself), or are you referring to an app you are developing for VisionOS, or something else? Just want to make sure I understand the context.

React Native, in general, and for the Babylon app we are developing and planning to deploy on visionOS. When deciding how to scope our development and testing efforts for React Native on visionOS, we knew we needed to target our implementation and testing efforts to one build configuration, to live within the staffing constraints we have. We looked at what Meta's goals for React Native build configurations were going to be when we were ready to start Babylon integration and shipping out product, versus looking at what React Native was already doing at the start of the project. We felt like we could be more in line with Meta's goals and strategy, be detail-oriented in our feedback about those new architecture features to accelerate maturity and greater adoption, and eliminate user-visible runtime overhead from the 'old' architecture that I was familiar with from my time at BlueJeans and Sony.

As a result, my colleague @okwasniewski found and fixed several bugs in iOS and other platforms that already existed when switching to new architecture. By paying very close attention to RN Tester for other platforms, because we were bootstrapping a new platform, several fixes were done to upstream integration tests that uplifts all the platform. He also went deeper into cocoa pods, CMake, and other toolchain to remove a bunch of non-standard workarounds that tvOS had built up over the years.

So, while some app-building users of React Native visionOS might disable new architecture, and/or "classic" bridge mode, especially if they have a brown-field application repo shipping on other platforms, it's not where we've spent time integration testing to date. This is also not a build configuration that Meta's staffed engineers are triaging as a priority. For developers (and their users by proxy): On the surface, new architecture probably doesn't appear to be a big CPU/memory bandwidth savings, but I'd probably advise any React Native application targeting XR to claw back all the performance and battery life they can up front.

Hopefully that makes the context clearer, let me know if I made it more opaque by accident! :D

ryantrem commented 4 months ago

Thanks for sharing all that context, sounds amazing! If you folks are doing the work the add visionOS support to React Native, and the intent is to make it new architecture + bridgeless mode by default, then it makes sense that you are looking for BRN to also support these modes. My understanding is that it is possible to have an RN package support both legacy and new architecture, and that some packages out there have already done so, but I don't know the details of how to set this up or what is involved. It sounds like you and your colleague's are already making many great contributions to various RN related projects, but would you have the time/interest in taking a stab at adding this support to BRN as well?

matthargett commented 4 months ago

Thanks for sharing all that context, sounds amazing! It sounds like you and your colleague's are already making many great contributions to various RN related projects, but would you have the time/interest in taking a stab at adding this support to BRN as well?

Yes :) I communicated the intent with @bghgary et al on a group call in August 2023, and gave them a status update in email in December 2023. The first order of business is really to get React Native Test App set up in the repository, either with incremental changes to the existing repo, or by rebooting the structure. Being able to validate PRs/commits on a simulator in CI is key to retaining progress and sustaining ROI in the short term, especially if multiple build configurations (new arch, etc) will be supported. Sounds like we should all hop on a call and re-sync. Gary has my email! :D