What’s the Big Deal with Native vs. Web vs. Hybrid Applications?

on June 10, 2013

A place exists in the enterprise for both mobile and hybrid applications, beyond the native applications that you’ve used for several years. I’m speaking here of business applications; Angry Birds doesn’t count as business software even if you play the game while waiting to get through the security line for a business flight.

But first, what the heck is a “native” application and what are the main differences between it and a hybrid app?

First, let’s define what a mobile application is. A mobile application is software written for mobile devices (i.e. tablets or smartphones) that perform a specific task, such as a game, calendar, or music player. Seems simple enough, so what’s the deal with this Native vs. Web (or Hybrid) application all about? I’m glad you asked.

  • Native application: Software runs on the device’s internal software and hardware, such as iTunes on an iPod.
  • Web application: Software runs through a Web browser (Internet Explorer, Safari, Google Chrome) and relies on Internet connectivity to accomplish its task. If you ever accessed Gmail through a browser and sent a file, you were using a “web app” for Gmail.
  • Hybrid application: Software runs on a device’s internal software but utilizes Web connectivity to accomplish certain tasks, such as syncing contacts across devices. One of the more popular hybrid applications in use today is the LinkedIn mobile application, which is a great example of hybrid app development

Ok, that seems simple enough, so what’s the big deal?

Really, there isn’t one. There is actually a purpose for each of these architectures. When it comes to responsiveness and graphics (such as gaming), native applications are the way to go. Once the application initially loads (like the startup time for Temple Run (I hate those monkeys!) or Angry Birds) you are off on your own little handheld adventure. For the developer and the business, native applications are great because you can “maintain a presence” in an app store (like Apple’s App Store or Google Play) for all your clients to see.

So if I am a business decision maker, Native apps are the way to go, right?

Not necessarily – and most of the time, I would argue No.

(Please excuse me for the consultant waffling that is about to commence.)

One of the biggest assets of native applications (for businesses) is also one of its greatest weaknesses. Native applications typically store data locally on the phone or tablet, so if the device gets stolen or lost so does the data (unless they find your iPhone and intend to wipe it). The next largest issue / inconvenience is that they become hard to control or manage. For any of you familiar with my other posts (Google “software cost curve”), the main cost of software is not the development but rather the maintenance. If you are developing one application to run on Android, iOS, Windows, and Blackberry (to cater to all of your different users) multiply that cost by some number greater than one. Just to maintain one application (say a hospital check-in system) you would need four above-average developers (one for each platform) to develop and maintain the software. This is a huge risk to any business in itself, as employees can come and go faster than the lifecycle of an application.

In addition, you cannot control the frequency of when your users update their application by downloading the latest version from the app store. This means you may be stuck maintaining multiple different versions of the same application.

Enter Web applications and Hybrid applications. These solve these two core challenges immediately. First, since all data lives on the server, a lost phone does not mean lost data. Second, you can develop one application (that utilizes HTML5) which should (for the most part) work on all the different devices your organization aims to support. This also conveniently addresses the cost curve, because anytime a user “logs in” he is accessing the most up-to-date application. This means no more maintaining old apps, as everyone has the latest and greatest functionality. One development team can maintain the application for all users, regardless of device and operating system, and it can spend more time developing new features or debugging and less time on maintenance. So from a data governance and version management perspective, Web based mobile applications are superior.

Ok Mike, this sounds great: What about the web presence we want? We need our clients to find us in the app store.

No problem: You can achieve this too. Simply by using an application like PhoneGap to compile and “wrap” your application and login functionality, you can offer your application in an App Store.

So… What are you saying Mike?

A market will continue to exist for both Native and Web applications, as well as the combination thereof. Each has its strengths and weaknesses but the negative stigma toward one or the other is probably off base. Internet connectivity is improving (see LTE “revolution”) around the globe, but it probably will never be fast enough to satisfy the needs of the most hardcore gamer (or stock trader for that matter). (I think Facebook is partially responsible for this polarization between native and web because of its initial commitment to HTML5 and then subsequent back tracking.)

Ultimately, the decision to go with a native or Web-based application is not a good or bad decision; they are just different. It is more important to understand the requirements of the system you are trying to build and the needs of your users; then understand the strengths and weaknesses of each model and choose accordingly.

