And why you should consider frameworks like React Native when creating a mobile first product.

You’re an entrepreneur or project manager trying to see if a technical decision is right for your business, but what’s the most cost effective way for your engineers to build a mobile product?

As a lead JavaScript developer at Cogent, I’ve found that React Native offers the best balance of engineering cost and user experience for mobile app development. It’s just one of many options however, and the differences to your business can be confusing. Lets go through the options for mobile development, and the implications for your next product idea.

Is everything an App?

The word “App” has entered the public consciousness in a way that software installed on computers never did. Even the least tech savvy user now understands how to install software applications (“Apps”) to do each thing that they want their mobile device to do.

The main characteristic of an app for most people is that it’s embodied by an icon on their phone screen, which they click on to open it and do whatever it does. They typically expect to acquire and update it via the App Store.

Example app UI design. Image: DesignzMaz

Example app UI design. Image: DesignzMaz

What about mobile friendly websites?

Websites can be just as complex as any piece of software installed on your own device or computer, and are usually referred to as “web apps” by software developers. These web apps can be designed to look great on mobile screens. Most companies need them to look good on computer screens too, and so looking good on mobile either means a separate version of the site, or using “Responsive Design” to allow a single user interface to change size and shape to look good on both computer and mobile screens.

Mobile users opening such sites on their phone typically have a much less frustrating time using your site than if you don’t design for mobile. However, if you ask them “Is this an app?”, they’ll typically say “No, it’s a website”.

Example web app UI design. Image: Flatfull

Example web app UI design. Image: Flatfull

So, what’s a native app then?

Apple (iOS) and Android phones both have technologies for building software applications intended to sell in their app stores. Together, these two types of phones represent over 99% of all phones globally. Globally speaking, Android is the most popular, with about 86% market share, but in the USA, it’s closer to neck and neck (53% Android, 45% Apple).

Each of the two platforms use a different programming language, framework and tooling. Android apps are written in Java, and iOS apps in Swift or Objective-C. More difficult to learn than the language though, are all the application libraries and tools needed to make the phone do all the things the app needs.

So, when we say “native app,” we typically mean a piece of software written in one of these environments, and thus running only on one of the two major mobile device types. Since most businesses can’t eliminate half the market, that often means having two teams of programmers with different skills building two different apps for the two different platforms. Needless to say, this is expensive.

I don’t want two different mobile products. Can’t the web help?

If a user is basically happy with a mobile friendly website, but wants something they can install via the App Store and gives a pretty icon on their phone dashboard, then why not just ship an app that opens a browser window and displays your web app (often called a Web View)?

This was the first approach used to avoid building two different native apps. It’s not just small companies on a budget that wanted to do this, many big players were worried about the problems of native apps too. Facebook, for example, built their app as a bundled up mobile web app, not because they couldn’t afford to have two code-bases, but because doing so wouldn’t let them move fast enough at rolling out new features across all platforms.

This sort of approach is sometimes called a “Hybrid Mobile App”. It works well, and products like Ionic or PhoneGap can be used to bundle up a web app into a fully functional mobile app you can list in the App Store.

The problem

The trouble with bundling up a web app, is that it can’t do everything that a phone can, nor does it entirely look like a phone app. Each phone has a lot of native user interface widgets that work efficiently and the user expects to see. Web apps, built in HTML, are always going to look like web apps. Promised functionality to allow the web to interact with the mobile, such as touch events, the camera and photos, contacts, maps, etc, didn’t quite eventuate.

“The biggest mistake we made as a company was betting too much on HTML5 as opposed to native.”
– Mark Zuckerberg

Facebook famously had to switch back to native after trying the above technique for a while. Does that rule it out? No, it’s still an affordable option to get something to your users, particularly if you have to have a mobile friendly web app for your business anyway. But for a feature rich app experience, it’s just not going to give good enough results.

Even Facebook initially built their app as a mobile web app to be able to roll out features faster, but eventually switched back to native. via GIPHY

Write once, build native

If each native platform needs code written in it’s own language, can we code a single product in a single language and then have some magical software convert it into separate native apps for us?

