Die, Native Apps, Die!

Recently, I've been telling anyone who will listen that you should consider writing an HTML5 web app rather than a native mobile app. The advantages are many and the list of things you can't do grows smaller by the day.

I spoke on the topic at DDD Sydney earlier in the year, and more recently at Web Directions "What Do You Know" in Brisbane. If you'd like the slides, they're available at http://www.damianbrady.com.au/dyrnaa and http://www.devnewsreader.com/about.html respectively; complete with demos. Check them out - I'd love your comments.

Why choose web apps over native apps?

There are a lot of reasons, and most are obvious.

Users are always on the latest version - no support of old versions
You only have to implement it once, in one language (counting HTML, CSS, and JS as one language of course)
You can choose what to charge and how to charge it
Done properly, web apps work on all devices - even those that don't exist yet

But they're slow!

Well no, not necessarily. I blame Facebook for this misconception.

Facebook famously released an HTML5-based app for iOS and then ditched it in favour of a native app to squeeze more performance out. After all the reporting, the emergent mainstream view was that HTML5 apps simply couldn't perform. In reality, the new release was a refresh using a technology closer to the metal as a reaction to consumers screaming out for performance above all else. Let's face it, Facebook is not a trivial app in terms of bandwidth and content. There's a fair bit going on with photos, chat, notifications, etc.

Could Facebook have made the app faster while still using HTML5? Almost certainly, and if they'd leveraged newer HTML5 capabilities as they became available, there definitely would have been improvements.

But would it have appeased the masses? Maybe, but we'll never really know.

But web apps can't do X!

Quite possibly not, no.

Well... unless you're talking about using touch events, orientation, geolocation, hardware-accelerated graphics, local data storage, offline operation, home-screen icons, audio and video, sending emails or making phone calls. So probably yes... yes they can.

Sure, there's gaps in there. A web app can't use your phone contacts, it can't play your music, and it can't (quite) use the camera.

...Yet

Yet?

There's a very definite trend in the world of HTML and browsers. Each new browser or mobile OS version slowly chips away a bit more at the list of things a web app can't do. Surprisingly, Apple seems to be leading the way to a degree in the mobile space; enabling more and more HTML5 features in Safari with each release.

I say "surprisingly" because Apple has a very captive market in terms of native apps. True or not, the perception exists that neither Android nor Windows Phone have the same quality of apps available in their stores. Certainly they don't have the quantity. Why then would Apple implement functions in Safari that pave the way for native-quality web apps? It's a good question, and I'm not sure I have the answer. Maybe it's just the constant drive to stay in front.

Grooveshark

Very recently, Grooveshark rolled out a fully-functional HTML5 version of their site that works beautifully on mobile devices. They've been plagued by problems getting native apps into the official app stores, and this option allows them to bypass the problem altogether.

It's a truly impressive piece of engineering. If you have a ... well... anything... I strongly suggest you go and try it out. There are some amazing features. For example, (On iOS at least) you don't even have to keep the browser window open for the music to keep playing.

One small thing... I'd love to see them implement some of the meta and link tags that Apple has made available for iOS devices. For an example, try adding http://www.devnewsreader.com to your home screen on an iPhone or iPad (warning, it's quick-demo quality).

Despite being a company that focuses on something not traditionally offered via a web page (streaming music), Grooveshark has chosen HTML5 as the right way to go. Before sinking time and money into developing native apps for multiple platforms, it's worth considering whether your app might be a good candidate for a web app as well.

Grooveshark may not be the first high-profile name to try to escape the walled-garden of native apps, but moves like this definitely show the blood in the water (pun totally intended and awesome).