“I want to launch a website and its mobile companion app. The application will be available on both iOS and Android. I heard that React Native would be a perfect fit for me. Is that true?”

There are two types of users. Those who use their computer to visit their favorite websites, and those — more and more numerous — who prefer to use these websites’ mobile application counterpart.

Facebook reported that a tremendous 74% of its users browsed the world’s largest social network on mobile in 2017.

With that in mind, as a product founder/manager, high indeed are the chances that you wish to deliver it to the largest audience possible: for both of these types of users.

But it gets worse, the mobile side itself can be divided into two even more competitive subtypes; namely Apple and Android.

Problem: the programming languages used to implement a website, an iOS application or an Android application are intrinsically different from one another.

So, what does that mean concretely? Well, if you implement your product for one platform, the code will not be “portable” to any of the other two platforms: most of it will have to be re-written.

In other words, this means that the cost of your product will (almost) have to be multiplied by the number of platforms you wish to support…

With the average price for a medium-size mobile application ranging from $200k-500k in most occidental countries, and about $50k-$200k for a website, you may wonder:

“Ok but, can I not unify those languages and implement my application only once for all platforms?”

“Learn Once, Write Anywhere”

React is an open source Framework developed by Facebook. Launched in 2013, it allows developers to create advanced web User Interfaces in JavaScript, based on reusable visual components (e.g. a custom blue Message bubble containing text content and timestamp in a chat). It can handle data changes over time without reloading the page.

React Native was also developed by Facebook. Announced 2 years later, it extends and brings the power of its older brother React to the mobile world. It is your mobile application that you will be able to write in JavaScript. The elements you manipulate wrap iOS and Android native relatable elements into one single React Native object, exposing a unified API (e.g. the React NativescrollView element is bridged into UIScrollView in iOS and ListView in Android).

Because React Native is built on top React, and because they both rely on the same language, it makes it possible for them to collaborate greatly in as varied areas as business logic and back-end integration for example. This means that beyond the aforementioned unification between iOS and Android offered by React Native, a bridge can now be created between Web and Mobile.

The Framework’s headline “Learn Once, Write Anywhere” is a play on Java’s “Write Once, Run Anywhere” and makes way more sense now: once you know JavaScript and the React set of tools, you are good to implement anything you want, on any type of platform!

“Ok, React Native provides me with one unified language, but you are still telling me that I need to write 3 different codebases? What is the point?” ‍

Well, React Native actually makes it possible to share a lot of code between iOS, Android, and web. And even if a significant portion may still have to be platform-specific, you may not need to hire any mobile native developer!

“Ha, that makes sense now! But wait, who should I hire in that case?”

The Ideal Web Developer Playground

As Seen by Native Mobile Developers

React Native brings a lot of modern tooling and features from the web to iOS and Android developers. This includes obviously deploying applications on both platforms with maximum code reuse and cost saving, the reactive paradigm as a core part of the Framework, as well as exciting stuff like hot reload (reload views instantaneously without having to wait 1 minute to re-compile the whole project).

There are however multiple non-negligible challenges for native developers to transition to React Native. After so much effort learning to master their native set of tools/language, and now that they feel they have good expertise, you are going to ask them to wipe most of it out, and struggle learning everything from scratch again — with a new complex and “hacky” approach that doesn’t use the official toolset (e.g. Xcode or Android Studio), nor is it recommended by the official guidelines.

Your developers will need to give up their beloved interface editors offering powerful constraints systems for the benefit of Flexbox, React Native’s way of doing UI layout, entirely programmatically.

Relatively new and not massively used, the Internet won’t offer much help on React Native when you are stuck with a bizarre bug — and there can be quite a few during your first weeks. This makes troubleshooting more bothersome, on top of not benefiting from the great debugging features they were so used to on their native IDE.

As Seen by Web Developers

React Native makes native development on iOS and Android accessible to web developers by writing native applications in JavaScript as the main programming language.

Because it also relies on a CSS-like styling language and XML-like declaration of UI elements, web developers will be able to take on the concept in no time. It will give them the ability to implement native mobile applications without almost needing to learn a new language.

