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, 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 and there are frameworks like Ionic, who build on this technology, but The Stack Overflow Developer Survey 2017 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 and NativeScript.

While there are efforts (React-Native-Web, 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, 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 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