React Native: Is it the end of native development?

Novoda has a reputation of building the most desirable apps for Android. We believe living and sharing a hack-and-tell culture is one way to maintain top-shelf quality.

People see React Native as a write-once-deploy-anywhere solution, potentially speeding up development for applications that need to be written for both iOS and Android and making it possible for Web Developers to easily write native applications, but is React Native the best choice for your next project?

What is React Native

React Native is a native version of the popular web library of the same name and its main purpose is to bring the power of React to native development. React Native components are pure, side-effect-free functions that return what the views look like at any point in time. For this reason it is easier to write state-dependent views, as you don’t have to care about updating the view when the state changes since the framework does this for you. The UI is rendered using actual native views, so the final user experience is not as bad as other solutions that simply render a web component inside a WebView.

How we investigated React Native

The best way to evaluate a new technology is to use it. We gathered together a team of four developers native in programming iOS and Android, to plot, scheme and research React Native. Here was our action plan:

The source code of the Twitter Client we created, both for iOS & Android, is available in our Spikes repo:

Costs of React Native

Project Setup

The documentation about setting up the testing environment is very poor, and mostly outdated. Consequently, we spent 4 days until we were able to run all of our tests successfully. While it’s true that we didn’t have any prior experience on running JavaScript tests, we found the amount of effort to set up the test environment outrageous. There were other setup quirks as well, mainly caused by incompatibility issues with different versions of the framework.


The recommended IDE is Atom, with a plugin on top of it, Nuclide, which adds support for React Native development and for its recommended static analysis tool Flow. While it might be a good editor in general for JavaScript development, we found it to be far behind compared to IDEs we are used to, like Xcode and Android Studio. For instance, there is no support for even the most basic refactors, this could potentially slow down the development speed.


As native developers we found the learning curve of React Native pretty high, as it may take up to a month until one could start feeling comfortable developing with this framework. For someone who is already familiar with JavaScript development, Redux, flow layouts and maybe even React, it is much faster to get up to speed with React Native.

Native coding

There are certain features that cannot be implemented solely in JavaScript, native code is needed for:

Overall approximately 80% of the code is shared between iOS and Android and written in JavaScript.

Hot Reloading

Hot Reloading is similar in concept to Instant Run on Android. Every time a source file was saved, the changes were deployed immediately on the device where the app was running, thus greatly expediting the feedback loop. Although it works better than Instant Run, it still breaks from time to time, requiring a restart of the app.

3rd Party Libraries

We cannot deny the fact that many times we have to resolve the same problems as others did before us, and that’s why we decide to make use of third party libraries, so we don’t have to reinvent the wheel. Whereas there are plenty of libraries to chose from on iOS and Android, we cannot say the same about React Native. There are definitely a considerable number of libraries, but as we experienced, some of them are not always working as expected.

Release cycles

One more thing worth mentioning is that React Native has a two week release cycle. While it is good that they bring more features and push the framework towards maturity, often they bring breaking changes as well, maybe in a “move fast and break things” fashion specific to Facebook. These changes sometimes where a burden to overcome, as we had people spending a lot of time fixing things when upgrading the framework. But we can’t deny that this isn’t expected, as the framework has yet to reach a stable status, still being under heavy development.

Cost Saving - the numbers

With these pros and cons, the state of the tools, the lite documentation and uncertainty of libraries as it is in the present, we feel that by using React Native you can actually save some time compared to traditional native development. In particular, according to the developers we have interviewed, on real projects one could save around 30% of development time. Of course this is just a high level estimate and depends on multiple factors, the most relevant is to have person with web-development knowledge in your team, as discussed previously on this article.

Why Choose React Native

At this point, you might think that React Native is another “write once, run anywhere” framework, like Titanium or PhoneGap, but you would be wrong. As Facebook very clearly states on their blog post, they acknowledge the differences between platforms, so instead, their goal is to bring the paradigms of React, which is very successful on the web, to native, while having the same set of engineers working on whatever platform they choose. They call this approach “learn once, write everywhere”.

How React Native actually works is by embedding the JavaScript files in the app, and running them locally. But also, one could have these files remotely on a server fetching their latest version when the app has connectivity. This would allow updating an application very rapidly, without having to go through the app store’s review process. There are also third party services that offer such solutions, and using them potentially could mean that for smaller applications that don’t have a lot of data to display (e.g. festival apps), a backend isn’t needed anymore.

Most of the coding is based on JavaScript and the paradigms in React. Thus, it makes more sense that a typical team working on a React Native application is composed mostly of JavaScript engineers, because ideally those will be already familiar with the tools and paradigms used by this framework: React, EcmaScript, Redux and Flex layout.



Starting to work with a new platform like React Native, one of the first things we did was to explore the available documentation, both official and from the community. We found that, while Facebook is putting effort in keeping it up to date, a good amount of the components are not well documented for the current release of React Native. This is even more evident if we consider community-created articles, given that these are often obsolete after a few releases of React Native.

Core React Native library

When the documentation wasn’t satisfying enough we tried looking up things in the React Native source code, however we found ourselves disappointed by the poor quality of code base. Probably in a rush to push more functionality to the framework, they also sometimes overlook how clean the code is.

Speaking about the core React Native library, we found many of the main components being still in a Work-In-Progress status. The official documentation regarding how to implement some key features (like navigation) changed the suggested component in different releases of React Native. The migration from one to another of these components is not a straightforward task and it requires some not-negligible work.

Third-party components

Of course it is possible to use third-party components, but the selection is not comparable with the number of community-generated libraries that we can find for iOS or Android. A big problem with these components is also the fact that the compatibility and support is not guaranteed with future React Native releases.

Native SDKs update

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, but the priority is given by the amount of requests that every API gets. It can happen then, that some new features will be included in the next React Native release, while some others are not going to be included at all.


We found that a good use case for React Native can be found in applications that need short time support, for example an app for a one-shot event like a concert or a conference. These kind of apps could also benefit from the fast release cycle available if dynamically loading part of the application logic from a remote server.

However after our month-long investigation we can definitively say that React Native is not a mature or stable platform yet. For this reason, and what we highlighted during this post, we think that React Native is not ready to be used in a long-lasting supported application. This does not exclude the possibility for it to be used for other kind of apps, having the right team including the right level of JavaScript expertise. React Native seems to be suitable for apps with simple UI, simple animations, and not long life or performance-critical apps.

The demo app we created is completely open-source, and it's available at

For more Novoda open-source project, have a look at

About Novoda

We plan, design, and develop the world’s most desirable Android products. Our team’s expertise helps brands like Sony, Motorola, Tesco, Channel4, BBC, and News Corp build fully customized Android devices or simply make their mobile experiences the best on the market. Since 2008, our full in-house teams work from London, Liverpool, Berlin, Barcelona, and NYC.

Let’s get in contact