There are two basic approaches to this. Microsoft’s Xamarin allows you to build apps in one language (C#) and then it compiles them to the language of each of the target platforms. Microsoft has invested heavily in cross platform mobile tooling, because as less than 1% of the global market for mobile devices, no one is going to build apps for just their platform alone.

A slightly different approach is used by React Native (and Native Script). Instead of generating code in the native language, they keep your code in the normal language of front end web development, JavaScript. Don’t mistake them for the hybrid web apps we discussed above though. Although they run JavaScript on your phone, they don’t display any HTML, they use the JavaScript to manipulate native widgets like some sort of puppet master. This gives something very close the user experience you’d expect from a truly native app.

Puppetting the mobile

If you look at blog posts categorising mobile apps, React Native is often said to produce hybrid mobile apps, and so it gets compared to Ionic and PhoneGap. While the word hybrid is certainly apt, React Native works so differently from the HTML based hybrid app options, I’d like to think of it as different class instead, with it’s main characteristic being the way it plays puppeteer to the native interface.

The way that this works in practice is that the phone runs your JavaScript code in another thread. If your JavaScript decides to make the header bar change colour, it sends a message to the main native app thread, saying “the header bar should be red now”, and the native header bar widget changes it’s colour to red.

This is only different from truly native mobile in a few areas.

1: Performance

Having the phone interpret JavaScript is going to be slower and more resource intensive than code written in the native compiled language. This is generally not a problem, because your app doesn’t sit there running code the whole time. Usually it only needs to do something every now and then in a response to the user. However, if your app is constantly processing data, then don’t use React Native. This mainly describes computer games, which should be native, but might also be an issue for specialist medical devices or other sensors.

2: Animation

If you want to animate something with React Native, you have two options. You can either tell the native widgets to perform some animation that they already know about (there are plenty of these available for standard widgets and transitions), or you can compute an animation in JavaScript and tell the native widgets to update themselves very regularly (i.e., about thirty times a second). The latter approach can be a little slow. There are ways around this, but it should be said that highly custom animations are one of the high risk areas of React Native development and you may run into challenges here (although they can be solved).

Mostly, but usually not quite, a single code-base

Mostly, but usually not quite, a single code-base

So, I can write one app and ship it everywhere?

Well, maybe.

Facebook is careful to characterise React Native not as being “Write once, run anywhere”, but merely “Learn once, run anywhere”. The idea is, even if you need to write different screens for iOS and Android in order to enable the correct native widgets, you at least do so using the same programming language and framework, so you can do so with a single development skill-set.

Actually, this characterisation is very conservative. React Native apps almost always are “Write once, run anywhere”. I’ve worked on four of them now, and all maintained a single code-base for both platforms. In fact, React Native also runs on Windows phones, and supposedly on Facebook VR.

Where the platforms needs are different, it’s usually possible to hide the differences within a component usable on both platforms. For example, AirBnB (which uses React Native extensively) released a map component which displays a Google Map on Android, and an Apple Map on iOS.

So, the end result is often a single code-base with a few exceptional bits of custom code for each platform. Testing on both platforms from day one really helps get this right.

What are the risks?

Developers are likely to want to use React Native because it provides a pretty great developer experience, and is very easy to learn, but no tech decision is without risk.

The biggest risk is that either Apple or Google might decide to no longer allow apps in their stores that run JavaScript. Both specifically allow it at the moment, but if it was a minor niche technology an about face on this could be a concern. However, it’s now in use by many major players in the App Store, not the least of which are of course Facebook and AirBnB.

The next concern is the chance that it’s simply not possible to puppet native widgets to do something you need to do. The solution here is that React Native apps can include custom native components. Some apps have found that certain screens or widgets simply couldn’t be built in React Native. In that case, you can always built that part of your app in a truly native way, which of course requires developers who know Swift or Java. So far, I haven’t needed this escape hatch, but it’s good to know that it’s there.

Summary

Here’s my opinionated breakdown.

  • Separate native mobile apps give a good result but having multiple code-bases is both too expensive and too slow for fast-moving companies.
  • Mobile friendly web design is very important for all websites, but users won’t consider this to be “an app” and you won’t hook them into your product in the same way.
  • Hybrid mobile apps using a Web View are a cost effective way of getting a primarily web business onto mobile, but have a lot of limitations for complex apps.
  • React Native provides the best balance of development speed and user experience for mobile app development, and is now battle tested and production ready.