Why React Native Part Seven

How Does React Native Work?

The idea of “write once run anywhere” is not new, but on mobile it has often been an empty promise, or one with many compromises. However, React Native takes a different approach than many have in the past which is what we’ll be talking about today.

When I tell people that any app should start as a React Native app, I often get responses like, “But we want to have a native app for better performance and native UI.” I then reply, “React Native isa native app, it just allows you to write both iOS and Android with a single code base.” At which point I’m usually met with a smile, a nod and a need to explain further. The easiest way to explain this is to talk about a different type of mobile software: games.

Have you ever wondered how games can come out on so many platforms all at the same time? It’s not because they have multiple teams writing the same game in different languages for each platform. But, yet, that’s how we’ve been doing native mobile development for a decade now (except for most games, of course). You see, the typical way you write a game is to use an “engine” that handles all the platform specific details. That engine is written in the native platform’s languages and knows how to deal with all the nuances of its hardware and operating system. But the actual game code (i.e., how it plays, what images or models to display and where to display them) is done with a single code base in a common language. For Unreal engine, they use UnrealScript (a C based language) and for Unity, C# is the main language with a couple other scripting languages for specific tasks. The engine itself is responsible for taking that common code base and identifying when something needs to be converted to native, either for rendering to the screen or some other platform specific hardware feature. But most of the that common code can run on its own to handle the logical flow of the game without needing to interact with native components.

React Native works in the same way. JavaScript is used as the common language, but there is a React Native “engine” that runs on both iOS and Android that takes the JavaScript commands that require native rendering or platform features and turning them into native calls. When you want to put a view on the screen it’s a native view. Buttons, text? All native. Need to make a network call? Also, native. This is very different than apps that take advantage of web tech using the platform browser to simulate an app. In those cases, the browser is cut off from the rest of the platform by design and the rendering is web native, not platform native leading to a poor user experience.

At this point you may be thinking, React Native can’t possibly support every native feature on both iOS and Android. And you’d be right. New platform features come out all the time (or at least once a year) and although the React Native community moves very quickly, official additions are a bit slower. But, in the next segment we’ll see how React Native handles native bridging, and how easy it is to add your own native extensions to a React Native app.