Future of Mobile Apps Debate: Native vs. HTML5 Web Apps

Coming into 2nd half of 2011, the mobile apps debate between native apps and web apps based on HTML5 is heating up.  Web apps actually run through the mobile browser on the device and can also be re-packaged as native apps using "wrappers" provided by various development tool providers. With ever more fragmenting mobile OS platform landscape to go support, and the convergence of mobile browsers around webkit and HTML5 compatibility (although the jury's out on standardization of HTML5 until late 2012 at best), developers are turning quickly to HTML5 as a "write once, run on all platforms" solution. But is this really viable for all use cases and what implications exist on business models? 

I just chaired this awesome executive panel event for the WCA (Wireless Communications Alliance) on "Mobile Cloud - Thin vs. Smart Devices and Services Differentiation" on 9/27 (presentation and video recordings available at http://www.wca.org/sig/mobile) part of which addressed this precise topic on native vs. web apps debate.

The verdict, actually, depends entirely on "what the app needs to achieve and how it needs to be delivered to users".  Here are some major issues to consider when making such decisions:

1. UX Features

Can "native" apps always do a better job of implementing a User Experience than "web" apps? 
There's the experience of the app itself, and the way it hooks into the device's other features. For Android, this would be features like widgets and notifications. Native does excel in both dimensions.

In terms of app experience, native apps can do more.  They can easily get a hold of swipe gestures, multi-touch events for those devices that support it.  They can react to hard keys presses, like Android's search or home button.  They can access hardware features too, like GPS, accelerometer, or camera.  It's more than the "in-app experience" though. An OS like Android provides different ways for apps to interact with users, and indeed, with other apps.  You have notifications which show up in the device's status bar, active widgets on the homepage, intents that allow your app to announce itself as providing a general service which other apps can utilize, etc.

It's true that many native in-app features are simply beyond reach for a HTML5 wep app.  No matter how hot your web skills are, if your app is stuck in a sandbox with no camera API, it won't be taking any pictures.  But fortunately, you don't have to be in that sandbox.  If you really need your web app to take a photo, you can transform it into a native app with an embedded web view which provides most of the UI.  This is how the open source PhoneGap (Nitobi, the company behind PhoneGap, just got acquired by Adobe on 10/3/11) framework works with web apps -- it fills the gap by exposing native features as web services, which the web view calls using a standard networking API.  When you build a hybrid app like this, you're also able to hook into those platform features like notifications, widgets, and intents.

Such hybrid apps do add complexity and looks / behaves like native apps rather than traditional websites accessed from a mobile browser.  But rest assured, web standards are evolving quickly, and modern mobile browsers are keeping pace.  Offline storage, canvas graphics, geolocation, and video/audio playback and even streaming features are already supported inside HTML5 compatible browsers in today's smarpthones. Even camera is starting to be supported; as of Android 3.1 (Honeycomb), it's possible to capture photos and videos using web standards.  And the latest iOS Safari browser supports WebSocket for 2-way streaming, as well as device orientation detection.  Another key benefit is that web apps essentially reside in a "cloud" environment not inside a device, so the user does not have to constantly "download updates" like the cumbersome native apps update experience through app stores, especially if those app file sizes are 10's of MB -- with web apps, feature upgrades and bug fixes occur with a breeze without any user action!

2. Performance

Are native apps always "faster" than web apps?  Yes, native apps don't have the web runtime barrier to deal with.  And yes, they run close to the metal and can take advantage of performance boosters like GPU acceleration and multithreading.

However, it would be an understatement to say the web has gotten "faster" in recent years. V8, the JavaScript engine that ships with Chrome, was a major development in web performance when it launched, and since then, it has only gotten faster.  Graphic rendering engines has also sped up the web, and now hardware acceleration is starting to happen.  In addition, the new Web Workers API makes multithreading a possibility, and modern web developers can also call on a range of performance-optimized libraries, and well-researched performance optimizion techniques. While most of those started life on the desktop web, they are still relevant to mobile, and there's increased attention paid to mobile.

Not all desktop advances have made their way to every mobile platform yet, but the trends indicate they are on their way. It's also important to note that the majority of mobile apps aren't bleeding-edge 3D games, but fundamentally information-based: news, mail, timetables, social networks, etc. Visit a few sites from your mobile, e.g. GMail, Amazon, Twitter, and you can confirm mobile web performance is more than adequate. As for games, basic ones are already feasible with 2D canvas, and WebGL is starting to appear on mobiles - see Firefox 4. Until it's widespread, there is a growing family of frameworks which compile WebGL apps to native apps that can take advantage of OpenGL.

So, native is a fast-moving target, but the web is closing the gap.

3. Developer Skill Set

This one is obvious.  Do you have Java skills (Android, Blackberry), Objective-C (iOS), or C++ / C# (Windows Phone) for developing your native apps?  Or, do you rather have HTML, Javascript, CSS skills for developing HTML5 web apps?  Inevitably, the latter opens up the door for traditional "(desktop) web developers" to easily "mobilize" their desktop apps to mobile apps and there are Millions of those developers who are already savvy with those web design skills.  Plus, the native "wrappers" for hybrid apps like PhoneGap only requires the same HTML, Javascript, CSS skills to enable native features onto your web apps. 

So, if your business model demands you to go after 3 or more OS platforms AND you don't need hardware accelerated multimedia or graphics features or hard button interfaces, then the winning choice will be going web (or hybrid) apps using HTML5.  However, do keep in mind that each of these OS platforms have slightly different implementation of feature sets in their mobile browsers (some support video streaming and some don't, for example) AND each of the device OEMs also "tweak" these standard browsers or even add in their own mobile browser that complicates the core features implementation planning to ensure consistent user experience across all the OS platforms.  Such pain will unavoidably continue until HTML5 as an industry standard gets signed off and all of the mainstream mobile browsers adhere to those standards (likely not earlier than 2013).

But if your business model requires you to depend heavily on "offline" or "hardware accelerated" features like graphics intenstive or 3D games, or very fast UI response times, then your best bet will be to go with native apps.  You'll have to choose your battle wisely, if to bet your horse on Android first or on iOS first, then scale up to the next platform.

4. Monetization Models

Is "natvie apps" the only way to monetize your app? Mobile app stores offer several avenues for developers to directly charge for their apps. Simplest is the one-time payment, to unlock and distribute the app perpetually. There are also in-app payment and subscription mechanisms on offer in some stores and platforms, and they are tightly integrated in a consistent, secure, mechanism. These newer forms of payment allow developers to convert a smash-hit app into a recurring revenue stream.
In addition to app payments, you can also monetize with traditional web models, such as in-app advertising or revenue sharing of targeted ads.

However, the "web apps" would not be the engine of the Internet if there weren't ample opportunities to cash in. Although direct "pay-per-use" models have yet to flourish, there are various niches where subscription-based SaaS solutions have indeed become viable. Examples include Google Apps and premium versions of various POP3/IMAP email services. Furthermore, direct payments aren't the only way to profit from web apps. There's online advertising, sponsorships, affiliate referrals, cross-promotion to other online products and services.

Having said that, one can't submit a web URL to the native app stores for "downloads", so what's a web developer to do? What you do is create a native "wrapper app" - for each platform you want to target, create an empty native app that simply contains a web view (or even widget as that window). The web view is where you embed the real app. Then you just submit these apps to the various marketplaces. There are probably thousands of web-powered apps in the main app stores today, some of them so cleverly assimilated that we don't even know they are web apps at all!

5. Discoverability

App distribution mechanisms like Apple's App Store or Android's Market have been overwhelmingly popular in recent years and are a major driving force for the entire mobile industry. Any developer can submit their native app to the marketplace, where users can discover it through a combination of browsing, searching, and getting recommendations. Not only that, but if you've done your job right, the user ratings and comments will convince users to hit that "install" button.

However, the web actually is arguably the most discoverable medium ever created.  In the URL, we have a unique identifier for everything ever published on the web, which includes any apps published on standard websites. Search engines make it easy to discover that content and other websites can link to it, including catalogues of web apps similar to mobile marketplaces. Indeed, any individual can share web apps with their friends by just linking to it in emails and social network messages. Links can be sent in SMS too, where mobile users will be able to click on the link and launch the app in their device's browser. We don't yet have the same marketplaces for web apps where users can rate and comment on apps, but that's quickly changing too.

********************************************************************************
So, in conclusion, the jury is still out and there is no clear winner.  In fact, the winner depends on "what" you're trying to accomplish and "how" your business model is designed to work.  Also, some apps are best suited for native (e.g. graphics intenstive games, etc.) and some are best suited for the web.   The web side now arguably has more momentum, but in terms of capabilities and execution qualities, native apps are not standing still.  One technique is hybrid apps, and this may be the best compromise for some developers: Web view where it's possible and platform-specific native components where it's not.

If you do choose the web path, be mindful of web standards like HTML5 and the fact that not ALL HTML5 browsers and device implementations are created equal, at least until clear industry standardization of HTML5 is established.  However, the "web" route is clearly the way for developers to attack myriad of mobile devices and OS'es all around, hence most effectively fighting the "fragmentation" war.