React Native for MVPs

React Native is the right mobile tool for most minimum viable products (MVP). It provides a way to build for both iOS and Android platforms at once with a single code base. It can’t do everything but it can be a great starting point for most apps.

The most important part of building a new idea is validating it. The only real way to achieve that is by getting the product into users’ hands. The MVP is so important for a new app because it helps shape where the idea should go.

The initial concept of what a product should be is almost always flawed if not wrong. The goal is to find those flaws as quickly as possible and prove there is a company worth building on the back of the app.

It is crucial to remember that most code will be thrown away until an app is validated. It’s not that the code written is good nor bad; there just isn’t any proof the correct thing is being built. Any tool that helps reduce the time, complexity and cost of moving fast and making breaking changes to achieve validation should be considered.

React Native expedites the development of simple mobile experiences. It takes the same concepts that made React.js a popular web development framework and ports them to the mobile context. The code is written in Javascript and follows their component and state model for logic and interface. The key distinction is that the output of React Native is an actual native application and not a hybrid mobile web experience.

React Native suffers from some of the same problems as the React web framework. The node and Javascript environment can be frustrating to deal with. The community of libraries and dependencies aren’t always the best. Routing and navigation can be confusing.

With all that said: React Native is faster for building most interfaces for iOS and Android than building them separately. Changes are easier to make. Modifications to code during development yield instant recompilation of the app reducing the amount of time spent starting and stopping a simulator every time you make a change. The model for developing interface components makes it easier to develop for two distinct platforms. Concepts like viewing styling and layout collapse into a single concern instead of maintaining the logic of two.

React Native can’t do everything. The view model of iOS and Android aren’t always fully exposed. There is support for animations but it is limited. Designing custom gestures and specific experiences will prove hard or impossible within the confines of React Native.

Native components bridge the gap between what React Native can and cannot do. There is a framework for building native modules and native user interface components that works pretty well. The downside: native components require a native (swift, objective-c, java) implementation on each platform you’re deploying too and significantly increase the complexity of your app. Too many native components within a project erode the productivity of React Native.

An ideal React Native application is one with a fairly simple user experience with a small dependency on native components. We used React Native at Pocket Labs to build the Noken travel app. It fit the above prescription and we needed only one major native component for offline mapping. To get a sense of the interaction between native components and those written in Javascript take a look at the following screens:

The mapping component you see is a native HERE SDK implementation that had to be implemented for both iOS and Android. The directions, speed limit and ETA are shared interface components written in Javascript that listen for callback events from the native implementation.

React Native should be seriously considered for minimum viable products. It is a tool that makes a lot of tradeoffs but can potentially save a project a lot of time. Many underestimate the time and cost of developing (and maintaining) for two platforms simultaneously. My recommendation for most app ideas is to start with React Native, validate the concept and then get fancy in version 2 with custom user experiences.