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?
Related posts:
About Glenn Gruber
Great article!
I can say that I pretty much agree with your points.
If you want people to share photos, video and other rich media or use a compass in a mobile UI it’s better to go the native route.
But in regards to user-experience there isn’t that much difference really. My company is doing pioneering work in regards to user-experience on location-based mobile web apps. We can create a native-like feel to our browser-based apps and make them offline and geolocation capable.
One of the key issues why we are going through so much trouble to mimic native apps with web apps is not only for the ability to use them cross-platform but also for lowering the barrier to access the mobile content.
I wrote some ideas about this in a recent article in our blog: http://zonear.com/2011/03/4-ways-to-make-it-easier-for-hospitality-companies-to-engage-their-customers-through-mobile-web-apps/
Timo Pietilä
CEO & Co-founder at Zonear Ltd.
Glen,
Great article on the current debate on native versus mobile Web. I do believe that optimizing for the Mobile Web is a first step that all travel companies must take. I would go one step farther to state that many travel companies do not have a clear strategy on the role of the native app versus the Mobile Web, with some few exceptions. I view the native app approach as creating a personal dialogue with your best customers. As you point out in the AA example, driving promotional offers through the app is a logical merchandising effort, but these promotions must be personalized based on the travelers’ history, explicit and implicit preferences and various persona (traveling on business versus holiday). The value of any native app should be measured on its usefulness at specific locations, during particular steps of the travel process and based on the situation of the traveler. Most travel companies have not created enough use case scenarios to pinpoint the way the traveler uses native apps in order to insure that the app meets their needs based on specific situations. Instead most have simply transferred Web capabilities to the native app environment.
Norm,
Thanks for the kind words (and you Timo!). I think we’re pretty aligned that a mobile-optimized web presence is a good first step, both from an SEO as well as platform coverage perspective.
And we’re also in violent agreement about focusing on the use case before starting development. It’s in fact the first thing we talk to clients about and leads off our “5 Steps”. See my post from earlier this year — http://www.tnooz.com/2011/01/13/how-to/part-one-of-three-designing-a-successful-mobile-strategy-for-travel/. But you make a good point that it’s a step that too many people skip, far too often.
Glen (and Norm) – great stuff.
However I think there is a big misunderstanding about HTML5. It’s not just about creating web sites which can “feel” more native thanks to the “5″. It’s about creating downloadable modules in a language that can be executed in a browser environment (read virtual machine), independent of hardware. Think of it as a “run everywhere” app.
This, if everyone plays the game, can be good.
Daniele,
I never said HTML5 is “magical” (the iPad is
), but the enhancements in HTML5 along with CSS3 and JavaScript really help deliver much more robust user experiences via the web on mobile devices than prior technologies. But people need to understand the limitations as well and decide whether they can still accomplish their objectives working within them or not.
To your point about “run everywhere” it’s been helped greatly due to the quasi-standardization of the mobile browser under the Webkit engine.
The “build once, run everywhere” argument is something that I’ve found people don’t fully understand. A lot of people only view it as “ok, so it works on both Android and iPhone”. Ok, those two are probably the most important ones but there are so much more than that.
In our case (we develop map-based web apps) the mobile web approach allows us not only to deploy our apps to be used in smartphones and tablets, but also integrated into regular web sites and used in big touch screen info displays with just few simple modifications to CSS.
In regards to user-experience and making the web apps feel more native-like..well you don’t really even need HTML5 for that as almost all of that can be achieved with regular ol’ AJAX techniques
This is timely for us at Viator – in the past 3 weeks we’ve relaunched our mobile website (m.viator.com) and launched native apps for iPhone and iPad.
We chose to build our mobile website in standard HTML, to make it as widely compatible as possible. Agree with all the comments above about developing a streamlined UI and a framework that can be easily replicated across multiple languages (we operate in 8 languages besides English, including Japanese).
Luckily we’re also large enough that we can develop native apps. Our goal was a rich native iPhone experience that did not simply regurgitate our website. We targeted a whole new range of features – What Can I Do Today? – that deliver real-time booking at the last minute, often within hours of travel times. This required us to re-engineer a lot of our backend systems, to support true last-minute availability searches. But again, this seemed like an absolute critical factor in an iPhone environment.
Our apps are 1.0 versions, and we plan to invest a lot more time/energy/resources into evolving the apps and mobile web experience.
I’d love to get any feedback. Browse Viator.com on your Smartphone and/or search “Viator” in the App Store.
Scott McNeely
VP Product – Viator Inc.
Scott,
Being an ex- Sun Microsystems employee, it feels strange responding to Scott McNeely (though I know he spells it McNealy)
. I recently downloaded your iPad app, great job! It really demonstrates the reason why a separate tablet app is needed for rich content sites.
Scott,
Glad you liked the article. I too also downloaded the iPad and iPhone app. I think there are some neat visual elements in the iPad app (like the spinning globe) but it seemed there was more utility in the iPhone version. The iPad version does make good use of the screen real estate, but might suggest folding in some of the iPhone version functionality. Happy to chat more if you’re interested.
Thanks Norm, and Glenn.
Glenn – Yeah, the v1.0 iPad app was intentionally built as an ‘armchair’ inspiration guide, much less transaction oriented than the on-the-go iPhone app. Our approach was to build 2 very different apps for 2 very different UIs.
But your point is well taken – as tablets become more common as ‘on-the-go’ devices, the iPad app will also need to become as transactional as our iPad app, and offer a direct booking line into our new last-minute availability systems.
Appreciate your feedback, it’s very helpful as we start to plan out the roadmaps for both of our mobile apps.
-Scott
Nice article!
However, am I missing something, because most international travelers don’t use their smartphones when they go abroad due to roaming charges. Or, is this blog just talking about domestic travelers?
Patrick,
I’m glad you liked the article. I agree that mobile web/app usage is often limited be high roaming charges when traveling internationally. But I wasn’t really looking at it from that angle. Just focusing on the implications of the technology.