The Mobile App Spectrum
Tags: mobile, app
Published: 2017-08-10 12:49:35

---
title: The Mobile App Spectrum
published: true
description: Types of Mobile Apps
tags: mobile, app
---

I'm a freelancer and at the moment I do mostly _mobile apps_. Often my clients don't have a real overview on the app technology they need or what is even out there. So I tell them about __The Mobile App Spectrum__, which is basically a non-exhaustive list of approaches that can be used to create mobile apps.

## What Clients Know

Most clients know about 3 things, but only two of them knowingly.

Often they tell me, they know there are _hybrid apps_ and _native apps_ and depending on their need to serve iOS or Android, or both, they tell me I should do one of those.

The third possibility, a _mobile web app_, isn't even on their radar. They see it simply as a website, and even tho they know and use websites as apps every day, they don't realize that their app could be like this too.

Also, they think "getting in the app/play store" is the main marker for something _being_ an app in the first place. I kinda understand the importance of these stores, because they are channels user know and use every day to satisfy their software demands, but often the app doesn't benefit from a listing in a store. For example, enterprise software where you sell via completely different channels.

## What's Out There

The multitude of app technologies is much bigger and nuanced than clients actually realize. Also, the reasons to choose one over the other are more diverse than "we wan't to be in the app store".

When I tell my clients about their possibilities, I usually call it __The Mobile App Spectrum__. I try to break things down to a one dimensional spectrum, where the extremes are __web apps__ and __native apps__. 

### Web Apps

On the far left, we have __web apps__, they are build with Web-technology entirely and run inside a browser.

They allow app delivery over web-servers, which is cheap, quick and gives you maximum control over this process.

They don't allow delivery over the stores, which could be very problematic or completely irrelevant, depending on your audience, but often they can easily be _upgraded_ to __hybrid apps__ to solve this issues when it arises.

I think 80-90% of all apps could be __web apps__ and which more and more features in the web platform, this number gets bigger every day. You can use 3D or make your app work offline. Android even allows you to _install_ these apps on the home screen, so they can behave even more like __native apps__.

The downside of __web apps__ is that they don't allow access of native APIs, so if the Web platform doesn't give you access, you can't do much.

Also, some argue that the DOM is really a performance problem, so rendering to it can lead to bad UX.

I'm coming from the Web to mobile, so I know the most about this approach. I prefer to do my apps with [React](https://facebook.github.io/react/), but there are is an endless stream of alternatives in this field, all with their up and downsides.

First, while the Web is mostly JavaScript at its core, there are many languages that compile to JavaScript. TypeScript, if you like C# like typing or ReasonML, if you're more into the whole OCaml thing. Even Rust or C can compiled to JavaScript, via Emscripten and I think with the dawn of WebAssembly there will be more in the future.

Then there are many many front-end frameworks. As I said, I use React, but there are more: Angular, Cycle.js, Vue.js, Ember, HyperApp, Mithril, ExtJS, YUI, Ionic, etc. pp. All with their strengths and weaknesses.

I can't say much about the developer popularity, because, like I said, there are too much ways to do it, and probably a few of them are really horrible and a few really wonderful.

### Hybrid Apps

Then, right after __web apps__ come the __hybrid apps__. They are build mostly with Web-technology too, but they bring their own browser like runtime. It's a shell that gives you access to the OS APIs.

They allow app delivery via the stores AND over web-servers. Since they are just web-apps running in a shell, you could take your web app and stuff it into one of them.

Also, if you don't need the OS APIs you can go the other way around and port your __hybrid app__ to __web only__, if you found out that no-one uses your app via the stores anyway.

They seemingly suffer from the same performance problems __web apps__ do, since they use basically the same technology. I can't confirm this, to me the Web always seemed fast enough, but what do I know ;)

