There seems to be a new round of buzz around the good old HTML5 vs native debate or, in other words of web vs apps. We had a Mobile Monday session in Manchester (@momomcr) on this, debate on ForumOxford is flaring up again, and more… So I thought let’s do this again and see – if anything – changed since I posted about this (for the record: here’s the first post from 2009 and the second one from 2010). Where has the battlefield moved to in the interim?
Mobile apps must die
There has been (as you may have sharply derived from this post’s title) a post from Scott Jenson, the Creative Director of Frog Design (they of much Apple fame – you know, they designed the Apple IIc and such), which he entitled – somewhat combattively – “mobile apps must die”. His argument is, in short, that the mobile desktop cannot cope with the plethora of native apps (or app icons?) and that it would be much better to use dynamic “use it and lose it” approaches for which the web is perfectly suited. He starts of on the value vs pain paradigm: if the balance is less than 0 (i.e. value exceeds pain), the solution wins. And he posits, that native apps don’t do that.
I am not doing the intellectual argument Scott poses any justice here (and I will pick up on some more points further below), so please make sure to read his post!
One size does not fit all
The challenge is to find a universal solution, I suppose. Jenson focuses merely on apps that – arguably – make a user’s life better if and when he/she is out and about and is looking for utilities to help mundane tasks/etc. There are tons of fairly one-dimensional apps for that: a retailer app for their catalogue, London tube map, some couponing app, a mobile banking app, apps using NFC, Bluetooth, camera (QR readers) and more. There will also be more complex ones: fancy AR-powered things, things like Foursquare (anyone near?), etc, etc. So, is this painful? Yes, it is. Would it be better if there was a seamless universal (cloud-based) solution that would make it “just so”? Oh, by all means.
BUT… it would not solve all use cases for smartphones (or mobile computing in general). There are tons of applications and use cases that are not the out and about equivalent of a Google search (and, yes, I am fully aware that 40% of Google mobile searches relate to locations), and I would posit that one has to judge each one on its own merits.
UX
The starting point should always be the user experience. Jenson points out correctly that this is not only about the perceived value of the product or service in isolation but it is more of a function: if the perceived value exceeds the pain to use it, it works. If pain exceeds the perceived value, it doesn’t.
But it is this very statement where things with Jenson go horribly astray. There is a reason why Apple has not yet moved Keynote to a cloud-based SaaS solution but keeps selling it as a stand-alone app: because it works better. The perceived value of using the product far exceeds the pain of having to download and install the application.
Tackling the shortfalls
When looking at the UX chain (from product to discovery, maintenance, management and use), there is more than one answer to shortfalls of some of these elements. Rather than moaning about distribution and app management, one can also improve those processes. The OS-based app store model all but replaced the carrier stores for smartphones now, and why? Because the end-to-end solution is less painful (not only for users of the apps but also for its producers!).
It is possible to draw a map of this (and I would if I possessed more artistic skill) where you could derive on what is right for you: if you need access to hardware APIs (camera, 3D acceleration, Open GL ES, etc), native might be your way (one of the reasons why you are not seeing higher-end HTML5 games in large numbers yet). If you capture light-weight information-heavy content that relies on dynamic updates, a web “app” might be good for you, in other cases, a native app with some functionality coupled with a container for web functionality might be the right way.
So there we have it: it still is the old “it depends” answer. Having said that, with webkit and HTML5 adding functionality all the time, ever (?) improving bandwidth and better compliance on the browser side, the usecases for native apps will likely get less over time. Will it happen in full swing in the next 18 months or so? I doubt that very much.
At the recent 
It works basically like top-ups for prepaid phones: one party sends money to another one using the recipient’s phone number (and the sender’s PIN). The recipient will be notified by SMS and can then either use it as phone credit or receive a pay-out through an agent. Interestingly, Safaricom partnered with thousands of merchants, groceries, etc because the banking system in Kenya’s rural parts is so thinly developed that people could not have used it appropriately. Apparently, a lot of people do not actually take the cash out but keep the balance in the phone (for top-ups or just for keeps). This means that, as an aside, Safaricom is allegedly saving $12m for not having to print and distribute top-up cards for its prepaid customers.
Next week, on 15 October 2010, there will be the fantastic opportunity to bask in the glory of Oxford University and attend what many say is one of THE outstanding conferences in the mobile space, namely the