Native apps vs. Web apps: The great debate Pt. 2 of 3

native 2

So you’re back for more after part 1?  Great.

Firstly, some admin.  Much like making an app, this series is going off project scope: the planned two parts have become three.  Also, I didn’t have space to delve deeper into the last post as asked.  That will happen in part three.

In this post, I’ll focus on how the native/web app decision affects product development and business model.  Then I explain a hybrid native-web app option.  Read on.

FYI: I assume you are developing your product iteratively with feedback from user testing.  If that’s not true then the next part doesn’t apply to you (and good luck – you are hopefully some kind of user/customer scryer).

Product Development

The great advantage of a web app in product development is speed.  Updates are simply pushed to a central server.  They can be seen instantly on any device.  User feedback (and measuring through analytics) can begin.  What’s more, because a web app lives on the server (and not on your device), you can guarantee that all your users are using the same version.  You see the effect of changes on all your users immediately.  Great news, unless you’ve created a bug.

Native apps, however, are more cumbersome.  Updates need to:

  1. get through the relevant app store approval process
  2. become known to your users
  3. be downloaded by your users

You have to wait for all that before you can get user feedback.  Indeed, even before you release to the app store, a native app is not as simple to share with others, especially those outside your project team.  (Although longer-term it’s worth adding that native apps do have app store customer reviews, web apps don’t.)

Business Model

How much is a native app?  I guarantee you my answer is within £/€/$1 of yours.  App prices are more standard than shoe prices.  They are a known quantity that can be planned for.  What’s more, app stores already have customers’ credit card details.  Customers go to app stores expecting to spend money.  These days, even in-app purchases and freemium models are understood and accepted by most.

How much is a web app?  And is it a once-off purchase or a monthly subscription?  And why would someone give up their credit card details to a website they happened upon via Google?  Pricing web apps is more complex.  Although this means there is more scope to experiment, and, as there is no mental ceiling (‘you paid $5 for an iPhone app?!?!), users may be willing to pay more once convinced.  (And, unlike a native app, you won’t have to forfeit 30% of your revenue to an app store.)

How to pretend your web app is a native app

The best of both worlds?  Well, not exactly but there are clear benefits.

Hi, I’m PhoneGap.  I’m like a UN interpreter.  I’m a C2 in web Esperanto (aka HTML5) and the language of pretty much any other phone you care to name.

OK I’m stretching the metaphor, but you can use something called PhoneGap (check out the video) to make your web app seem native.

A PhoneGap app is developed like a web app: one* set of code, written in web Esperanto, and interpreted by PhoneGap for each different mobile platform.


  • access to the camera, microphone, calendar, and other native device features
  • no need for a new set of skills to develop for each type of phone (you can use the same developers)
  • changes can be made in one* place (you don’t need a different set of code for your native iPhone app and your Android app)
  • You get instant updates, just like a web app

Also, customers find you via an app store (discussed above).

As it is not really a native app, there are some issues:

  • Load time is higher because the app is not stored on the device
  • It won’t be as responsive as a native app (remember you’re speaking through an interpreter)

Summing up

So a web app probably takes the prize on product development, but is a more risky proposition on business model.  You can try to get the best of both worlds with PhoneGap but there are still compromises.

In the next post, I’ll sum up the story so far.  Then, I’ll add a few technical layers for those who’d like to see under the hood.  As always, leave your thoughts below.

* Sadly, it’s not that simple.

Featured Photo Credit: Nimbuzz via Compfight cc. Text and recolouring by eltjam.

11 thoughts on “Native apps vs. Web apps: The great debate Pt. 2 of 3”

  1. Hi Lindsay

    With Phonegap, is the load-time and responsiveness of the APP noticeable (i.e. annoying) to the end-user? Or is this dependant on device and connection?

    It seems like a really good solution if you need to trial an idea on more than one platform or keep budgets in line …

  2. Thanks Lindsay for a map of the terrain on this developing area. As a pseudo-techy I appreciate getting the descriptions in plain language before you head into realtech details. Until I get my hands on a functioning web app, it’s hard to assess how off-putting the clunkier response will be. Are there any good examples you might point us to? Looking forward to episode 3 and that techy challenge when it comes. Bring it on!

    • Glad you like it Jim. The obvious place to start is by checking out Twitter or Facebook on your phone’s browser. The Facebook’s web app has no ‘talking heads’ when you get a message for example. It’s worth noting that those two companies can afford to make their web app user experience as good as possible, so that’s a best-case scenario.

  3. Thanks for this. I understand web app (needs internet connection, easy to update) vs native app (can be used when offline, more difficult to update).
    But what about web app vs website?
    For my (Work-In-Progress) project I am going to be uploading eLearning content direct to a WordPress website. The content is being produced in Lectora, and published from there as HTML rather than published to a LMS. The WP site design will be the front end that the user sees, and then I will ask my WP developer to set up the dashboard so I can easily upload the HTML files produced by Lectora.
    The WP site will display in any browser, as usual, and bar a few HTML5 style tweaks re layout according to screen size, it will look exactly the same on mobile, tablet, laptop, PC, Apple, Samsung, Microsoft. Just a regular WordPress site. It will be ‘mobile friendly’ or even ‘mobile first’ only to the extent that I’m keeping all the fonts etc really large.
    This gives me simplicity and ease of changing and updating the content – very important for the early days.
    Now I have found out about sites like UppSite that convert a regular website into an app. I have no idea how well they work. An UppSite app can be placed on an app store, sold there, or offered to users direct from a website. Would this then be an example of a web app? It still needs an internet connection (eg to pull in content from YouTube or from other web pages in an iFrame) but it displays as an icon on a smartphone and opens on the phone like an app, not like a website in a browser.
    I hope I’m right – it would be a very good solution for me.

    • I can point you in the direction of apps that use PhoneGap, is that what you mean? I don’t know of any apps that have both a PhoneGapped version and a native version so as to compare them. The Facebook app uses some HTML5 (though they’re too big to bother with an off-the-shelf product like PhoneGapp), though less so than before. I have a discussion about this I’ll post below for all.

  4. Hi Niall,
    Yes it is noticeable. The degree depends a lot on what the app does. Data-intensive apps (like a radio app) will need to get data over the internet whether they are native or web apps. They won’t slow down much. Processing-intensive apps (like games) slow down a lot if they’re a web app. (I agree that it’s a good solution.)

  5. This is like the hybrid option, the PhoneGap app. It’s a web app (or regular website) displayed in a native app box. Bear in mind that it sounds like you’re not starting with something that fits the (admittedly loose) definition of a web app. It sounds like a series of connected pages rather than an integrated one-pager. See part 1 of this series for more details.

    I am not familiar with Uppsite but I would be wary of anything claiming to simply convert code. From what I can gather though, it doesn’t convert code. It merely wraps up whatever HTML you have into a box to be sold in an app store and saved on a phone (as a reference, not on the device itself).

    I think it has potential for your problem as you describe it. I’d try the free version (and make sure you don’t give away an IP in doing so) and see how it responds.


Leave a comment