But can the mobile web emulate apps like Layar?

Is the the app store model just a fad, a blip in the progress of the open, mobile web? Ruadhan O’Donoghue of dotMobi examines the issue.

Everyone with an iPhone knows what an app is. They know what the app store is, and they know how to get new apps onto their phone. The app store model has been a remarkable success, with over one billion app downloads per month as of October 2011. But despite this, there are echoes of the walled gardens of the Internet in the 1990s, with companies such as AOL controlling exactly what content users could access. These walled gardens eventually came down when faced with competition from a more open web, and companies that didn’t adapt their business model suffered. Parallels with the current app store model are glaring, and have led some to argue that the app store model is just a fad, a blip in the progress of the open web.

The mobile web, then and now
Most iPhone users, and indeed Android and other smartphone users, probably don’t know that the mobile web existed before the iPhone’s debut in 2007. But it did. WAP, WML and iMode were some of the buzzwords of the day. It didn’t look much the way it does today, but it’s been around since the late 1990s.
The fact that the mobile web has taken a back seat is a testament to what a great job Apple did with iOS and the app store. The arrival of the iPhone in 2007 redefined how people interacted with their phones. Today, however, the web has all but caught up again. We need only look to some examples of the kinds of web apps that already exist today to see the web is poised to make its comeback. Just compare the native (app) and web versions of the Google’s Map application. Not only is it possible for the web version to sport a similar UI to the native version, but they also offer very similar location-aware functionality.

So what is the difference anyway [the Science bit]?
A native app runs directly on the device hardware and its OS. It is generally programmed using the APIs exposed by the device manufacturer, and its execution is handled by the device OS. A web app on the other hand is accessed via the device’s web browser, and essentially runs part in browser, and part on remote server. The server part can be written in pretty much any language you’d care to mention, and the browser part is generally written in some flavour of HTML and Javascript.

Why should I care?
Your decision to go native or to go web can impact a number of factors, including performance, barriers-to-entry, interoperability, ease of development, and openness. If any of these are important to you then you should care.

Performance
To emulate a native app with HTML5 and other web technologies, your app must run on a whole stack of technologies including the device OS, the web browser, and the Javascript engine. By comparison, the native app runs at the bottom of the stack, with much lower overhead and therefore better performance. Some apps are just not suitable for web.

Barrier-to-entry for user
There is essentially no barrier-to-entry for a web app. A user need simply click a link or scan a QR code and they can experience your app. Native apps must be installed on a user’s device, before they can use it.

Cross-platform
The web is platform-agnostic. In theory, and a promise of HTML5, the same web app will run on all platforms. For native apps, each supported platform must largely be developed separately.

Maintenance & updates
With a web app you have full control over what version your users are on. You control exactly when updates happen. With a native app you must cater for users who might be on different versions, and your users may choose not to upgrade to the latest version at all.

Openness
With the native app store model, both publisher and user are at the mercy of the app store. App approval processes can be opaque, apps can be yanked at any moment and without explanation, and arbitrary rules can be applied at any time.

You should only build a web app when it is the right thing to do, and this depends on your project and on your target audience. If you know that all your users are going to be iPhone owners, and you need graphics acceleration, then a native iPhone app is probably the way to go. If, on the other hand, squeezing every last CPU cycle from the device is not important for your app, and you want to reach more than one platform, then perhaps a web app is right for you.

So where does HTML5 fit in?
HTML5 represents a coming-of-age for the web browser in that things that were once only possible via a native runtime are now achievable directly in the browser.
Web apps can now reach into the guts of a device and pull out data in a way that was never possible before.
There are caveats, however. HTML5 is still a work in progress, with the W3C expecting the completion of its official specification no sooner than 2014. And even with WebKit as the de facto mobile browser engine, unfortunately each WebKit implementation is different, with different interpretations of the HTML5 specs, incomplete implementations, and unsupported features. This means more work for web app developers to ensure their apps work in all browsers. And then there’s performance – HTML5 apps will be slower than their native counterparts.

The HTML5 drumbeat is getting louder
There is a growing trend of big publishers moving to HTML5 web apps. Amazon’s recent Cloud Reader app (https://read.amazon.com) and the FT’s recent web app (http://app.ft.com) are two examples of big content publishers that have decided to go down the web app route.
Both originally had native iPad apps in the Appstore. In June 2011, Amazon announced its Cloud Reader app, a HTML5 web app with similar functionality as the iPad app. Around the same time an update to the native app removed access to the Amazon store from within the native app.
In August 2011 the FT pulled its native app from the app store and encouraged all its visitors to migrate to the shiny new HTML5 web app.
Both the FT’s and Amazon’s decisions to build a web app were in response to Apple’s decree in February this year to impose a 30% levy on all in-app purchases. By building out web apps and, in the case of Amazon removing in-app purchases, and in the case of FT, removing the native app altogether, both companies have managed to circumvent the app store levy. Apple can call the shots in the app store on your iPhone or iPad, but it cannot control what you do with your web browser (Flash content notwithstanding – but that’s another story).

They’re not alone
Amazon and FT are not alone here. Walmart too has recently opted for a web app, and has moved its Vudu movie streaming service into the browser. The Wall Street Journal is yet another publisher that has opted for web based services rather than see its margins cut.
Facebook has also just announced details of its informally titled Project Spartan. Interestingly, Facebook has thrown its weight behind both HTML5 and native apps with a new framework for third party apps which will accommodate both. Considering the large portion of Facebook apps that are games, where performance is vital, it’s hardly surprising that it is backing native apps too. It’s unclear if some deal has been struck with Apple regarding royalties in this case.

Cross platform … really?
The iPad version of the FT web app is reported to have taken a team of three full time developers eight months to roll out, and a further four months for bugfixes and to complete the Android version. It seems, in practice, at least some of the time, the cross platform nirvana promised by the web and HTML5 may be something of a double-edged sword for complex apps right now. Nonetheless we are at a place where both the development time and the capabilities of web apps can indeed rival those of native apps for most projects.

A browser is all you need
There’s no disputing the open web as having the potential to be the ultimate content delivery platform. You can take any piece of hardware, and so long as it has a capable browser, you don’t need to worry about obsolescence, or that the app ecosystem to which your hardware is tied will be mismanaged, or that your hardware vendor will decide to kill off the platform altogether. So long as there is a capable browser, you can keep on checking-in, you can keep on streaming, you can keep on shopping, reading, emailing, chatting, huddling – you can stay connected, you can keep on breathing.
The problem now is not that the browser is not capable enough, but that all capable browsers are not created equal.

This feature was first published in the November print edition of Digital Times magazine.

email

You may also like: