What: The ability to store content on the device for offline consumption.
Summary: HTML5 can support offline storage in a number of ways, and there are some pretty good apps out there that utilize it. However, there are two problems here. Firstly, the amount of space you can use is somewhat limited. On iOS, you initially only get 5MB. You can increase this to up to 50MB, but only with a rather unpleasant dialog that confuses many users. For an constantly updating newspaper, 50MB should be plenty to store the latest edition. However, for a rich, editioned magazine with full page interstitial adverts, 50MB just isn’t enough.
Verdict: Native, because pretty magazines are big.
What: They ability to notify the end user of important events, for example breaking news or a new edition of content.
Summary: Unless your users constantly have your browser tab open, and you have some AJAX polling going on from your web application, web technologies currently don't support this. Your best bet is to notify users by sending them an email or some other out-of-band information. Both Android and iOS have rich, native push notification systems that provide a much more seamless user experience that provides instant gratification.
Verdict: Native, because we like to know things in real time.
Online and Offline Analytics
What: The ability to track how users interact with your application.
Summary: The web mastered online analytics many moons ago. The problem is, offline analytics are much more difficult as one needs to record actions that are taken offline, store them on the client, and reply the actions when returning online. This is of course possible, but it requires a fair bit of effort and in many cases it isn’t possible to tell the server the exact time an event occurred. However, if you have a native app you can find libraries from the big players (for example Adobe Omniture or Flurry) that make all of this easy.
Verdict: Native, but only just as the web will catch up soon.
Online and Offline Advertising
What: The ability to retrieve ads from an ad server, and display them while online and offline.
Summary: Advertising is difficult. Fetching the right amount of inventory for offline display is difficult. Placing it dynamically inside your app is difficult. Keeping the assets small is difficult. However, it is of course possible, and every ad server that matters serves their ads as HTML. So this is an easy victory for web technologies.
Verdict: The web, because HTML is the only advertising format that makes sense.
What: The ability to share your interactions with the app with the world, and for them to easily join in if they want to.
Summary: Virtually every app (native and web) provide the ability to share something on the two big networks -- FaceBook and Twitter. The sharing is easy. The hard part is sharing something that lets the recipient back into the application. This is possible to do in native apps, but it is clunky and involves the user opening a link on the correct device, with the application pre-installed. Protocols are being worked on to improve this for native apps, but they ain’t here yet. URLs are the stuff the web is made off, so this all just works in the web app.
Verdict: No contest. Apps are closed. The Web is open. Web wins.
So there you have it. According to the table above, there are still quite a few things that, from the technical perspective, are best done natively. As time passes and web standards progress, expect the web to catch up in all of these areas. But this is going to take many years so, in my humble opinion, hybrid apps are the way forward the foreseeable future.
Till next time, in which we will talk about the different ways we can package and download content, and compare edition based content with permanently updating content.
Editor's Note: You may also be interested in reading: