ref – https://hackernoon.com/understanding-react-native-bridge-concept-e9526066ddb8
Does not depend on Webview, uses native APIs
React Native is often presented as a game changer that allows to run JavaScript code inside a mobile environment. Its main strength is that it doesn’t rely on Webviews like other competitors (Phonegap, Ionic, Cordova…), but on the actual real materials provided by the different platforms.
In other words, unlike Cordova, PhoneGap, and other cross-platform frameworks that render code via WebView, React Native renders certain code components with native API’s.
It has built-in access to all the native views and components, and to about 70 specific device APIs by default (you can extend it).
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 the iOS platform.
Uses existing compilers to create apps for specific platforms
Currently, there 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.
There exists many compilers for different languages and targets. React Native is built in such a way that it uses these existing compilers to create apps for that specific platform.
No only can React Native create apps for mobile platforms such as Android and iOS, it can also use compilers to create apps for Desktop, Virtual Reality, and much more.
How was it done?
React Native deals with two realms, the JavaScript one and the Native one. Both of them are able to share information. They communicate using a “bridge”, which is definitely the very heart of the React Native architecture, the part that offers so much flexibility.
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.
When two services written in different languages communicate, they do so by using interoperable languages, such as JSON or XML, and relied on an async protocols and a message queue. Service A pushes some commands inside the queue and service B has to execute these commands when possible.
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.
React Native behaves the same way. The JavaScript realm sends asynchronous JSON messages describing the action the Native part is supposed to accomplish.
For example, the JavaScript side will send information concerning the views that must be created by the Native side. When the Native side is ready, it will effectively create the views:
In React Native, the bridge endorses the message broker role, handling asynchronous commands between the two different worlds.
The bridge is built in C/C++ and thus, can be run on multiple platforms, OS etc…
It embeds the Apple JavaScriptCore framework in, which exposes APIs for your code to access the actual
Javacript Core VM capabilities.
With this in mind, React Native can inject variables, functions and declare globals to enhance the JavaScript existing code as shown at the first 3 steps here:
Then once the JS code is injected into the API, the C++ platform then queues them for deliver.
On the other side, you’ll see that we have our compiler/platform combinations. As long as the JS code is injected into the C++ platform, and then gets queued, we can switch out the compiler/platform like a puzzle in order to different type of apps.
Other advantages
– Maximum code reuse & cost saving. React Native’s component-based structure allows developers to build apps with a more agile, web-style approach to development than most hybrid frameworks, and without any web at all.
– If you know JavaScript, React Native will be easy to pick-up, allowing most front-end web developer to be a mobile developer. All you need to know is JavaScript, platform APIs, some native UI elements, and any other platform-specific design patterns and you’re set.
– Native look and feel of the app.
– Performance measurements between React Native exported app and the native app are very similar (https://medium.com/the-react-native-log/comparing-the-performance-between-native-ios-swift-and-react-native-7b5490d363e2)
– Native app development usually means inefficiency, slower time to deployment, and less developer productivity. React Native is all about bringing high speed, responsiveness, and agility of web app development along with effectual processing and best user experience to the hybrid space, to provide your users with a native app experience.
Disadvantages
It Lacks the Security Robustness
We know that React Native is a JavaScript library and open-source framework, which creates a gap in the security robustness.
But at times, you need to provide extra security specifically if you are creating banking and financial apps where data is highly confidential. So, in that cases, experts advice not to choose React Native.
React Native is Still New and Immature
React Native is newbie as compared to other Android and iOS programming languages. It is still in its improvement stages.
One of the areas where it lacks consistency is regarding the release of the frequent updates, which at times are confusing for the developers. This is because every time a new update is released, the developers have to make a lot of changes and make regular upgrades. Popular app Airbnb faced a lot of problems in the upgrading.
Latest Native code
Native developers are sometimes required to write the latest native code that we were not updated for that version of React Native.
Modules
Despite the constant advancement of RN technology, it does not provide ready-to-use modules that give access to iOS or Android APIs. This forces developers to create so-called Native Modules themselves or develop “bridges” using Java/Kotlin (Android) or Swift/Objective-C (iOS) and severely increases software development time. Native technologies require no such thing. The same goes for native frameworks, libraries or SDKs — if you want to employ Augmented Reality, voice assistants or SDK for mobile payments, again, you’ll need the aforementioned bridges. This will require you to hire three developers instead of two as it was in the case of Airbnb that had to learn about it the hard way.