React Native New Architecture

[CedricGuillemet]

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]

Are there any updates on the new architecture?

[CedricGuillemet]

Are there any updates on the new architecture?

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

[ryantrem]

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: reactwg/react-native-new-architecture#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]

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:
microsoft/react-native-test-app#1803

[ryantrem]

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]

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]

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]

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

[ChaimActionShip]

Hi. How are the changes doing? We would like to move our project to bridgless mode, and the last package incompatible with it is BRN =(

[matthargett]

Hi. How are the changes doing? We would like to move our project to bridgless mode, and the last package incompatible with it is BRN =(

@okwasniewski has been working on making 6DOF head tracking work well on Apple Vision Pro within BGFX (a prerequisite for BabylonNative) here:
callstack/bgfx@1bb0b5d

If we're very lucky, a pull request should be up in the BabylonNative repo soon that integrated the BGFX changes and then he'll be able to do a trial integration pass in Babylon React Native. That trial integration will probably necessitate the migration to New Architecture, as React Native visionOS has been developed with that as a default assumption. His full-time commitment on my project is up at the end of this month, so we'll be looking for funding/staffing partners at that point to keep the OSS vibes going. 🤞

It's taken hundreds of commits (and issue creation/comments) across dozens of open-source repos over the last ~8 months to get to this point, and we are self-funded so it's very single-threaded. I appreciate everybody's patience and support in the home stretch here that should enable hundreds of BGFX and BabylonJS experiences to make the leap to modern React Native and Apple Vision Pro :D

[okwasniewski]

FYI: I got Babylon React Native to work on the new arch (Turbo Modules + Fabric)

Going to create a PR next week

[CedricGuillemet]

This is super cool @okwasniewski !!!

[ryantrem]

I'll definitely be interested in seeing the code changes to make that work!

[okwasniewski]

I'll definitely be interested in seeing the code changes to make that work!

@ryantrem here is my WIP commit adding the support: okwasniewski@1b32b8b

Still need to handle prop updates and few more things including Android support 😄

[okwasniewski]

Hey @CedricGuillemet @ryantrem,

I've opened a PR, here: #659