Is there a place for both Native and Web Applications in the future? What do you think? Which operating system do you think business will favor most? Let me know in the comments below.

  • Johan Groenen

    Native means that the app runs directly on the operating system of the device, whereas a web app runs within a web browser (which itself is a native app). A hybrid app is a web app packed inside a native web browser, which is stripped of most of the browser functionality. Has nothing to do with the storage location (local or remote), which in all three cases usually is a combination of local storage and remote storage.

  • Melle Sprenger

    I think your definition of “Native”, “Web” and “Hybrid” is over simplified. A native application can (and often does!) involve “utilizes Web connectivity to accomplish certain tasks, such as syncing contacts across devices”.

    In my world the difference between “native” and “web” is only one thing. The first one is written in the native language of the operating system (which could even be HTML5/Javascript, think Chrome OS or Tizen) and the latter is written in HTML5/Javascript and needs a browser component on the client side to run (think webkit or any browser that supports HTML5/Javascript).

    A hybrid app can be in a lot of forms but generally is written in HTML5/Javascript (but we could of course argue that a crossplatform .NET app is also hybrid). The app than can be compiled to an actual native app using native controls (Titanium does something like that… almost.. see http://stackoverflow.com/questions/7488002/does-titanium-mobile-convert-javascript-to-native-java-or-objective-c-compiled-c) or run inside a wrapper that is basically a stripped webbrowser.

    A very important point that is not in your post is that there is a big difference on the user interface level. choosing a “Web” solution means choosing a non native GUI on the platform (apart from, the HTML based platform i mentioned before) and choosing a native app means you can use the standard GUI elements that come with the platform. Titanium is the only platform (i know of!) that is hybrid in the sense that it makes it possible to use platform native controls from a cross-platform Javascript app. Creating a native app is choosing for the “platform first” approach and create an app that seamlessly fits on the platform the user choose to buy.

    There is also a matter of difference in performance (native=faster!) but i think that is not the most important argument, i know really slow and laggy native apps and some very responsive pure HTML apps.. i think there is a bigger dependency on the skills of the mobile developer there…

  • M_Guido


    Thanks for clarifying my over simplification. The key point of the article is still relevant to business / end users. Before stereotyping one application architecture as “better” or “worse”, it is important to understand they all have their strengths and weaknesses.
    The only way to choose the “right one” is to understand your functional requirements and if the inherent trade-offs of each architecture align with your organization(s) / applications goals.

    Thanks for your feedback!

  • M_Guido

    All excellent points Melle and thanks for the feedback!

    This is definitely an over simplification of Native Vs. Hybrid as I was trying to relate to a business user rather than a technical developer.

    However, the key message of the blog is still valid which is that there are advantages and disadvantages to both types of applications. For example, time to develop and maintenance for Hybrid / Web-based applications can be significantly faster while Native Apps can have better performance. I am not familiar with Titanium so I
    will have to check it out! Thanks for reading and providing your input!

  • Mandeep Pasbola

    Nice article, In the mobile world, terms like native app, web app and hybrid app are very common, Here’s a tiny bit of explanation. http://goo.gl/oEnqe8

  • Emmanuel

    Hi Michael, We have an customer panel, and we want an app for our customer, now i dont know wich one of Native or Hybrid can be good for us. Customer check balance and purchase online. So wich one its better for us in your point of view.


  • M_Guido

    Hi Emmanuel,

    Without knowing any other details, I would say a web application (browser based / hybrid) would be the best approach. This way you can automatically push updates to users (i.e. any time they log in, they will always have the most up to date application). It also depends on what type of payment processing system you are using (credit card, pay pal, square, etc.), but most have available APIs you can leverage within a web application.

    Thanks for the comment; hope this helps.


  • Siddharth

    Nice blog Michale, I want to add some points that i think should not be missed. There is no doubt that HTML5 will play a critical and dominant role in the future of app development. As the number of devices and interfaces continue to explode, developing native apps will become a crippling endeavor. Though some experts predict that in 1 or 2 years HTML will beat the native development, but I’ve been hearing such predictions for already several years. Here’s an article that perfectly articulates about Hybrid vs Native vs Web Mobile Applications and What is the way ahead?
    Read More About: http://bit.ly/1oWwO89