React Native’s denominated ‘new Architecture’ is the newest of the architecture changes made by the React Native team, and it boasts of being a game changer and the future of React Native apps.

One of the most significant changes it brings forward is removing the usage of the asynchronous bridge between the JS and native components of the app, among many other changes.

It has been in the works for a while now and is bound to become the new default for React Native apps sometime soon, so let’s review the biggest changes it will bring forward.

 

Changes to the bridge

React Native’s bridge architecture was initially born as a way to connect the JS and native counterparts of a React Native app and allow bidirectional communication between them. To make this communication possible, the data traveling back and forth suffered serialization before being sent.

This serialization introduced a bottleneck that could end up limiting the maximum possible performance of apps written in React Native, which was one of the reasons for its removal.

The new architecture replaces the bridge with JSI (JavaScript Interface). JSI is an interface that allows JS to hold references to C++ objects and vice versa, thus removing the need for data serialization.

On a device, JSI works similarly to a web browser, where a C++ application embeds a JavaScript runtime (Hermes) and exposes APIs that allow and facilitate communication between the host application and the JS runtime.

New modules that use this approach may benefit from increased performance, and more libraries are updating to get this new functionality every day.

 

Turbo Modules

Another change that accompanies the new architecture is the addition of Turbo Modules.

Turbo Modules are the evolution of the native modules you might be familiar with and use JSI, lazy loading, and many other improvements to use the device’s APIs and services in a more performant (and type-safe) way.

Turbo Modules allow running processes on C++ instead of JS, improving time on compute-heavy processes, sometimes up to an order of magnitude.

This also means that the exact C++ implementation can be re-used between platforms, reducing the amount of code duplication needed to make a module work on both Android and iOS (though, in practice, most will probably still be written in Kotlin / Swift).

Something worth mentioning is that Native Modules will not be deprecated by React Native and will continue working for the foreseeable future. This is important to ease the transition between architectures and provide a gentler adoption curve for the new one.

 

Fabric

Fabric is considered the third component of the new architecture. It is a new rendering system that claims to be more performant and interoperable with host devices as more of the rendering logic is now moved to C++.

This change is aligned with the new architecture, as the logic does not need to be serialized every time to run on the host platform (a.k.a. going through the bridge), which means less time is spent serializing data to JSON.

Fabric also claims to improve load times due to the usage of lazy loading of the modules. This means that modules are only loaded as needed, so apps are not bogged down at startup loading things they don’t need.

Finally, but not less importantly, adding support for Suspense and Concurrent Features from React 18 gives developers more ease and control over how their components are shown during and after loading.

 

Performance and other changes

Performance benefits are present on both iOS and Android, as evidenced by the work of community users who are working on this change.

The difference in performance, however, while similar in absolute numbers (up to 40ms in some of the test scenarios posted above), if viewed in relation to the previous times, does not make Android noticeably faster.

What this means is that the slower of both platforms does not have a noticeable boost in performance to compete with Apple’s.

App size may also see reductions when using the new architecture, with users reporting reduced sizes of up to 50% depending on the original size, though those changes may be related to the usage of Hermes and depend on many other build and compile flags, so the actual numbers may vary widely between specific apps.

 

Updates to libraries

A great number of libraries that want to be supported will need to make the jump to the new architecture, and while progress is present in many of the most popular libraries, some older or less-supported libraries have not made the jump, and some may never do.

This change will inevitably create a bridgeless chasm (get it?), with libraries that made the jump to the new architecture on one side and the ones that will end up falling into disuse on the other.

If you want to check whether your app has unsupported libraries, the React Native archive will be your friend, letting you know if a library you are currently using in your app is known to present issues on the new architecture.

Also, if you are using Expo, you can use the Expo Doctor command to find out more automatically.

 

Expo and the New Architecture

With Expo’s position as the recommended option by the React Native team, it is no surprise that they have made a huge effort to make Expo work with the new architecture, and they claim that almost all their SDK libraries fully support the new architecture, with some known issues that are being actively looked into.

The setup for using the new architecture in Expo is also extremely simple and foolproof, so if you are looking into creating a new app with the new architecture, it is my recommendation (and the React Native team) to go that route.

If you need more information on Expo and React Native, check out this other article.

 

Conclusion

The new architecture presents many advantages compared to the old one, most of all regarding performance. This is a step in the right direction for the platform, and it targets one of the biggest problems in the debate on React Native vs. native apps.

These improvements, though, as the platforms, are not made equal, with iOS reaping the most noticeable improvements vs Android.

Speaking as a React Native developer, though, anything that makes Android work even a little bit faster is welcomed with open arms.

It is also important to reiterate the rift that will be created regarding library support of the new architecture, as it will be a huge factor in making the jump for those apps that rely on older or less popular libraries.

And finally, try Expo if you haven’t yet.