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?
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.
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”.
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 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.
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.
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.
This is only different from truly native mobile in a few areas.
So, I can write one app and ship it everywhere?
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 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.
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.