Choosing the right technology for your mobile app

Say you’re a business owner and you want to get a mobile app built.

You get in touch with a few mobile app development agencies. They throw some technical jargon into the discussion. They can build your iOS and Android apps using the latest technologies: “React Native”, “GraphQL”, “NodeJS”. Maybe you’ve heard these terms before. The cool kids like Facebook are using it, so it must be good!

It’s useful to take a step back to understand exactly how mobile apps are made. I’ll only talk about Android and iOS platforms, since they cover about 100% of mobile devices. I won’t discuss the topic of games, which are generally built with different technologies. I also won’t cover the topic of servers and databases, which are another can of worms.

Get ready to learn the difference between:

• native mobile apps
• Xamarin apps
• hybrid web apps
• hybrid native apps
• progressive web apps

Before we start, one important point: “Java” and “JavaScript” refer to two separate languages. Don’t get confused when I refer sometimes to Java, sometimes to JavaScript. They’re about as close as “car” and “carpet”.

Native mobile apps (Java, Swift)

A native mobile app is written in the platform’s official language: - for Android: Java or Kotlin - for iOS (iPhone/iPad): Objective-C or Swift

Notice that there are actually two languages for each platform. That’s because Java and Objective-C are rather old languages (Java appeared in 1995, whereas Objective-C was created in 1984!). Apple created Swift in 2014 in an attempt to make life easier for developers. Google didn’t create Kotlin, but they chose to support it officially in 2017. Using older languages isn’t necessarily a bad thing—they’re more stable (Kotlin and Swift are still evolving, so your code could stop working later) and they don’t run slower.

As you can see, if you want both an Android and an iOS native app, your developers will need to be familiar with at least two languages.

Your developers will also have to understand the APIs provided by both platforms. What’s an API? It stands for “Application Programming Interface”. An analogy might help. The mobile device is a body. Your mobile app is the brain. The API is the set of nerves that let them talk to each other. Without it, your application is incapable of doing anything. Unfortunately, Android and iOS apps are built in very different ways, so their APIs are completely different.

In practice, most native app developers are specialised in either Android or iOS. When you hire an agency to produce native mobile apps, they will likely use two separate developers (or more). You will also end up with two separate codebases, one for Android and one for iOS, each with their own bugs.

Native Xamarin apps

Xamarin is a Microsoft technology. It solves one problem from native apps: the language barrier. Developers can use a single language (C#) to build Android, iOS and even Windows apps. Sounds great, doesn’t it? Unfortunately, they didn’t go as far as solving the differences between the APIs of each platform. I won’t blame them, it’s an impossible task. But you won’t get two apps for the price of one. Developers will need time to make it work on each platform, although they will be able to reuse some of the code.

In terms of performance, a Xamarin app is equivalent to a native mobile app.

Hybrid web apps (Ionic, Cordova aka PhoneGap)

Early on, people got frustrated with the need to build a separate app for each platform (Android, iOS, and back then, Windows Phone and BlackBerry). Someone had a neat idea: what if we just showed a webpage that looks like a mobile app? This was the start of the “Write once, run anywhere” philosophy.

Ionic and Cordova let developers write web pages that are specifically designed to be embedded into a shell mobile app. They have access to features such as the camera, notifications, etc. They’re written in JavaScript and HTML5, the same languages that any web developer uses nowadays. That’s good, because web developers are much easier to find (and therefore cheaper) than Java, Objective-C, Swift or C# developers!

One major issue with these hybrid web apps: they can be slow, especially on iOS devices. Scrolling through a long list for example can feel jerky. Mobile apps are not optimised for displaying web pages. Facebook had to abandon this approach in 2012.

Disclaimer: the last time I tried building a hybrid web app was quite a few years ago. I’ve heard from other developers that performance has improved a lot since then, so they may be worth trying out, especially if you want a solution that also works on the web and/or on desktop apps.

Hybrid native apps (React Native, Weex, NativeScript, Titanium)

Hybrid native apps are a newer category. They still use JavaScript, but they no longer show a webpage to the user. Instead they use native code for the interface, which mostly solves the jerkiness issue.

To make that work, they require a “bridge” between the JavaScript and native code. The bridge can be quite slow in older hybrid native frameworks such as Titanium. These apps may feel too laggy for a user’s taste.

Fortunately, newer frameworks such as React Native (by Facebook) and Weex (by Alibaba) have solved the lagginess issue thanks to a concept known as “virtual DOM” which reduces the amount of data that needs to go across the bridge. In general, you won’t be able to tell that the app you’re using is not native.

Although these hybrid apps are branded as “native”, I personally find the term a bit deceitful: parts of the app are indeed native, but it’s controlled by JavaScript, which is generally not as performant as native code. Yet, it is good enough for most apps.

React Native and Weex are spreading like wildfire because they are based on React and Vue, two major web technologies. This means that a lot of web developers are now starting to build mobile apps. Exciting times!

Progressive Web Apps (PWA)

Last but not least, progressive web apps make up a separate category. They are mobile websites that can be installed on your phone and become an app. They are somewhat revolutionary because you don’t even need to visit the Play Store to install them. They can do most of the things that “normal” apps can do, thanks to the powerful features of HTML5. But they are still websites, so they will not always feel as smooth as a native app.

One caveat: right now, progressive web apps can only be installed on Android phones, so it’s not a viable solution for iOS. However, there are strong rumours that Apple will soon allow it too.

Flutter apps

This list would not be complete without mentioning Flutter. It’s an open-source project backed by Google which uses a completely different approach from everything else I’ve mentioned so far. It uses the Dart language, which is compiled to low-level native code to ensure high performance. It renders the interface with its own hardware-accelerated technology, so it doesn’t suffer from the same issues as web-based apps.

While Flutter is a promising technology, it’s very early days and as far as I know, no major Google app uses it.

Choosing a technology

Now that we’ve looked at the different types of mobile apps, which one should you choose?

It’s hard to say, but here is my own opinionated guide:

• Start with a hybrid native app, ideally based on React Native or Weex. They’re easier and faster to build than native apps. You will benefit from a fast-growing population of developers and a strong ecosystem.
• If you really care about performance, build a native app, but start with a single platform (Android or iOS). It’s a lot faster to iterate on one native app than two. Remember, each app will have its own code and therefore its own bugs. There is no such thing as an app with no bugs.
• Avoid hybrid web apps (Ionic, Cordova) unless you want to also release your app as a website. Hybrid native apps provide a smoother experience overall.
• Keep an eye on PWAs. Once Apple devices support them, they will be the new rage. They may also be cheaper to build than other types of mobile apps, since they’re just websites.
• Don’t use Flutter. It won’t be mature for a while and it has a very small developer community.
• I don’t know enough about Xamarin and its community to give an informed opinion. So I’ll give you an uninformed opinion: don’t use it.

Keep in mind I'm writing this in January 2018. Technology moves quickly :)