Library support for New Architecture + Bridgeless in 2024

[brentvatne]

Note

tl;dr: The New Architecture is being rolled out in 2024, and now is a great time to verify and fix compatibility issues in your libraries. React Native 0.74 provides an Interop Layer that greatly assists in this process, making it possible to use modules written for the legacy architecture with minimal changes in most cases. A small team of engineers have kicked off the effort with some of the most installed libraries, but more help is needed from the community to ensure coverage across the vast ecosystem. We're requesting help in the form of: library users testing and reporting issues, authors updating libraries, and engineers experienced within this domain assisting others with making their libraries compatible. Resources, links, and additional context are below.

Important

The current status of many of the most popular libraries is tracked on React Native Directory.

As shared in the New Architecture landing page, 2024 is the year that the New Architecture will be rolled out to all React Native users. 

In order for developers to be able to begin transitioning their existing projects to the New Architecture, it's important that the libraries they depend on are compatible.

There have been previous efforts to expand library support for the New Architecture, which helped to inform changes that were needed to make this process easier for library maintainers. 

In React Native 0.74, there are various Interop Layers enabled by default which allows many libraries to work without any changes — however, it's not perfect and some libraries will need to be updated to account for its quirks. 

React Native 0.74 also enables bridgeless mode by default, which is a key feature of the New Architecture and may require changes to some libraries.

This discussion is a call for support in migrating third party React Native libraries, in this final push to get the New Architecture shipped.

Kicking off the initiative with the most frequently installed libraries

Meta and Expo kicked off this effort by identifying the 400 most installed libraries on Expo's CI service (EAS Build), and then filtering those down to those that depended on native code. We believe this is a good indicator of which are the most popular libraries in the React Native ecosystem as a whole.

We proceeded to either work on testing and fixing the libraries ourselves, or reached out to the maintainers of those libraries to ask for support. Many of those folks kindly agreed to help, and we've been working together to get their libraries updated.

📈 🔗 The current status of these libraries is tracked in the "New Architecture support in popular libraries" spreadsheet on React Native Directory.

This list includes the most popular libraries in the ecosystem, including libraries from Software Mansion such as react-native-reanimated and react-native-screens, libraries in the Expo SDK such as expo-updates, service libraries like react-native-firebase, and many others.

As of Wednesday, June 26, 2024, >61% of the the 400 most installed libraries are compatible.

How you can help

There are a few ways you can help with this effort, depending on your experience and interests:

• Test libraries: If you're a library user, you can test libraries that you depend on and report any issues you encounter. This will help library authors identify which libraries need to be updated. Learn how to test your libraries.
• Update libraries: If you're a library author/maintainer, or willing to contribute, you can update libraries to work with the New Architecture and bridgeless mode. Using the Interop Layer, this can often be relatively straightforward. You can also open a discussion in this repository to ask for help or provide updates on the status of your library. Read “Enable the New Architecture for Libraries” to get started.
• Help other library authors: If you're familiar with the migration process, you can help other library authors update their libraries by answering their questions here or in issues on their repositories.

Be sure to refer to the React Native Directory to see which libraries are already supported. Additionally, you can search in this discussion to see if anyone has already opened a thread for the library you're interested in.

The libraries that are most likely to require updates are those that ship or depend on third party native code. Libraries that only use JavaScript or React Native core APIs are expected to work without any changes (provided that they do not use private/undocumented APIs).

Resources to help you get started

• Enable the New Architecture for Libraries: the first document that you should read when you want to add New Architecture support for a library. This document was recently updated to recommend using the Interop Layer first for the shortest path to compatibility.
• Test your library against React Native 0.74-rcs: a straightforward guide to test your library against React Native 0.74-rcs.
• Test your library built with the Expo Modules API against React Native 0.74-rcs: a quick video walkthrough.
• React Native New Architecture Working Group - Guides: a collection of guides and resources to help developers understand the New Architecture.

Opening a thread for a library

Discussion title

Use the library name, eg: react-native-safe-area-context.

Discussion body

Provide information in the following format (where "New Architecture" means with bridgeless also enabled):

• Library version: The version of the library you tested.
• React Native version: The version of the React Native you tested with (eg: 0.74-rc.4).
• Compatible with New Architecture?: Yes/No/Unknown. If not, please provide details. Be sure to test both platforms (iOS and Android) and provide details for each.
• Compatible with New Architecture disabled?: Yes/No/Unknown. If not, please provide details. Be sure to test both platforms (iOS and Android) and provide details for each.

Below this, share any questions, comments, or concerns you have.

[mrousavy]

Btw - who was write access to that google doc with the libraries?