Don’t also underestimate the fun and exciting aspect for a web developer to work on a native mobile application for the first time. See your creation compile in your hand, play around on a touch screen and happily reuse Apple and Android native UI elements — something web developers are not used to on browser. You do not get that exciting aspect when you come from a native mobile development background.

Uneven Transition Complexity

Transitioning from web to React Native doesn’t have any drawback really. It is more like extending one’s current web development knowledge in order to accomplish new/more things.

Transitioning from native development to React Native requires much more of a learning curve (and much less fun) than transitioning from web, to do pretty much the same thing. There are nonetheless examples of people adopting it successfully, even claiming they will never go back to native development anymore (read the excellent An iOS Developer on React Native article).

React Native bridges a gulf between mobile developers and web developers. It allows those teams to work together more smoothly and, although easier to transition to for web developers, still brings benefits to people on both sides.

So if your team is a mix of native and web developers, you still seem to be in the ideal configuration and you could even be able to reduce your need in the former over time. If your team is composed of web developers only, you may not need to hire any native developer at all. It appears to be tougher for teams composed of native developers only — but this is not impossible.

“Wow, that seems amazing for my web developers. What about PhoneGap and Titanium? I heard a lot about those foxes, are they any better?”

Competitors

Unlike PhoneGap and all other Cordova based solutions (e.g. Ionic), React Native does not produce a Web View based application. The JavaScript code is bridged into the native language, the end application is fully native. React Native comes with better performance and smoother animations.

PhoneGap’s showcase demonstrates a noticeable shortcoming in well-known apps. In contrast, the public list of apps that have migrated from hybrid/native to React Native is long (Facebook, Airbnb, Instagram, etc). At Fueled, we have seen many clients reach out to transform their hybrid app into a native one. It would certainly be quite challenging nowadays to find a high-end app that has moved from React Native/native to hybrid.

Unlike Titanium, React Native introduces the reactive paradigm to constructing component-based user interfaces. The application UI is simply expressed as a function of the current application state, greatly simplifying development of what can sometimes become complex state machines, as well as improving the readability of the code.

React Native also offers a superior debugging approach relying on Chrome or Safari’s console/debugger. It is better at helping you troubleshoot layout and view related issues by allowing you to nicely inspect UI elements.

React Native and Titanium are nevertheless very similar Frameworks. Both are written in JavaScript and produce native applications, both are fast and both have the ability to deploy on iOS and Android.

Unlike Flutter, React Native applications are developed in JavaScript. Flutter relies on a language named Dart, bridged into the corresponding native language like React Native. Dart is a rather verbose OOP language that will require your developers some time to get familiar with.

The recommended IDE for Flutter development is Android Studio, one of its greatest advantages making it possible to take advantage of its extensive toolset.

But Flutter is also known for being less competitive in terms of styling (there is no separation into styles, templates, and controller), laying out the views and implementing animations is more difficult, and there is no control on the application life cycle.

Much younger than React Native, Flutter still has a long way to go in catching up. While promising and providing with similar features, the developer community tends to agree that it does not currently seem to compete.

Is React Native a Tenable Option?

At Fueled, with one solid team of each iOS and Android developers, the choice between adopting React Native or sticking to native applications has been an intense and long-lasting discussion.

We strongly believe that beyond all evidence detailed above, this choice should be thoroughly discussed on a per-project basis. There are a number of significant implications to consider that influence this decision.

One of the strongest might be a client’s desire to use a consolidated technology, in which case you may want to push back if it sounds inappropriate—or find yourself bound by that constraint.

Another example, many clients with limited budget prefer to start focusing on one platform only—usually iOS and iterate again later on another platform if the product takes off. With React Native, although making it also portable to Android, the first phase of development would take more time for the same quality of deliverable and might be too expensive for the allocated budget.

For most of the projects we develop here at Fueled, we tend toward more rapid development in shorter iteration cycles, where our technical teams also already have a strong expertise in native development. In these cases, React Native would significantly impact our development velocity in the early stages of the project. However, for longer-term projects with larger codebases, where there is a potential (and desire) to share code across platforms (iOS, Android, and Web)—and especially where a team already supports deep Web expertise—it probably makes more sense.