The main implementation here seems to be [Cordova](https://cordova.apache.org/) and there are frameworks like [Ionic](http://ionicframework.com/), who build on this technology, but [The Stack Overflow Developer Survey 2017](https://insights.stackoverflow.com/survey/2017#technology-most-loved-dreaded-and-wanted-frameworks-libraries-and-other-technologies) says __only 38.8% of all developers love it__.

Side note: Since these app types are running inside a browser, you aren't tied to Ionic, but can use whatever web framework or even compile-to-JS language you like.

### Nativish Apps

After the __hybrid apps__ comes what I would call __nativish apps__. They are also __hybrid apps__ in the sense that they use web-technology and that they have a runtime environment, but they don't use the whole palette of web-tech.

They aren't like web-apps that run in a browser, but try to use as much of the native stack as possible. The idea is, that they present the developers with an interface they know from the Web. You get a modern JavaScript engine with APIs like fetch, WebSockets and also CSS. The reason for this seems to be mostly performance. They want to deliver constant 60fps to be faster than __hybrid apps__.

At the moment there seem to be two implementations of this approach, [React-Native](https://facebook.github.io/react-native/) and [NativeScript](https://www.nativescript.org/).

While there are efforts ([React-Native-Web](https://github.com/necolas/react-native-web), [ReactXP](https://github.com/Microsoft/reactxp)) to allow these apps to be ported to the Web, at the moment they're bound to the native realm. So delivery mostly happens through the stores.

The Stack Overflow Developer Survey of 2017 only says __66.9% of developers love React__ and has not much to say about React-Native of NativeScript.

### Compile-To-Native Apps

There are also ways to create native apps without writing native code, which I would call __compile-to-native apps__. They don't use any web-technology, but kinda do their own thing.

Like back in the days, with the Google Web Toolkit, where you could write Java and it would compile to JavaScript. Here you can write in a language that compiles to binaries that can run directly on iOS or Android, without the need to learn Objective-C, Swift or Java, but also without any knowledge of web-technology.

They come with consolidation wrappers for respective native APIs to flatten the learning curve.

Their goals overlap mostly with those of the __hybrid apps__ and __nativish apps__. They want to give developers tools they know, this time the tools just aren't Web tools and they want to run on different platforms, without much reimplementation.

Since the results of __compile-to-native apps__ are native apps, you have to deliver them through the stores and not the Web.

The main implementation here seems to be [Xamarin](https://www.xamarin.com/), which allows the use of C# and even allows to compile for Windows.

The Stack Overflow Developer Survey 2017 says __only 48.7% of all developers love Xamarin__.

### Native Apps

On the far right we have __native apps__, they are build with the respective technology the platforms offer. On iOS it is Objective-C and Swift. On Android it's Java and probably all JVM languages like Kotlin, Scala and co. They can leverage all the native APIs from the get go and often have superior performance to the other solutions. Most people would even argue that their UX is better in any case.

I guess the fact that Android is Java based and a bit more open than iOS leads to more flexibility in development. There are multiple languages out there that were specifically designed to run on the JVM, so there aren't many extras needed to create a __native app__ for Android in Scala or something. Google even announced to make Kotlin an [officially](https://developer.android.com/kotlin/index.html) supported language for Android.

The iOS way is rather strict and gives you Objective-C and Swift, which were both created by Apple.

Since they are completely made of native code, they are delivered via the stores and don't run on any other platform.

Their main down side is, they are per definition not cross platform.

Because both platforms are rather different, it's hard to say much about their developer experience.

The Stack Overflow Developer Survey 2017 suggests people like Swift much more than Objective-C and more people like Scala than Java, but that's about it.

## Wrap Up

There are many approaches to get your app ideas on mobile devices, each of them with their up and down sides. I think, 80%-90% apps are so generic they don't need to consider much of the technical implications.

The important questions are often more non-technical.

How do you monetize your app?

Where does your audience search for your services?

What kind of developers are available?

Do you think native UX would bring you more customers?

Do you already have a web app, that could be optimized for mobile usage faster than implementing a new one?

All these are things to consider.

---

If you know different approaches I forgot, please let me know in the comments! :D