An Overview of the Current React Native Architecture

In this State of React Native 2018 blog post, a future plan for introducing a new architecture to the React Native ecosystem was announced. The upgrade is expected to address the limitations of the current architecture and provide new capabilities to projects using React Native. As of 2022, the new architecture is closer to achieving maturity, while more and more elements of the new ecosystem have become generally available (such as the Hermes engine).  

But before the new architecture arrives, read on to learn more about the current solution and get an analysis of its structure to understand shortcomings that the new solution will address.

Threads and the rendering process 

First, take a look at a basic fragment of code written in React Native:

const HelloWorldComponent = () => {
return <View style={{ flex: 1,
justifyContent: 'center’,
alignItems: ‘center’,
borderWidth: 5,
borderColor: 'red',
backgroundColor: 'yellow' }} >
<Text>Hello, World</Text>
</View>
);
}

You might wonder how this JavaScript (JS) code can produce an application that runs on mobile devices. As it turns out, this code needs to be processed by application trees: 

• First, a React Element Tree is created by React. This tree contains React Elements – pure JavaScript objects that define how the application or a particular view should look like. This is where properties (props), styling and elements hierarchy are defined. 
• Next, a React Shadow Tree is computed. This is the stage where the layout of elements is determined. A React Shadow Tree includes React Shadow Nodes that contain properties from original JavaScript elements, along with layout data. Layout calculation is provided by the Yoga layout engine. 

• Finally, a Host View Tree is constructed. This tree is composed of display elements specific to a particular native platform (Android, iOS) that corresponds with React Native JS elements. 

As a result, three separate structures used in the process of rendering React Native application are created. Each structure exists in a separate thread whose functions are roughly divided in the following way: 

• JavaScript thread – responsible for handling incoming events and rendering the view elements in response to said events 
• Background (Shadow) thread – where the process of calculating layout elements takes place 
• UI (Main) thread – where the application itself is run. It is the only thread that can access user interface (UI) and manipulate it 

The three separate threads exist within their own realms. But how can they communicate with each other? To put it simply – by using the Bridge. 

React Native Bridge

The React Native Bridge serves as an intermediary between threads. It is mostly written using C/C++ and uses a JavaScript engine (JSCore, V8 in debugging) to facilitate communication between JavaScript and Native (machine) code.

The Bridge can be conceptually seen as something similar to a Message Broker, as is works in an asynchronous way and requires serializing data (in the JSON format) between threads. Incoming messages are queued by the Bridge and processed in a first-in, first-out (FIFO) manner.  

Communication between threads is bidirectional. The JavaScript thread handles events coming from the other two threads, while the process of displaying and updating the application view requires data to be sent through the render pipeline. 

Advantages and drawbacks of the React Native architecture

By using the Bridge, React Native can leverage certain advantages. The obvious one is the cross-platform capability that enables you to reuse the same source code to deploy your application on different platforms (mainly Android and iOS). It also makes the development process easier. The architecture lets you hot reload your application during the development process so that you don’t have to recompile the source code every time changes are made, which saves a lot of time.  

However, as the saying goes, there’s no rose without a thorn. The implementation of the Bridge comes with some drawbacks, most importantly: 

• all of the communication between threads is asynchronous, which complicates the usage of native application programming interface (API) components, which expect synchronous processing (Android’s RecyclerView is one example of a tool that faces certain limitations in its usage); 

• the transfer of large amounts of data (such as images and data in the base64 format) can be very slow; 
• data has to be copied between threads instead of being accessed by all threads where it is stored. 

For relatively simple applications, written mostly in JavaScript, these drawbacks are usually not a huge problem, but for more complex projects, closely integrated with native platform APIs, these limitations might pose a serious issue.  

These drawbacks are the reason behind the introduction of a new architecture for React Native – but that’s a story for another time.

React Native architecture – more to come!

This article is meant to provide a general overview of the current React Native architecture and its inner workings and limitations. Having insights into its current state gives you a better understanding of why the new architecture and its components (Fabric, TurboModules and others) are such a big change.  

Since the new architecture is getting closer to becoming a stable solution, we’ll explore it further in future articles to see what is looming on the horizon. 

If you’re looking to develop a React Native application, a team of experienced and engaged engineers can accelerate your software delivery and help you build an outstanding product. At Software Mind, we engineer cutting-edge solutions for companies from a wide range of industries who value high quality and reliable software partnerships. Reach out to us via the form below and find out how our top React Native development talent can boost your company’s growth.

FAQ section

What is React Native framework?

React Native is a hybrid software framework for making applications for Android, iOS and more. Based on JavaScript and React, it offers useful features that aid mobile developers in creating powerful cross-platform mobile applications. React Native enables software engineers to deploy applications written in React.js on Android, iOS and various other platforms thanks in part to React Native Bridge. The React Native Bridge serves as an intermediary between threads. It is mostly written using C/C++ and uses a JavaScript engine (JSCore, V8 in debugging) to facilitate communication between JavaScript and Native (machine) code. The Bridge can be conceptually seen as something like a Message Broker, as it works in an asynchronous way and requires serializing data (in the JSON format) between threads. Incoming messages are queued by the Bridge and processed in a first-in, first-out (FIFO) manner

What advantages can a mobile app gain from adopting the React Native framework?

Adopting the React Native architecture can bring significant advantages to mobile apps. One of the key benefits is cross-platform development, which enables developers to build a single codebase that can run on both iOS and Android platforms and reduces development time and costs, as developers don’t need to create separate codebases for each platform. Another advantage is hot reloading, which lets developers see changes in their code reflected in the app immediately without having to restart it, which speeds up the development process and makes it easier to debug issues. Additionally, React Native provides a large ecosystem of pre-built components, so building complex user interfaces can be done quickly and easily. This saved developers’ time and effort, as they don’t need to create these components from scratch. Overall, React Native offers a powerful and efficient framework for building mobile apps and provides several advantages over traditional native development approaches.

Are there specific use cases where the React Native framework is particularly beneficial?

Yes, there are specific use cases where the React Native architecture is particularly beneficial for apps with a large user base, a fast release cycle, a complex user interface and for applications with a need for quick prototyping. Let’s elaborate on these four points. React Native’s cross-platform development capabilities make it well-suited for apps with a large user base and enables developers to reach a wider audience with a single codebase. The open framework’s hot reloading feature allows developers to quickly implement and deploy changes on their local test environment to validate new features fast and easily. React Native’s large ecosystem of pre-built components makes it great for building apps with intuitive user interfaces, as developers can leverage these components to save time and effort. And finally, thanks to its ease of use, it is a good choice for quick prototyping, as it allows developers to swiftly create and iterate on prototypes. In general, React Native is a solid choice for any app that requires cross-platform compatibility, fast development, or a complex user interface.

Is React Native’s new architecture faster?

React Native’s new architecture is currently being evaluated for its performance, but initial benchmarks indicate that it has the potential to be much faster than the previous architecture. The new framework has implemented several optimizations, such as a more efficient way of communicating between JavaScript and native code, which can result in faster rendering and startup times. However, there are some potential trade-offs with the new architecture. For example, it may use more memory than the old architecture, which can be problematic for some devices. Additionally, the new architecture is still under development, so some bugs or performance issues may need to be resolved. Overall, proposed changes to React Native architecture have the potential to improve the performance of React Native apps significantly. Nonetheless, it is still too early to definitively state whether it is faster than the old architecture in all cases. Developers should carefully evaluate their specific needs and requirements before migrating to the new architecture.