1. react-native-blurhash supports new arch (Fabric)
2. react-native-mmkv PR is ready, waiting on RN 0.74 release
3. react-native-vision-camera is still in progress (kinda blocked at the moment)

[mrousavy]

@RSNara @sammy-SC sorry hate to bump this, but do you have any thoughts on my questions? I'm not sure how to proceed with that in VisionCamera and your insights would be hugely appreciated - would be dope to use CodeGen/Fabric for this to avoid the whole global JSI function logic.

[mrousavy]

@brentvatne I haven't tested rn blurhash with bridgeless yet, but it doesn't use JSI so I think it should work fine. I'll double check :)

[mrousavy]

@mym0404 I am not migrating from JSI to Turbo/Fabric, I am migrating from old arch to new arch. There are some parts that I wrote in JSI which might be possible to do with new arch (Turbo/Fabric/CodeGen), so that would be less code for me to write, a bit safer since I no longer dangerously look up the view using global functions, and type-safe, but I'm waiting on the Meta team to share some thoughts on this if this is possible to do. :)

[mrousavy]

@philIip asked me on Discord to clarify my question a bit, so here we go:

I think the VisionCameraExample app (inside the repo, package/example) is a perfect way to demonstrate this.

You can follow along the route it goes quite easily both in JS and native:

1. In JS, the user uses the useFrameProcessor hook (which essentially just returns the same function you passed into it, but with a custom try/catch error handler) and passes the frameProcessor function to the <Camera> just like any other prop:
   

2. If we just pass the frameProcessor prop to the native <NativeCameraView>, it will be converted to a RCTDirectEventBlock, which we don't want. We need to use JSI because we send the Frames as custom jsi::HostObjects through to JS. So we cannot use the Native Module type conversion system here.
   Instead, we use componentDidUpdate() to imperatively set the frameProcessor on the view using JSI functions:
   

3. Inside the imperative setFrameProcessor(...) (or unsetFrameProcessor()) functions, we call a global JSI method that I injected into the Runtime, this takes a view tag (findNodeHandle) and the frame processor itself:
   

4. And from then on we are now already in native (Objective-C++ or C++/JNI) land.

   1. I do some conversions on the jsi::Function (arguments[1]) to make it a Worklet which is callable from another Thread (see line 69-70)
   2. I resolve the CameraView* using it's viewTag (arguments[0]) (this currently happens through [UIManager viewForReactTag:] on iOS) (see line 73-75)
   3. I create an instance of a custom type I created (called FrameProcessor, it just holds the C++ Worklet instance and exposes it to ObjC/Java), and set it on the CameraView.
      

5. This is the FrameProcessor type that I set on the view (same exists for Java/C++/JNI).
   

6. As you can see, it's treated like a normal prop from React - just like all other props. It's just the complex route it has to go through for the conversion from jsi::Function -> Worklet -> FrameProcessor that makes this hard to achieve.
   

Essentially what I am looking for is to expose the frameProcessor property to React just like all the other props that you can see in 6., and have my custom C++ type converter that creates the FrameProcessor object from a jsi::Function. Ideally I just want to write that part, just like an RCT_ENUM_CONVERTER, but for the jsi::Function now.

Is that possible?

[angelo-hub]

following up here as i'm building birdgeless right now and in the next 2 months will be implementing react-native-vision

[TheRogue76]

@brentvatne I sent you an email regarding getting access to the doc. Hope that's ok. Just need to add the details for lib version and the versions it was tested against

[brentvatne]

sure thing! I've sent you an invite to edit it

[leonelmq]

Hi! I found firebase SDK already in the list. Is it planned to reach adobe to add the whole SDK to the migration?
https://github.com/adobe/aepsdk-react-native

[brentvatne]

hey @leonelmq! if you use this adobe library, it would be great for you to reach out through their issues and request this feature. you can point them to this discussion for context

[axeldelafosse]

Hey Brent! Thank you so much for this initiative, this is great!

Can we add zeego and its dependencies please? It's a great lib by @nandorojo :)

Here is the list:

• zeego
• @react-native-menu/menu
• react-native-ios-context-menu
• react-native-ios-utilities

[nandorojo]

Brent actually tested this on iOS last I spoke to him, and while there's no crash, it doesn't work. You can see the issue I opened at dominicstop/react-native-ios-context-menu#100

[brentvatne]

done! I added them to the "Community reported" section of the sheet

[younes0]

@brentvatne
Could you add please:

• react-native-fast-shadow:⚠️ not implemented, see FastShadowedView is not Fabric compatible yet alan-eu/react-native-fast-shadow#25
• react-native-ux-cam: ⚠️ not implemented, see New architecture support uxcam/react-native-ux-cam#132
• react-native-simple-toast: ✔️complete: see https://github.com/vonovak/react-native-simple-toast

