End-users don’t care about native vs #HTML5

I came across  more discussions on native vs HTML5  today, so I thought I’d jump in to the fray. For the most part, this debate feels like a East Coast Rap vs West Coast Rap, Oasis vs Blur, Rolling Stones vs The Beatles type of discussion.

Put in Shakespearean terms, the whole debate is “full of sound and fury, signifying nothing.”

Native vs HTML5 is a fun thing to discuss amongst geeks and wonks, but for the rest of the world, well, they’ll probably go out and buy both Definitely Maybe and Parklife. You know what I mean? Ya ya….

From the end-user perspective, the difference between native and HTML5 is rapidly evaporating and the question is now coming down to developer preference. What are the rules-of-thumbs? Here’s my handy-dandy guide that I’ve compiled based on my millions of developer conversations:

1)   Optimized for a device: If you have a very specific experience you’re going for on a very specific device, you’re probably going native. This is especially true if you’re writing for something like the iPad, which is one device with very specific one-off demands. I’d love to say there was no exception to this rule, but then you look at the FT that has developed a super amazing iPad app and did it all in HTML5

2)   You feel the need for speed: If you want to get something out there quickly and get it out to a lot of people, HTML5 is the way to go. Building for the web is faster and easier, plus there are a ton of web developers out there who can give you a hand

3)   You really need specific APIs: At first blush, you’d say native and up until now, that would be a good guess. For the most complete device-level access you will want to stick with native. But if you just need access to the big things like camera, accelerometer, off-line storage and so on, HTML5 can help you out as well. Mozilla and friends are seeing to that with their web APIs

4)   You don’t want your app to look like a website: Sure, native will take care of this for you but want to know the big secret? So will HTML5.  Actually, an HTML5 app can run outside of the browser and be launched from a one-touch icon on the start screen. I know… sounds awesome! I’ve seen it with my own eyes

5)   I want write once/run anywhere, dammit!: Happily, no one will get you there. The closest is obviously writing native for iPhone because that will get you, well, on all the iPhones (and iPads, too in the  pixilated “2x mode”). But if you write for iPhone/iPad, you’re kinda SOL when it comes to the desktop if that means anything do you. Android as we know is fragmented, so when you write an Android app, you’ll be tweaking  it for the rest of your life for all the infinite combinations of versions and form factors. HMTL5 can help but you’ve still got to contend with Firefox’s Gecko as well as the different flavors of WebKit. But with HTML5, a couple of tweaks and some responsive design and you can cover both desktop and mobile

One more thing….

It actually doesn’t matter. Native vs HTML5 is not a black and white question as apps are pretty much hybrid (or shades of grey, to keep up the metaphor.)  What I’m hearing is that core parts of applications are being built in HTML5  and only the wrapper is being built in native. Remove the wrapper, add a new one, and you can distribute on other app stores. Remove the wrapper entirely, and you can distribute on the web.

So in mobile, native vs HTML5 is a ton of fun to discuss and watch people get excited about. But ultimately, it doesn’t really matter and development dogma will soon give way to building and app depending on app requirements, and a dev’s own personal preferences.
From the end-user perspective, both can serve up the same performance, same look, same feel, same experience.