React Native From the Trenches

At the start of last year Facebook announced React Native, a new mobile development framework that would enable developers to build cross platform applications using JavaScript which would perform as well as an app written natively. You can watch the announcement video here.

When Facebook first open-sourced the toolkit we immediately started playing and developing with this and began evaluating it as a tool for use in production environments. Rather than making a snap decision we have gone away and built a series of applications for clients as well as to demonstrate at events like Dreamforce so feel we can now comfortably share some of our thoughts on it as a development framework.

The Good

JavaScript FTW!

So firstly, the fact React Native uses JavaScript is a big win. JavaScript is fast becoming the dominant language for a lot of development and so being able to reuse existing language skills is a big bonus. Whilst we are also huge fans of Swift and Objective-C, the web-style structure of a React Native application makes it easier for our non-mobile developers to get up and running building mobile apps and provides a more project structure for development productivity.


Flux is an application architecture pattern from Facebook that works extremely well with both React JS and React Native in enabling a developer to compose applications in a more logical format where data flows unidirectionally throughout the system. Component based frameworks like React can become both unpredictable and slow if data flow within an application is not managed properly whilst using two-way data binding. Updating a single object can then lead to cascading updates within associated objects making debugging difficult and causing un-necessary work for the system. Flux helps to resolve this through a very simple pattern which fits very nicely for UI applications.


The biggest surprise for the team when we were working with the framework was how performant it was. The applications we have built are comparable in performance to their completely native counterparts written in Objective-C or Swift and do not suffer from any noticeable lag which can hamper many hybrid apps. The team at Facebook have also listed out some known performance issues, resolutions and information on what they are doing to work on this so you can see active development occurring.

The Bad

Active development

By far the worst thing about the current state of React Native is the instability inherent in its active development state. We have worked with a few versions and have found there always to be some minor tweaks or changes between the versions which need us to undertake some minor changes. Obviously this is destined to reduce further and further over time and as more and more of the initial work is completed but is just something for prospective developers to be aware of.

Needs More (Cross-Platform) Modules

React Native is fairly new and so it is understandable that there will be an initial shortage of available module for use. Obviously this will improve over time but is muddied by the iOS/Android vs JavaScript debate for how you deliver an item. You can extend React Native either with “standard” Node.JS JavaScript modules (for example we have used lodash in many of our apps) as well as modules written using Objective-C/Swift or Java. The more of these that are written in JavaScript the better long term as it will enable them to truly be cross-platform, but currently there are a lot of items written either only in Objective-C or just unavailable.

In Closing

Overall we are extremely excited about what the future holds for React Native given how well it performs already. It is an extremely robust framework and after a small initial learning curve we think enables anyone with a good JavaScript background to be able to effectively build performant mobile apps. Look out for some future posts in which we will dive into some more code centric examples.