Coronavirus latest »

Weighing risks against benefits of React Native in the enterprise

Few can deny the excitement generated in the mobile development community by React Native’s promises of productivity and multi-platform. Indeed, a veritable flood of apps created with Facebook’s recent brainchild now appear to be landing in the app store.

Understandably, then, discussions proliferate as to whether React Native is already mature enough to be considered as the basis for enterprise applications. Citing a research report from IDC’s Al Hilwa, ADT recently communicated that React Native is “still maturing and unlikely to be suitable for enterprise adoption until late this year [2016].”

Maturity, of course, is likely to be of greater concern to the enterprise than it is to an individual or a small team, for whom updating to – or reverting from – the latest patch release on a library or tool impacts no-one other than the party doing the updating. Maturity is also a subjective concept and corporate executives are understandably more risk averse than hungry developers, keen to try out cool new stuff.

Still, if there is any truth to the claims that productivity might be increased three- or fourfold (six- or eightfold if targeting a second platform), then would it not be wise for the enterprise to consider the technology despite any adolescent imperfections?

According to Gartner, large enterprises may want to develop as many as 100 apps per year by 2017. So with the vast majority of enterprise app developments costing in excess of $50k, a doubling, tripling or more increase in productivity is worth some investigation.

Objective C vs. React Native: Comparing Developments

In 2014 enterprise app-specialists RNF Digital Innovation completed development of Calor Gas’ first ever tablet app. The app replaced a long-standing laptop-based solution and has been in constant use by its salesforce since the full-scale rollout was completed in early 2015. The app followed best-practice techniques and fully embraced Apple’s proven architectural and design guidelines.

In a parallel undertaking, RNF had begun conducting experiments with React Native. This commenced with a non-trivial prototype followed by a full-blown app aimed for the app store.

Later in 2015, RNF was commissioned to create a second application for Calor, this time targeting the needs of another division of the salesforce. Interestingly, though business requirements were different, scope and complexity were on a par with the first-generation app so, with a few man-months of experience behind us, we elected to implement Calor’s next-generation app using React Native.

This decision was not without risk. First of all, React Native had until that time only ever been showcased on iPhones. Would the team burn up hours trying to make it work on the larger device? With split views and rotation ominously missing from React Native’s components and APIs (they remain missing at the time of writing), would the team be able to make up for these and other missing features?

Just as importantly, how would developers, now with years of hard-won Objective-C and XCode experience behind them, approach a new language and an entirely different revamped tool chain? Finally, what other bugs and surprises lay in wait in this nascent technology, barely weeks into its first public release?

The Showdown

The similarity in scope and complexity between Calor’s original app (Apple tech) and the app now constructed using React Native provided us with an excellent opportunity to measure the relative productivity of the two approaches. But before presenting the results, an observation:  React Native is first and foremost a framework for developing user interfaces. From the developer’s perspective, the languages at play here are JavaScript (more accurately, ES6) and JSX. When working in this environment, it is natural to develop the app’s business logic in ES6, resorting to Objective-C only when necessary (which wasn’t often in Calor’s case). Apple’s standard approach to UI design and layout is called the Storyboard – a graphical depiction of the UI plus a WYSIWYG editor, for which there is no equivalent in React Native. The approaches to UI development could not, therefore, be more different.

Aside: Reusing Existing Business Logic
Suppose a team has spent months developing a reusable library in Objective C for use across a suite of mobile apps. Does switching to React Native imply that this work has to be done again? Fortunately, React Native provides helper classes, which make it trivial to integrate any existing (non-UI) Objective C code. In Android, business logic written in Java can be invoked in the same way.

Table 1 presents the core tools employed in the development of Calor’s first and second generation apps.


App #1
Standard Apple/iOS Tech.

App #2
React Native


Objective C





Unit-Test Framework



Static Analysis


ES Lint

Table 2 presents a comparison of the relative productivity encountered with the two applications.


Average Features / Developer / Day


App #1
Storyboard, Objective C

App #2
React Native, ES6





× 3.18

Business Logic



× 1.86

In both apps #1 and #2 the UI/BI logic split was around the same at 50%. So across the board it is fair to say that the introduction of React Native resulted in a two- to threefold increase in productivity. These figures will obviously vary significantly depending on the enterprise’s circumstances. However, for RNF the lesson was clear: Though app #2 involved learning a new technology, as well as having to implement work-arounds for still-missing components, the developers ended up significantly more productive. The end product itself has proven solid as a rock in terms of runtime stability.

Sources of the React Native developer’s productivity

For the traditional iOS (and Android) developer, seeing the effect of a change means building, running and then clicking through the app to the point where the change was introduced. In large apps it is not uncommon for this to take several tens of seconds, possibly minutes. Any more than a few seconds’ delay inevitably results in lapses in concentration, which costs the project yet more time.

With React Native, “hot reloading” means that a change to the code automatically updates the view – typically in under a second.

The second big contributor is simply that there far less boilerplate code to write. ES6 is noticeably more succinct compared to Objective-C (or indeed Swift, Apple’s modern replacement for Objective-C). Less code means quicker code reviews, less debugging, smaller tests and, ultimately, easier maintenance.

Finally, React Native’s architecture, its declarative approach to UI, its predilection for placing related code in the same file, plus its emphasis on functional programming all make for software that is more deterministic and hence more reliable than the standard approach.

Accumulated over weeks and months, these factors add up to big gains which, as RNF’s results reveal, can end up outweighing the technology’s relative immaturity by some margin.


As always, executives need to balance risk with potential gain. However, the productivity gains experienced at RNF, as well as the potential for an incremental introduction of the technology, suggest that, for some enterprises at least, significant productivity gains are already available for the taking. Now may indeed be the time to React.