[0.74] Bridgeless By Default

[cipolleschi]

Important

tl;dr: With React Native 0.74, we’re going to enable Bridgeless by default, as long as you enable the New Architecture

As we roll out the New Architecture of React Native in Open Source, we want to share an update on Bridgeless Mode. Starting from 0.74, Bridgeless will be enabled by default only when the New Architecture is enabled.

The New Architecture remains experimental and you need to explicitly enable it in your applications.

This marks an important milestone for React Native, as Bridgeless was the last piece of the New Architecture, and we managed to open source it in React Native 0.73, but it was still behind a flag. Now, we removed that flag and it will be enabled by default when the new architecture is enabled.

Now, you can experience the New Architecture at full power in your React Native app. We need your help to iron out the latest details, so please, open an issue on React Native every time you find something that is not working as expected in the New Architecture.

How to enable it and what does it mean?

As this post's title suggests, you don’t have to do anything to experience Bridgeless but to turn on the New Architecture. To enable it, follow the instructions in the New Architecture documentation:

• Android
• iOS

How to check that Bridgeless is enabled?

Once the app is running, you can verify that Bridgeless is enabled by looking at the Metro logs. When Bridgeless is enabled, you should see logs that look like this:

 (NOBRIDGE) LOG  Bridgeless mode is enabled
 (NOBRIDGE) LOG  Running "<YourApp>" with {"rootTag":1,"initialProps":{"concurrentRoot":true},"fabric":true}

What to expect?

Your App should run seamlessly in Bridgeless mode, provided that it was running with the old Architecture before.

We spent a lot of time working on interop layers and on bringing the Bridge API you might have used to Bridgeless mode. You can read more about it in the Backward Compatibility section below.

However, we know that there might still be some missing APIs and some rough edges that we need to iron before stating that the New Architecture is the new default.

We need your help!

Whenever you find something that does not work as expected, please submit an issue to the React Native repo, using the New Architecture issue template.

We are prioritizing working on the New Architecture and those bugs have the highest priority for us.

Opting-out of Bridgeless

Although we consider Bridgeless an integral part of the New Architecture, we are still providing the possibility to disable it, while keeping all the other bits of the New Architecture turned on: Codegen, New Native Module system (Turbo Native Modules), New Renderer (Fabric).

We are not going to support this combination in the long term, so we are not suggesting to use it effectively. But, in some cases, it could be helpful to disable Bridgeless to debug some features or to verify that there is a disparity between Bridge and Bridgeless.

To disable Bridgeless mode only, follow these steps:

Android

1. Enable the new Architecture as shown here
2. Open the <your-project>/app/src/main/java/com/<your-project>/MainApplication.kt file
3. Apply the following change in the onCreate method

override fun onCreate() {
  super.onCreate()
  SoLoader.init(this, false)
  if (BuildConfig.IS_NEW_ARCHITECTURE_ENABLED) {
  // If you opted-in for the New Architecture, we load the native entry point for this app.
+   load(bridgelessEnabled=false)
-   load()
  }
}

4. Build and run your Android app.

iOS

1. Enable the new Architecture as shown here
2. Open the <your-project>/ios/<your-project>/AppDelegate.mm
3. Override the bridgelessEnabled method by adding the following code:

 - (NSURL *)bundleURL
{
  #if DEBUG
    return [[RCTBundleURLProvider sharedSettings] jsBundleURLForBundleRoot:@"index"];
  #else
    return [[NSBundle mainBundle] URLForResource:@"main" withExtension:@"jsbundle"];
  #endif
}

+- (BOOL)bridgelessEnabled
+{
+ return NO;
+}

@end

4. Build and run your iOS app.

Verify that the app is running with the New Architecture in Bridge mode

Once you run the step above for either Android or iOS and the app is running, you can check the Metro logs to verify whether the app is running with Bridgeless turned off.

The Metro’s logs should look like this:

BUNDLE  ./index.js 
LOG  Running "RNTestProject" with {"rootTag":1,"initialProps":{"concurrentRoot":true}, "fabric":true}

As you can see, the tag (NOBRIDGE) is not rendered, but React Native is running with concurrentRoot set to true, which is a distinctive feature of the New Architecture.

Backward Compatibility

To ensure that projects can migrate smoothly to the New Architecture and to Bridgeless, we dedicated a lot of time to interoperability and backward compatibility. Specifically we:

• Brought back to Bridgeless some methods from the Old Architecture and from the Bridge.
• We created a Bridgeless interop layer that allow you to use a proxy object for the Bridge even in Bridgeless mode
• We worked with the maintainer of the most popular libraries to ensure that those libraries will work seamlessly in Bridgeless mode.

