6 Reasons why you should be using react native

May 2017

If you're a front-end engineer this is a good time to be alive! React Native lets developers create real, native apps, using JavaScript.

Previous to this, us front end engineers had options like PhoneGap and Cordova. In essence, these technologies just wrap your web site into a WebView and package it up as an app. You'll get access to some native features with these technologies, but you'll never be able to build an app that actually feels or performs like a real native one.

In the past, we had to wave goodbye to JavaScript when we wanted to create 'real' apps. React Native is the future of mobile development, and here is why you should be using it:

1. Code consolidation

Building an app for the web, iOS, and Android is a tall order. You'd need to learn 5 different languages (HTML, CSS, JavaScript, Objective-C (or Swift), and Java) and also become familiar with new build tools and package libraries for these platforms. Nobody got time for 'dat.

With React Native (RN), you can share all of your business logic between mobile platforms, and you'll also be able to share most, if not all, of your view logic between the two. You can even share JavaScript code from your web app with your RN app (e.g. via an NPM package or a git submodule). This means that you only need to fix bugs in one place. Glorious!

Where you want iOS and Android screens to look different, you don't need to use if/else statements, like you would with a hybrid app, instead, you would just name your iOS specific components as something.ios.js and your Android specific components as, and RN will serve up the correct screens for each platform.

RN abstracts away the differences between iOS and Android, leaving us to concentrate on one single API. If you want to stick some images in a scrolling view, you don't need to know how to load images on iOS AND Android, or what each platform calls their scrolling view element.

It's as simple as this:

    <Image source={{uri:''}}/>

On top of that, if there is a major OS release and the look of the UI changes (e.g. from iOS 6 to 7), your RN app will be golden. If you're using a hybrid framework and mimicking the native UI, you'll be in a whole world of hurt when a change like this happens.

ios ui change between ios6 and ios7

2. Easy Layout

The styles applied to RN components resemble CSS, and Flexbox is used for layout. You're probably already familiar with Flexbox so will be able to leverage those skills. Crucially, you won't need to learn the layout specifics of Android (composable containers) or iOS (Auto Layout) and will be able to easily create screens that work on multiple device sizes, in both horizontal and portrait orientation. You're able to share layout solutions across platforms and reduce the time spent on fixing platform specific layout issues.

A lot of UI frameworks couple their layout tightly with rendering, which often means that the layout engine runs on the main thread. By decoupling the layout engine - called 'Yoga' - RN is able to run it asynchronously. Happy days.

3. Hot Reloading

The build time for native apps is relatively slow. If you want to fix a typo or move an element a few pixels to the right, then waiting minutes to rebuild your app is really frustrating, and terrible for productivity, too.

RN apps rebuild very quickly and, with hot reloading, you'll see the changes on your simulator/device in under a second. Yes, it really is that quick.

To top it off, on hot reload your app's state will persist. So if you're trying to fix a bug that is a few screens deep, upon reloading, your simulator device will still be in the same state and you won't need to perform a set of actions to get back there.

4. Code pushing

One thing really going for hybrid apps is the ease with which you can update the app. They are just websites, after all, so changes are immediately reflected on client devices.

Releasing a new version for a native app is more of a chore and much slower: it currently takes about 2 days for Apple to review app changes (i.e. for a native app).

With RN, as long as you don't need to link to a new component (e.g. you don't suddenly start using the native map, for example), you can push updates over the air. A hidden benefit of this is that your app version remains constant, and you won't be left with zero reviews on the app store, for your new version.

5. Performance

React Native vs hybrid app performance

Hybrid apps can only use one thread and can't make use of native components; RN is the clear winner in terms of performance when pitted against a hybrid app.

React Native vs native app performance

You may think that a native app would be more performant than a RN app, however, this isn't necessarily the case and it depends on exactly what you are doing. In this article, comparing a Swift app vs a RN app, we see that the Swift app has slightly more efficient CPU utilisation, however, the RN app wins in GPU efficiency (and therefore has a higher frame rate, which is really important for a good feeling app - it's the most important metric for me) and also memory usage.

The three threads

With React Native (RN) we specify which native components we want in a screen of our app. The component is declared in JavaScript and this bit runs on a dedicated thread - the JavaScript thread. Next, communicating over something called the 'Bridge', RN tells a different thread - the 'Main/UI' thread - what native elements it needs to render (and passes along any relevant data at the same time).

The device needs to calculate where to place all the elements, and it does this in a third thread, using Facebook's layout engine: Yoga.

Having three threads is powerful and one thing that I really like is that your business logic runs on your JS thread, leaving the main UI thread free.Native apps can become unresponsive when a long-running task blocks the main UI thread.

How the three react native threads work with the bridge

6. React Native for other platforms

One of the USPs of React is its virtual DOM. On the web, React renders components to the browser's DOM. However, the virtual DOM can render to anything and vanilla React Native renders components to UIKit in iOS or to the Android DOM.

Although Facebook is primarily concentrating on iOS and Android, there are other platforms you can currently build for (note: some of these are forks of the RN branch)

Disadvantages to using RN

While I think the benefits outwiegh the drawbacks, your mileage may vary. The biggest disadvantages to RN are:

  • 1 Month release cycle. Things break! And, you also need to watch out for 3rd party libraries breaking at the same time (Expo is good for protecting against this - it's a framework around RN and is definitely worth checking out.).
  • When the iOS or Android SDKs are updated, it takes some time for React Native to integrate these newly introduced APIs into their core library (The React Native team is pretty fast to update in order to allow developers to use new APIs)
  • Potentially harder to debug as there are more moving parts and there are 2 states: Native and JS
  • The debugging tools aren't as good as native environments.


I bet my house that the future of mobile development is with RN. It's easy to pick up and it's so quick to create apps with it.

What are you waiting for? Get stuck in.

stupid cat
Please enable JavaScript to view the comments powered by Disqus.