A Primer on Differences Between Mobile Web Apps and Native Apps

2 Replies

The other week, we got question about a new mobile app that had been released:

In a nutshell, he describes it as a web-based app, not one that goes on [iTunes App Store] or Android Market [now named Google Play Market]. I’m not familiar with this, how it works, what are the advantages, and more importantly how average mobile phone users would cope with buying and installing something that is not on an app store?

The line of questioning isn’t surprising given the context and some of the quirks that are involved with dealing with apps outside of the context of an “app store.” I unpacked this for that person, and wanted to also share that here as some context to help some of you out whom are looking at creating a mobile app, and are sitting on the fence about whether you need to write one that appears in an app store, or go the approach of a website that acts like an app.

Web Apps Versus Regular Apps
Web-based apps are dependent on the capabilities of the web browser, and utilize a programming methodology called AJAX which allows for sections of the screen to update without needing to refresh the entire page. Web apps geared towards mobile, at least in terms of more recently (I’ll ignore WAP and Flash for now), push that methodology a bit by using JavaScript libraries to activate device and platform specific features. Libraries such as PhoneGap, jQuery/jQuery Mobile, Sproutcore, and others basically make it easier to turn any webpage into an app suitable for some mobile devices given some work (there are also content management systems that assist in this process).

It can be assumed that regular (native) apps don’t need a web connection, but that is not always the case (though there is a prevailing opinion that if the app requires a data connection to simply be used, then should it have been made an app at all). Web apps traditionally start from the web browser on the mobile device, though some might allow a stub to be pinned to your homescreen to go into it faster. Regular (native) apps are also more likely to have richer interactions, graphics, or audio since it would not rely on the stability of a data connection to serve assets needed for it to work.

Discovering the App
The main issue with any app is being able to find it when you are looking for it. With the rise of smartphone-centric app stores (iTunes App Store in 2007 and those which came after), you’ve basically got a situation where if you do one of these web apps, that you have to create a “wrapper” for it, created using the native coding language of that platform, so that you can add the necessary information (metadata, etc.) for it to be hosted in an app store.

That tends to be more expensive, and so the route for many mobile web apps is to use the app to replace the literal mobile website, in this way the URL, any existing SEO, etc., and casual linking, allows the visitor who is coming from their mobile device to kind of stumble into that mobile web app. Its a decent philosophy, however it can be difficult to get people to wrap their heads around the fact that what’s in your browser can also be an app (Google, Financial Times, and even a beta web app at MMM push this).

One of the things that some mobile app content management systems do is in addition to helping you build the website, you pay an additional fee to have that website published as an app in one or more app stores. This fee is because some app stores require the developer/content producer to pay to be included in their listings, and is usually a yearly cost. The good thing is that these content mangement systems tell you exactly what you need (in terms of description of your app and any graphics) in order for it to appear in those app stores in the best light.

Advantages/Disadvantages
The primary advantage for web/mobile web apps is that you are outside of the rules and conditions of app store philosophies. In this age where some are getting acquainted with limited/restricted communications, its a smart approach for faith-based groups who are in regions, serving regions, or have a potential future implication of being too far from the policies of app stores and/or regions to have a presence that might be hosted locally in additional to international-straddling methods like an app store. Other advantages include the ability to push out updates on your own schedule, more granular analytics (many folks are using Google Analytics, which are very good for this kind of work), and no need to install anything for the user (the just need to save the bookmark or “pin” the bookmark to their device’s homescreen).

Disadvantages, therefore, are pretty easy to come to light.

1: Creating a mobile web app means that you either aim for the better mobile browsers (as [redacted] did), or take the time to code for all of the browsers specific to the audience and people whom would be utilizing this application. That’s not just specialized knowledge, but also coding savy of a unique kind (recently, a Wallmart web developer spoke to this). Mobile web apps will work differently across devices because of what capabilities the browsers have. Android, Windows Mobile (not Phone), and Symbian are very guilty of this as their browser implementations vary widely. There are some programming helps here, but these are new to the scene and aren’t as widely implemented as these devices have been in service.

2: Discovering the app is difficult without some suitable marketing behind it.

3: Web/Mobile web apps require connectivity for some/most of their functionality. Very few web apps are utilizing the HTML5 feature which allows 10-50MB of browser cache to be used to “store” the app (and only a portion of the latest smartphones are able to use this feature. If [redacted] is doing this, good for them. If not, then folks would essentially be reloading the app (therefore using whatever data services they have or don’t have) each time, at the cost to the user, apart from any cost to access that app/site.

Buying/Installing and Concerns for the Average User
Like I mentioned above, the average user will only know that its a web app versus a website when they are notified that it is such. Many times, this is done with a tool-tip bubble when you get to the page (there are a number of WordPress theme which do this), or maybe some kind of notification on the screen in a high-visibility area. If the URL/address bar goes away and it goes full-screen, that’s another way to know that you are in the web app versus website territory. If there is no notiication, you are relying on the user knowing that they can do this – which isn’t necessarly the best philosophy.

There’s nothing to install. At least, there shouldn’t be. If you need a plugin to use a mobile web app, then its being done wrong.

Purchasing would be akin to signing up for a subscription to a secure area of a website. Here, the developer would have to navigate SSL certificates, HTML5 local storage, and use by going directly into the web app, versus coming in through some kind of sign-in screen. The Kindle Cloud Reader is a good example here as its essentially a self-contained website, but if the session cookie has expired, or you have made a purchase that’s yet to be reflected in Cloud Reader, you’ll get a screen asking you to reauthinicate/login again, and then the new content downloads and is available to that mobile device. Key to this is what Amazon does in terms of asking you to register your device with Kindle. Even with the Cloud Reader, there’s tracking of how and what device you use to access the service so that you get the experience best tailored to your device’s abilities.

Lastly, a person will eventually ask if this is something that’s worth paying to get behind a paywall, or is it easier to compile and use a “good enough” application, which might go out to the web a bit less often. Native apps perform faster, and generally are easier to find because they are in app stores. If the group making the web app doesn’t have heavy brand recognition, they just won’t be found. [redacted] would need to partner with groups outside of its usual/known audience or embark on a marketing program that gets them out there a bit more.

Additional Points
When you are making that decision whether to have a mobile website or a mobile app, these are some of the things you’d want to have in mind. For further strategies on this topic, please see the following articles and resources:

Do you have anything additonal to add to what we’ve stated here. We’ve redacted the name of the company that was being referred to here so as to protect the integrity of that conversation. That said, this was forwarded to them so that they could adjust their mobile website and marketing approach to be more clearer towards what the destination does versus the expectation of those coming to it.