In the following sections, we will explore more in depth the APIs we brought back and the current known limitations of Bridgeless.

The Interop status as of React Native 0.73

We started working on interop layers and backward compatibility way back, even before React Native 0.73. As a refresher:

• We introduced the New Renderer Interop Layer in React Native 0.72.
• We introduced the Legacy Native Module Interop Layer and Static View Configs in React Native 0.73.

This line of work already allowed you to use several APIs that were available in the Old Architecture in the new one. However we were aware that something was still missing.

New API introduced in 0.74

In 0.73, we were not able to support all the API we wanted. We listed the APIs we knew were not working properly in the post for 0.73 to let you know what you could use and what not.

In 0.74, we fixed some of those missing APIs and added more layer of backward compatibility to let you migrate to the New Architecture with more ease.

For this version of React native, we focused more on Android APIs

ReactActivity.getReactDelegate()

The ReactDelegate you can obtain from the ReactActivity is now supporting some other methods that were not supported in 0.73:

• onKeyLongPress()
• onKeyDown()
• onConfigurationChanged()
• onNewIntent()
• onWindowFocusChanged()
• onActivityResult()
• shouldShowDevMenuOrReload()
• reload()

The reload() method, specifically, requires some extra details: we introduced it with the purpose of replacing direct calls to ReactInstanceManager.recreateReactContextInBackground(). So, if your NativeModule was using recreateReactContextInBackground, you can now replace it with a simpler reload() method call.

ReactContext.getCatalystInstance

To improve backward compatibility between the New and Old Architecture, we brought back the getCatalystInstance() method of the React Context.

The method now returns a BridgelessCatalystInstance which supports the following methods:

• getJSCallInvokerHolder()
• getRuntimeExecutor()
• getJavaScriptContextHolder()

[DimitryDushkin]

Hey! Could you share what will change for user experience? Are there any numbers on performance/start up time/crashes/etc. difference between bridged and bridgeless modes?

[ahmed-khlifi]

@DimitryDushkin You can expect a performance boost, the reason is that bridgeless mode eliminate the JSON bridge that do communication between The JS thread and the native thread, the bridge can cause sometimes a little of lag especially when there is a lot going on in the APP ( animation, API calls ..), because it's responsible for the serialization and decoding of a lot of data
Now, using JavaScript Interface (JSI) the JS and Native codes will do direct communication which improve the performance.
I hope this helped you to understand the impact.

[DimitryDushkin]

Thanks @ahmed-khlifi for a response! I wonder are there any concrete numbers reflecting these changes?

[ahmed-khlifi]

@DimitryDushkin By numbers I assume you are talking about some percentages, which actually I'am not aware if there is something specific about that, because it depends on the implementation and the business logic in the Application.

[DimitryDushkin]

@ahmed-khlifi got it, thanks for a response!

[ShwareAPI]

The New Architecture Performance Benchmarks

[ArindamRayMukherjee]

Hi there,

Two questions(apologies, the docs seem to not address this so far)

1. Issues like The "bundle install & & RCT_NEW_ARCH_ENABLED=1 bundle exec pod install" command results in the error "Could not find the Realm binary." realm/realm-js#6640 that arise out of bridge-less being the default mode; is there a systematic way of detecting them?
2. What would this mean for C++ based turbo modules that are integrated through the bridge?

ps: The C++ turbo modules guide used to be visible from the main react-native docs page, but has now inexplicably vanished from there.

[cipolleschi]

@ArindamRayMukherjee

1. Issues like The "bundle install & & RCT_NEW_ARCH_ENABLED=1 bundle exec pod install" command results in the error "Could not find the Realm binary." realm/realm-js#6640 that arise out of bridge-less being the default mode; is there a systematic way of detecting them?

No, this is an issue of the library that is not distributing the Binaries correctly. React Native has not visibility on 3rd party libraries and that's a responsibility of the library maintainer.

2. What would this mean for C++ based turbo modules that are integrated through the bridge?

It's not clear what do you mean with "...that are integrated through the bridge". How are you integrating TurboModules with the Bridge? The C++ TM architecture is decoupled from the Bridge. Even in the link you share, the bridge word only appear in the context of bridging JS type to C++ types, not in the context of the old architecture Bridge.

Do you have an example we can use to talk on?

ps: The C++ turbo modules guide used to be visible from the main react-native docs page, but has now inexplicably vanished from there.

We moved the documentation from the website to the working group: docs.

[ArindamRayMukherjee]

@cipolleschi Understood. Thanks for explaining.