And why its architecture is awesome, at a top level.
When writing React Native apps, we build native UIs. And that’s the key point, we create UIView instances just like we would have with platform specific languages:
My first assumption on this framework was something like:
They probably create an AST from the JS code and transform it to make it run on multiple devices.
But what currently exist are compilers that target their own specific platform. For example, we have compilers that accept Java / Kotlin code and target Android platform, or Obj-C / Swift targeting iOS platform. It exists many compilers for different languages and targets. They do their job well because they have been designed to create optimised artefacts for them.
React Native is built in such a way that it uses existing compilers:
It’s built with a really opened architecture that allows the code to be run, not only on mobile devices, but also on other platforms:
It can also be used with other frameworks:
So how did the team build such a framework, that is platform and framework agnostic, by using the existing tools & compilers?
Let’s take a step back and look at the big picture of React Native.
The bridge is the concept that provides a way for bidirectional and asynchronous communications between these two universes. What’s important here is that they are completely written in different technologies, but they are able to communicate.
Let’s remember when we were coding distributed backend applications with multi-service communications.
How do we manage communication between two services that are completely different at a language/platform level ?
If we want these two services to communicate, we rely on a message queue. The first service pushes some commands inside the queue and the other one has to execute these commands when possible.
In React Native, the bridge endorses the message broker role, handling asynchronous commands between the two different worlds.
It offers multiple possibilities:
The more the bridge’s language is ubiquitous and universal, the more the possibilities are… and it is indeed!
The communication on the native side is “the easiest” part.
Let’s begin with the iOS platform. Since Obj-C is an extension of the C language, it can communicate with it natively. This way, exchanges between the bridge and the Swift / Obj-C world are easy and natural.
On Android, we need to rely on the Java Native Interface to dialog with the bridge.
Here’s an old but really awesome and deep post explaining how the bridge is implemented on iOS by Tadeu Zagallo.
Let me know if you have further questions regarding React Native internals. I’ll try to provide all that I know on the topic.