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 in the "New Architecture support in popular libraries" spreadsheet. This does not track every library, only those that appeared in the top 400 most installed libraries on EAS Build, so if a library is not there it does not mean it is necessarily unsupported.

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.

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 Monday, March 25, 2024, 42% of the community libraries tracked in this spreadsheet are compatible (see the “Statistics” tab). This is already great news for 0.74 as we’re still in the RC phase, but we need your help to get through the majority of libraries by the time 0.74 hits stable!

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 "New Architecture support in popular libraries" spreadsheet 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

[SerSerch]

Hi! I have a new turbo module (only android)
I will be glad for feedback and issues

@serserm/react-native-turbo-serialport

the repository has a monorepo architecture
it is also possible to write a plugin to make it work in expo, but I don't know how to do it properly

[brentvatne]

hi @SerSerch! re: expo support - any module that works without the expo module system set up should work with it set up. they are typically orthogonal. the only exception is when the module requires you to use its own subclass of eg: appdelegate

[SerSerch]

@brentvatne oh, thanks! it works!
expo-app