One of the first decision points when companies look to build mobile apps is whether to "go native" or pursue an optimized mobile web approach.
Anyone whose plan is to simply redisplay their existing website on a mobile device, please email me and I will get you immediate medical attention (joke, sort of).
Many who are interested in going down the optimized mobile web site road (perhaps using HTML5), may have just gotten some of the wind taken out of their sails with the newest version of Apple’s OS, iOS 4.3.
One trick that was available in prior iterations of the OS was an option to save a "shortcut" to the home-screen that opened a full-screen web-app, hiding the browser interface using the UIWebView control.
This seemed to offer the best of both worlds from a usability perspective as well as providing prominent placement on the phone to enhance accessibility, increasing the likelihood of repeat usage.
However, while iOS 4.3 brought the lightening-quick Nitro Javascript rendering engine, it appears that these home-screen web apps don’t get to use it, slowing performance by about 250%.
Why is that? Daring Fireball’s John Gruber provides an answer:
"The Nitro JavaScript engine is only available within Mobile Safari. Outside Mobile Safari — whether in App Store apps using the UIWebView control, or in true web apps that have been saved to the home screen — apps get iOS’s older JavaScript engine."
Not good. So unless and until this gets resolved, it’s something to keep in mind when you’re developing your mobile plans.
So perhaps it’s worth a review of the decision process that many firms take and see whether it’s time to re-evaluate your strategy.
Rather than get into a deep technical discussion of the merits of one approach or another, let’s keep it practical. More often than not this devolves into to three core discussions:
- Budget. This goes first because it’s real and drives actual decisions. Supporting multiple platforms with dedicated apps requires time and money. Something that is not often in abundance at most companies.
- Leverage of Phone/Offline Capabilities: It’s up to each company to determine what their objectives for their mobile presence and how critical leveraging device capabilities are in achieving them. I would venture to say that using the gyroscope on the phone would be very rare for a travel company, but taking & sharing photos, local storage for mobile boarding passes (although that can be done with HTML5), calendar integration and push updates (reminders, travel delay alerts) favor the native app route for now.
- Good v. Evil: To some extent this is an obtuse extension of the Open Wweb versus Walled Garden debates about Apple. TechCrunch’s MG Siegler summed it up well when he said: "There has been a general underlying current among the geek community that HTML5 is good and native is bad."
Well the last one is not a practical concern, but it does stir up a lot of emotions and drives the decisions that some companies take, more often than it should (that is never).
But religious debates aside, what’s really happening?
Native apps are where the action really is. Forrester recently estimated that the revenue from paid applications on smartphones and tablets was $2.2 billion worldwide for 2010 with a CAGR of 82% through 2015. That’s a huge number.
But revenues are only of value if you’re planning to sell your app. Many travel suppliers and intermediaries do not charge for their app as the intent is to use it as a mechanism to monetize their customer (via bookings, advertising), enhance customer service and build loyalty over the long term, not to engage in a one-time transaction.
And a recent Forrester/Dr Dobbs survey bears out that "native" is where it’s at:
Forrester analyst, Jeffrey Hammond states that WAP-style mobile web and Java Micro Edition, dominant technologies pre-smartphone, are in steep decline as the world is shifting rapidly to smartphones.
And while a lot of attention has been garnered by mobile middleware, promising "write once, deploy many" solutions, the uptake has been scant.
Of course, whatever direction you choose (and you’re not limited to one answer), you must be aware of the costs of development under native, mobile middleware or mobile-web driven development.
So what’s the right prescription?
Given the dominance of Apple’s iOS and Google’s Android platforms, many companies have taken the tact of building native for those two platforms (notwithstanding Android’s gains, iOS is still first on the priority list) while using a mobile web strategy to support RIM/Blackberry, RIM/QNX (whenever it finally ships), Microsoft Windows Phone7 and HP’s WebOS.
Other than Internet Explorer, all the browsers in question are based on the WebKit technology, supplied by Apple. Microsoft does however provide HTML5/CSS3 support and plans to enhance it, so you should be safe there as well.
Getting back to the practical issues, I realize that some companies don’t have the budget to do what I just recommended. If that is the case, pursuing a WebKit-driven optimized mobile web strategy.
Show me some examples
I’ve reviewed a number of sites for large airline, hotel and OTA brands. Some do a better job than others. Some hotels do not even have an optimized mobile presence at all, save for a few proactive individual hotels.
But I’ve chosen three examples that provide a representative sample of the state of mobile readiness in the sector.
American Airlines has a very nice native iPhone app providing a wide range of capabilities, up to and including a Sudoku game for while you’re waiting at the gate. But when you compare it versus mobile web alternative, it’s clear where they’re placing their bets.
Hilton’s iPhone app is certainly mobile friendly, although not necessarily a paragon of user experience best practices.
But it is well ahead of their mobile site, powered by Usablenet and seemingly designed for feature phones rather than the richer experience available on smartphones.
Okay, that’s one airline, one hotel, let’s add in an online travel agency.
Travelocity has perhaps done the best job as their mobile web presence mirrors their iPhone app almost exactly. Nicely done.
So do you think your mobile site/app is up to snuff? Do you agree or disagree with my critiques/characterizations?