And update eventually:

• @sentry/react-native: ✔️complete: see: https://docs.sentry.io/platforms/react-native/migration/#from-4x-to-5x

[brentvatne]

done! I added it to the "Community reported" section of the sheet

[ngocle2497]

@brentvatne
Can you add:

• okta-react-native: created PR

[brentvatne]

done! I added it to the "Community reported" section of the sheet

[TheLonelyAstronaut]

Hey @cortinico!

I'n currently porting React Native Navigation by Wix to new bridgeless architecture and have some questions/blockers:

1. What should i use instead of bridge.uiManager in case of bridgeless mode? I want to find view by nativeID, but C++ UIManager from RCTHost does not provide such functionality.
2. How could i get NSTextStorage from RCTParagraphComponentView? I need it for shared element transition.

[ngocle2497]

Hi @cortinico , just create PR to migratte react-native-orientation-locker to new arch. Can u update the sheet?

[brentvatne]

done! I added it to the "Community reported" section of the sheet

[morenoh149]

hi @cortinico I have a PR to migrate react-native-contacts to new arch. Can you update the sheet?

[cortinico]

cc @brentvatne

[brentvatne]

@morenoh149 - you can update the entry for it on react-native-directory, this is where the canonical compatibility information is stored now: https://github.com/react-native-community/directory

[0xFA11]

I think we should also include @gorhom's react-native-bottom-sheet in the list.

2 useful links:

• [v4] | BottomSheetFlatList not supported when newArchEnabled=true gorhom/react-native-bottom-sheet#1726
• fix: replace getRefNativeTag with findNodeHandle gorhom/react-native-bottom-sheet#1823

Hopefully, react-native-bottom-sheet v5 could implement and support new arch!

[brentvatne]

@ThusSpokeNomad - you can update the entry for it on react-native-directory, this is where the canonical compatibility information is stored now: https://github.com/react-native-community/directory

[0xFA11]

@brentvatne done, see here: react-native-community/directory#1198

[siddarthkay]

It would be nice to include Tesla Motors react-native-camera-kit -> https://github.com/teslamotors/react-native-camera-kit

I tried to enable new architecture for our app and observed that this library works well on iOS but shows this warning on Android.

The library maintainers will welcome PRs regarding new architecture -> teslamotors/react-native-camera-kit#537 (comment)

Here is my research issue where I document our journey to enabling new architecture for status-mobile -> status-im/status-mobile#18138

[brentvatne]

@siddarthkay - you can update the entry for it on react-native-directory, this is where the canonical compatibility information is stored now: https://github.com/react-native-community/directory

[siddarthkay]

@brentvatne : react-native-community/directory#1289

[vipindvipin]

Hi @brentvatne @cortinico

I've recently migrated my React Native project to the New Architecture (currently using React Native version 0.72.14) and will be maintaining this setup for a few months.

After the migration, multiple issues have surfaced. For example, components like FastImageView and BVLinearGradient stopped working. To address this, I opted for the interop layer by adding these components in react-native-config under unstable_reactLegacyComponentNames, and they started working.

As I'm not updating the React Native version, I’m left with using the interop approach**. However, I encounter challenges in finding the correct component names to add to react-native-config.**

The bigger concern now is that my app has become very slow, with unresponsive touches and sluggish bottom navigation. The performance issues seem to be related to the incompatibility of libraries with the new architecture.

How can we efficiently identify the correct component names to add to react-native-config for interop. Determining which specific names are needed for each library is often confusing.

What are the other possible ways to tackle major issues like unresponsive touches and slow bottom navigation?

Note: Upgrading the React Native version is not an option for me.

[cortinico]

Hey @vipindvipin

How can we efficiently identify the correct component names to add to react-native-config for interop. Determining which specific names are needed for each library is often confusing.

Since React Native 0.74, there is no need to specify the components you want to add to the interop layer: #175

Note: Upgrading the React Native version is not an option for me.

Sadly if you don't upgrade React Native version you will have a way "worse" New Architecture experience. We shipped several bugfixes in the last months that you'll be missing out. Moreover, you won't be able to distribute to the PlayStore anymore once the SDK requirements by Google are enforced, so I invite you to consider upgrading to the latest stable.

[gunnartorfis]

@adyen/react-native

Library version: 2.4.0
React Native version: 0.74.5
Compatible with New Architecture? No

Crashes on iOS, verified by removing every import from @adyen/react-native.

Build fails on Android with a "Java heap space" error.

[cortinico]

Build fails on Android with a "Java heap space" error.

That's unrelated to the New Architecture by the way. It's a Gradle/Android issue that happens when Gradle hasn't enough memory to execute.