App Wars, Episode 2: The apps empire

There are 5 main types of apps you can build in 2016. Do you know them all? More importantly, did you know there’s a bit of a war going on between the two main factions?

One one side, there are native apps. On the other, web apps. Both sides would love to dominate the app world. Both sides have created first and second generation players.

This series of blog posts wants to introduce you to each type of player so you can pick the right one for your project.

TLDR; Try our cool candied nibnut app to help you decide!


In this episode, I introduce you to the world of native apps, those you install from an app store. They are like the desktop apps of old, except they run on our smaller mobile computers.

Native apps

Native apps are the first generation players of the native camp. They were born with the iPhone back in 2007, and have taken the world by storm.

Some examples: Pokémon Go, the web browser you use on your mobile phone, or your chat app.

For it

  • Access to all the bells and whistles of the device.
    i.e. Camera, GPS, contact list, …
  • Can do Push Notifications.
    Those little messages you get even when you’re not using your phone. Think Facebook “New message” notifications. Fabulous user re-engagement tools!
  • Speed
    Native apps are packaged as machine-readable code (compiled) and they run directly “on” the operating system. No middle-man – or is it “middle-app”?
  • Very good visibility for your brand.
    Once installed your app is visible on the device’s home page, all the time
  • Unlimited local data
    A native app can easily store “unlimited” amount of data directly on the user’s device. However, it should be noted, if your app stores a lot of data on the user’s phone, it could be one of the first ones to be deleted when the user runs out of space for pictures, videos, and other stuff she prefers…

For it – kinda

  • Unique, “native” look.
    Back in 2007, web apps could not emulate the look of a native app. Nowadays, it’s much easier to have a web app look like a native app. (we’ll talk about the native app “feeling” later, though)
  • Security.
    Again when things started, the web was mainly http (not secure) so by comparison, apps were little Fort Knoxes… But since, there has been a few instances of corrupt native apps, and now the web definitely is going https all the way. Things are pretty much leveling off.
  • Optional internet connection.
    In theory, a native app requires no internet connection once it’s installed. However, most apps these days chose to require network access at least part of the time. For instance, more and more apps now include social sharing capabilities. You won’t be able to share anything on social networks without an internet connection.

Against it

  • Development time and cost.
    You will need to build one app per platform you want to support. (Apple devices, Android devices, Windows devices, …) This increases both costs and development times.
  • Multiple versions to support.
    Users are not always using the latest version of your app, and you can’t really force them to upgrade. So you have to support older versions for a while.
  • App store approval process.
    Some app stores review your app before it is made available to users. Reviews can take days, or weeks. And you might not be approved, which means you’ll have to go through this again, once you fix the things you were told to fix. And, you will have to go through this once per app store, i.e. once for each platform you support.
  • Installation (!)
    Some studies show we are getting so spoiled, even the 5-10 seconds it takes to install an app from the app store is becoming too long for our short attention span… It probably doesn’t help that native apps have exploded in size in the last few years, taking longer to download and install.
  • Remote data storage is extra.
    If you need to store some data remotely, outside the user’s device, that’s going to be another piece you need to build and maintain. Or at the very least, you will need to subscribe to some online database service. Either way, it’s extra cost and/or development time.
  • Limited to mobile.
    If you want your application available on desktop computers, you’ll need yet another version of it – web or desktop. Your mobile version can not be used on desktop directly.

Hybrid Apps

Hybrid apps are the second generation player on the native team. Nobody likes duplicate work, and clients sure don’t like having to pay extra to support more platforms.

So great minds are actively working on an “esperanto” development language, one you could use to build our app once, and then compile it for as many platforms as you want.

It’s a grand idea, but the early tries were limited by technology. They were nothing more, really, than a native app shell to package a web app into. Users saw right through the smoke and mirrors, and rejected the gambit.

Newer frameworks show real promise, however, truly creating native apps out of one single code base. But it’s still a bit early to claim victory yet.

A hybrid app by definition should look and feel exactly like a native app. So unless a developer announces she has built her app using a hybrid framework, it’s nearly impossible to tell just by looking at the final product.

One well known example I can highlight is Facebook. They are behind one of the very promising hybrid framework, (React Native) and their app is built with it.

A hybrid app will have nearly all the same pros and cons as a native apps – with a few differences:

For it

  • Cost and development time.
    Because you now code only once, for as many platforms as you want, you save a great deal of time and money.

Against it

  • Higher maintenance costs.
    The hybrid code tends to be a bit more complex than regular native code because it needs to support different devices. Also, it might be a bit harder to find a hybrid app developer, and so their rate could be a bit higher.
  • Access to bells & whistles can be limited.
    Because you are now trying to support a bunch of different devices all at once, you either have to code for the lowest common denominator or to make your code a bit more complex so it adapts to the device it is running on.

Ok! Now we know the native camp’s players. Join me next week next Thursday for a description of the opposite camp: the web.