https://www.google.com/trends/explore?date=today%2012-m&q=react%20native,iOS%20swift

Has React Native replaced Native?

Being an iOS developer, I was quick to judge React Native and consider it another inferior and elementary way of building mobile applications. Obviously, an app won’t feel native if it was written in JavaScript, I thought, but what I was overlooking has become the most advanced cross-mobile solution to date.

As you can guess, when React Native was released and received a lot of hype, I hoped the platform would quickly fade. It’s possible I was just worried about my job security, as JavaScript programmers were now able to develop native applications, but I think the issue went much deeper; I was afraid that it would allow for a new wave of apps that didn’t quite feel native or natural.

After playing and creating with the platform for almost a year, I have come to enjoy its development patterns, most of its styling techniques, and even composing views in code. This raises the question, has React Native replaced native mobile development?

What has UIKit done for me lately?

When iOS opened the App Store in 2008, it unlocked development to a world we had not seen before. But as the years added up, Objective-C and iOS development patterns started to show their age. Auto-layout and MVC, the primary iOS development pattern, generally pigeonhole developers into creating massive, bug-filled ViewController files. Of course, writing in Objective-C locked the app into the iOS platform and as Android users quickly outpaced iPhone ones, this became a huge pain point.

React and React Native have essentially one development pattern; a uni-directional data flow through components. It takes a few sample projects to adopt, but it has fundamentally changed the way we build views. Now, we can reason about what a view should look like based on its inputs because the components are functional and deterministic.

In addition to solidifying a new pattern for mobile development, React Native has connected mobile development to the large JavaScript community. To manage dependencies, we now have NPM. For more functional array manipulation, we now have ES6 and lodash. The list of solid open source JS projects far outnumbers Objective-C’s open source community and now mobile developers can leverage it.

Native development has such slow development iterations. To change something as simple as a color on the profile page of an app, you need to recompile, run, navigate to the screen, and finally verify the change. React Native shakes up the workflow by needing only to build the app once and then reloading the JavaScript each time a change is made. No more waiting for compilation. In addition, React Native includes hot module reloading, which allows developers to save a file and instantly see visual and logic changes without resetting the app’s state and requiring the developer to manually navigate through the app to verify state. These are the tools of the future. (I don’t even have time to get into Redux and time-travel debugging)

Okay, what’s bad news?

What is stopping everyone from writing every new app in React Native? First, while Facebook and React Native’s open source team have done a great job at implementing solid interfaces with Apple and Android device APIs (e.g. Push Notifications, gestures, camera, etc.), many APIs still aren’t completed. If your idea for an app requires audio, video, a microphone, bluetooth, or geolocation, you will need to rely on a third-party solution or implement the feature in both Objective-C and Java as well as create the interface.

Next, since React Native is still maturing, updates to the package generally have breaking changes and require a good bit of refactor. You might ask, “Why not just stick with the version you started?” Well, if Facebook releases a new interface you need or a third-party package you really want requires a newer version than you have, it’s possibly time to bite the bullet and follow Facebook’s guide to upgrading React Native.

When it comes to mobile development and especially iOS, navigation is an enormous part of the user experience. It suprised me to find that React Native’s Navigator is actually more challenging to implement than either native iOS or Android. This is a known pain point within the React Native community. Facebook is shifting to another Navigation component called NavigationExperimental, which appears to have solved a lot of the issues surrounding Navigator. With that kind of component name what will your CTO say when he reviews your next pull request?

Questions to ask before using React Native

Are your users expecting this app to reflect their mobile operating system’s unique design guidelines (e.g. Human Interface Guidelines, Material Design)? If so, can you still reap enough benefits by using a cross-platform solution? Each app would still have the same development patterns as well as shared business logic and network requests, but is that enough to justify writing two visually different apps within the same directory?

Does your app require any device features (e.g. 3D touch, geolocation) that React Native does not support yet? If it does, are you comfortable using an open source third-party solution or writing the interface yourself?

After thinking through the layout of your app, do the current navigation solutions in React Native meet your needs? This question may require some prototyping before answering.

Concluding

React Native is a legitimate cross-platform mobile solution that creates apps which can be indistinguishable from native apps. As it enters the mobile development sphere, it brings with it improved patterns, innovative tools, and a vibrant community. While it may not be the platform which you build your next app, it is certainly a part of the mobile development future and deserves to be evaluated as such.