Question: "Why create native mobile apps for iPhone and Android when the option for creating mobile apps that run in a web browser exists?"

Written by: Reinder de Vries, March 15 2015, in Programming, Q&A

There are a lot of different options, when you’re trying to pick a good platform to develop apps for. What if your audience is on Android and iOS? Then you suddenly need to create two apps! Working with middleware can be a good solution, in that case. But, why and how?

Let’s look at the options, and why going native or hybrid or web might suit you.

  1. Native means writing code native to the platform, so for iOS that’s either Swift or Objective-C, and for Android that’s Java.
  2. Hybrid means using a middleware solution that serves as a native wrapper around a (often) web technology based framework. Examples: Apache Cordova, PhoneGap, Appcelerator.
  3. Web means using pure web technology, effectively creating a website that is in fact a web application running in the browser. Examples: built with AngularJS, React, etc. combined with tools like jQuery Mobile and
  4. App editors, a fourth category, is basically a SaaS platform around one of the 3 categories above. Effectively, creating an app with pre-fab components and exporting that to a running binary and/or web application. Examples: App Machine, AppMakr.

I’ll focus on category 1 and 2 in my answer, because it’s the main topic of the original question. Category 3 and 4 could change the perspective for someone investigating which platform to use.

Native Pros: Performance
Native apps generally perform best, because they have direct access to hardware and memory. UI components are represented in a form that is native to the OS, so processing of graphics is fastest. Background processing, making use of hardware such as the accelerometer, and interfacing with external products like HealthKit, Bluetooth and low-level network is all possible. Native apps can be published in the App Store/Google Play.

Native Cons: Lots Of Work
A downside of native apps is that any app must be made once for each platform, effectively doubling or tripling the effort and cost involved. For bigger teams, and complex apps, overhead is created by needing multiple designs for multiple devices, and mediating between UI standards that differ from one platform to another.

Hybrid Pros: Less Work!
Hybrid apps can perform well, depending on the used platform. Many middleware platforms have good solutions for writing once, deploying twice, independent of the hardware. Wrapper libraries are created, giving a unform interface for functions that work different on the multiple mobile OS’s. Platforms like Cordova and PhoneGap have a very good support of all major phone OS’s. Needless to say, using middleware decreases the effort and cost to create an app for multiple platforms.

Hybrid Cons: Bad Performance?
Still, because they rely on the web browser and especially rendering of tree-based HTML, graphics are slow and clunky. Less memory is available and objects are often represented in a way that is not native to the platform, creating overhead and a strain on processing. JavaScript, often used, is evaluated and interpreted in a virtual machine, creating a barrier between the hardware and the app. Also, iOS apps in particular, must use the Safari-based web views and can’t rely on more advanced rendering found in Chrome for example.

Best Of Both Worlds
Never make a design or development decision only based on cost. Such a decision surely will bite you in the butt later on, because you didn’t consider the other factors that come into play. For instance: many developers I know, who work with middleware, don’t have a basic understanding of the separate platforms and their hardware. They build on sand, and often run into unsolvable platform-dependent exceptions — stuff that causes more time to be spent on creating the middleware platform, eating up the initial cost benefit.

How can you benefit from a middleware solution, even when going native?

Consider moving a part of your application logic to your back-end, effectively reducing the functionality each individual app has.

A simple example is date-time formatting, say for a news article. Don’t send timestamps from server to app, but send well-formated date-time strings. This will reduce the hassle of formatting the string in-app, once for each platform involved.

Another example would be, using a web view where possible. Take for instance the Quora app. They could have used a simple web view, instead of a native view, for the “answer detail view”. This would have saved them time creating a flexible answer detail view for each separate platform. For Quora, this surely would not have worked, their views are simply too complex. For a simpler app, optimizations like these are worth exploring.

What About Security? Is Native Safer?
Security was part of the question too, so let’s dive quickly into that. In general, native and/or hybrid apps aren’t more secure than one another.

Consider this: a web application is just like a car. The platform you use is the engine of the car. But, there’s the driver, the road you drive on (the internet?), traffic signs, the chassis, perhaps a passenger.

In terms of security, these are all systems and all have major drawbacks and implications for the safety of your product. The road can have holes in it, your passenger goes berserk, the driver passes out and OOPS now you’re missing a wheel.

A common mistake I see app developers make, is that they think their code is kept hidden from outsiders. Strings, or secret API keys, are visible when you reverse-engineer an app binary, and are often visible on the network when no SSL is used.

Of course, native code is compiled and cannot be fully reverse-engineered after that. Strings, method names, sometimes variables, can be. Hybrid apps use HTML/JS/CSS which is not compiled, so you could in fact read the original source code. Usually, this code is obfuscated, removing original variable and function names and such. All of this, doesn’t introduce any safety to your system: security by obscurity isn’t safe.

Good security relies on an intricate understanding of the used systems, and trust in those who build systems for you. There’s no need to understand how SSL works, if you trust that it is built well. Use common practice, such as using HTTPS, salting with HMAC, and shared-key encryption.

So, whether it’s choosing a platform or making sure your product is secure, make sure you’re informed and choose based on perspective, not on a single metric.

I’m guessing your next question is: where do I find a good developer?

Originally appeared on Quora.

Join 11.000+ app developers and marketers
  • Every Monday: get curated app marketing news, resources, tools and goodies in your inbox
  • Grow your app's userbase with the latest App Store Optimization and app marketing strategies
  • FREE: Get the free step-by-step Get Started With Your App Idea guide to set yourself up for App Store success!
Yes, Sign Me Up!

Popular Posts

Written By: Reinder de Vries

Reinder de Vries is an indie app maker who teaches aspiring app developers and marketers how to build their own apps at He has developed 50+ apps and his code is used by millions of users all over the globe. When he’s not coding, he enjoys strong espresso and traveling.

Get instant access to The Step-by-Step Guide: Get Started With Your App Idea

(PLUS: see the tool we use to save a ton on back-end coding)


Comments & Thoughts

On The Blog