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 Development

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
  • Get a weekly curated list of app development tools, articles and resources in your inbox
  • 10x your app installs with relevant App Store Optimization and app marketing strategies
  • BONUS: Grab a free copy of the App Toolbox 2017 to supercharge your next app project
Yes, Sign Me Up!

Most Popular Content

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.

Got a killer app idea?

Grab the App Toolbox 2017 to learn how to save time building your app,
and how to 10x your app installs in the App Store. With the toolbox, you'll immediately know how to move forward to build better, more profitable apps.

Get The App Toolbox

Comments & Thoughts

Leave a Reply

Markdown is supported (Learn more). Your email address will not be published. Required fields are marked with *

On The Blog

  • Onboarding: Effective Strategies To Get Users On Board
    Onboarding: Effective Strategies To Get Users On Board

    October 6 2015, in Marketing

    An effective onboarding strategy makes sure your users get the maximum benefit from your product: it ensures no one trips and falls, and keeps arms and legs inside the vehicle at all times. How does that apply to your app?
    Learn more...
  • Doodling With Swift 3: The Read-Eval-Print Loop
    Doodling With Swift 3: The Read-Eval-Print Loop

    September 15 2016, in Development

    Everything apps isn't all Swift, and everything Swift isn't all Xcode. You can code in the Swift programming language without Xcode with a compact tool called the "REPL". Ready to doodle in Swift?
    Learn more...
  • What Are The Best Tips And Practices For Creating Mobile Apps?
    What Are The Best Tips And Practices For Creating Mobile Apps?

    May 24 2015, in Development

    When learning programming or design, where do you start? It’s tough as a beginner, knowing that there’s much to learn in so little time. And when you’ve learned a new topic, how do you know whether you’ve truly mastered it? To shed some light on learning how to create mobile apps, I’ve set out 9 different places to go, people to meet and tactics to keep in mind.
    Learn more...
  • The 2-Day Weekend Project Plan: Make Your Ideas Thrive
    The 2-Day Weekend Project Plan: Make Your Ideas Thrive

    August 16 2015, in Development

    Making your own apps is a challenge, and often aspiring coders make the mistake of not planning properly. They get caught up in the high of a great idea, but that motivation quickly burns out by the time they're facing the first real challenge. Here's a project plan that will definitely help you out. It enables you to move from idea to execution quickly, and test the idea in the meantime. Go go go!
    Learn more...