Native apps – a necessary evil?
It’s a very interesting instruction. One I used to agree with…
Purely from a technical point of view it is difficult to argue with the logic. Being able to develop once and still create Web applications which work well on many devices – with different hardware features, screen sizes, etc – is very possible using the latest iterations of Web standards.
HTML5 allows developers to produce rich and interactive graphics and animations in their pages using the Canvas element. One can handle streaming media (fairly) effectively using it. Persistent client-side storage is even available, which can be used for offline applications, amongst other things. The very brilliant, and now widely supported, CSS level 3 specifications make it really easy to accommodate different devices and screen sizes by using Media Queries – an excellent example of that is colly.com (play with your browser window size or use your phone/tablet).
All of those technologies are very interesting in their own right but for the purpose of this post I won’t delve into the mucky details. If you are interested, or feel you need to brush up, I recommend following the excellent @DesignerDepot on Twitter.
The important point here, and I assume (which may be a dangerous thing!) the key point for the Open-Standards-over-native-apps argument, is that Web sites built using modern Web standards – running on a modern browser – have the potential to be just as feature rich as any native app.
I do see one bit problem for the Web standards supporters, though. One big difference; one thing that Apple – and the others – offered which so far Web applications have failed to match. Micro-payments.
I’m sure there may be many people who disagree with that statement, but here me out.
Firstly, the importance of micro-payments. Whatever the difference in the functional capabilities of Web applications and native apps, Apple’s App Store essentially created an industry – or at least a sub industry. It was probably the first to market it’s applications as apps and certainly the most successful. 10 million apps have been downloaded and the App Store’s revenue in 2010 reached $5.2 billion. The median revenue per third party app is $8,700 – according to Wikipedia (and source) – and there are more than 300,000 apps available, equating to a $2.6 billion market for the app developers themselves. No doubt, then, this is big business. And (as big a fan as I am of FOSS) that kind of potential revenue has been the main driver in the success of the app movement, driven many software innovations in the name of competition and, most importantly, created an environment for entrepreneurs and developers to benefit financially from their creations. I would say – in my opinion unquestioningly – that the success of the App Store and its contemporaries is primarily down to a no-fuss micro-payment system where users feel safe and comfortable and not under pressure when parting with $3.64 (on average) of their hard earned cash.
You may argue that these micro-payment systems already exist on the Web; Amazon’s payment system – including 1-click – and Paypal could be seen as successful examples, amongst many others, no doubt. However, the argument which I’m contesting is not that Web-based systems are a better alternative to native apps but that open standards are… Amazon is no more open than Apple or Android. Google App’s – while very much Web based – doesn’t use a payment system which is compatible with any of it’s competitors or described in any specification (W3C or otherwise). In fact the W3C did look into this very issue in the 1990’s, although due to lack of uptake of micro-payments (how wrong they were) the working group was closed.
Anyway, to conclude this (now rambling) post…. it’s all well and good to plug open standards but, until the big issue of payments is resolved with an open standard, a healthy applications market – and hence the competitive pressures which have built pushed the boundaries of mobile software to what it is today – could not exist without closed systems and APIs.