Everyone wants a mobile app, banks, health funds, airlines, pubs and all sorts of marketers want us interacting, playing with and using their mobile apps. This is fine and dandy, and is a Good Thing for the future of humanity, but … which OS do you want to target?
Is your app going to target iPhone, Android, Blackberry, Windows Phone 7 or (heavens!) Symbian?
The right answer will, of course, be all of the above. It really isn’t hard to figure out, and there is a precedent you see.
What do you do if you want to target users on MacOS, Windows 7, Linux (a bazillion flavours itself), Google OS or (heavens!) Unix?
The answer to that question is you created a web app, because the browser environment was designed to be (reasonably) neutral between vendors. The same paradigm exists in the mobile world. Creating a specific OS version just limits your app to that OS, and who wants that?
However there is one big difference, the mobile app needs to deal with being occasionally (dis)connected, right? Solving that problem has been hard enough that mobile apps are still sprouting up that basically show content offline.
Riding to the rescue of the beleaguered user comes HTML5 with its cache manifest offering to give web apps a completely sane way of specifying what content should be held offline and what resides online. The only problem is the memory limits most browsers place on the cache – except for Opera they all only let you have 5MB (or 10MB if you are on IE) – and in these days of fast connections and rich media that simply isn’t enough to get the job done.
There are various ways around this, with Google Gears, Microsoft Sync Framework and Flash also offering ways of getting offline storage to work, and there are some jQuery plugins that hint at the promise of getting this working in a framework that leaves the browser sensitivities to someone else (although I’m always leary of potentially leaky abstraction layers).
Personally I don’t care how we solve the problem of sufficiently large offline storage, but I think the future of web development demands that solve it we must.
In the meantime we will continue to see niche agencies offering native applications for various phone OSs, but not necessarily delivering the value the business needs because the cost is so high to develop cross-platform apps – and some other applications that target specific OS flavours, most notably Apple iOS or Android, and get away with that because the user base can be targeted that way (for now).
EDIT – 23rd Jun 2011
GigaOM recently weighed in, telling us that native mobile apps were beating HTML5 ones. One commenter, Roshan Shrestha, mentioned that:
“I see that many of the apps are just a wrapper against an HTML browser component. Most of them do not store much data locally and require internet connection, so these are basically web apps.”
I agree that most apps could be web apps, and I think it will end up there, but not yet. In the meantime everyone needs an Android app, wants an iPhone app and should have a Windows Phone 7 app.
This is what Apple has been saying since 2007, when they released the original iPhone. Unfortunately the rest of the world seemed to disagree and put great pressure on them to release a native SDK, which they eventually did. iOS still has the best mobile browser implementation in the world, too -- iOS 4.3 included a major overhaul to the Javascript engine and Mobile Safari includes the best support for new mobile APIs.
ReplyDelete