HTML5 versus Native Apps (Again)

Excuse me for wading into a religious battle but I’ve often been puzzled by the zealotry displayed by those who are adamant that only native applications are worth looking at. Admittedly it’s a zealotry that is more often displayed by Apple followers – and let’s face it, Apple followers tend to be zealous at the best of times. But even more moderate souls often espouse the same view.

This “native is best” stand gained lots of credence a year or so ago when Facebook announced that they’d be turning away from HTML5 development for their mobile apps and would instead return to multiple streams of native development. In an interview about the decision, Zuckerberg went so far as to say that:

The biggest mistake we made as a company was betting too much on HTML5 instead of native… We burnt two years. We’re betting completely on [native apps]. Native is going to be the approach that we go with for iOS and Android

While a few years ago it was obvious that HTML5 was a technology that wasn’t quite there yet, the rapid development of the standard, alongside the not insignificant negative impact of supporting multiple native platforms, had me thinking that HTML5 was the natural way to go – Zuckerberg’s comments called that into question.

So it was interesting to read a post written by Stehen O’Grady of RedMonk. In the post O’Grady reflected upon the RedMonk Monktoberfest event and specifically the mobile app for the event that was based on Lanyrd’s HTML5 application. The app delivered session schedules, venue information and an attendee/speaker directory. Seemingly most of the features that native developers who pitched to build mobile applications for the event were covered by the Lanyrd HTML5 app – but, obviously, in a completely cross platform way.

O’Grady points out that the HTML5 application supports not only iOS, Windows and Android devices, but Blackberry, Kindle and other devices via Opera Mini – for the price of one development operation, developers can offer backwards compatibility across the full plethora of mobile operating systems. O’Grady admits that there are some applications that can’t currently be met by HTML5 but he sounds a realistic tone that questions the dogma that pervades this debate:

…the dismissiveness towards web based mobile applications, fueled in part by Zuckerberg’s September comments, seems short-sighted. In an industry with little appreciation for either history or nuance, it is perhaps unsurprising that attitudes towards mobile/native tend to be so binary.

The key message from this debate, and one that is often overlooked, is the major impact of going down a native development path having to replicate development resources across multiple operating systems is a not insignificant burden on organizations. For a company the size of Facebook there is little impact – they have such a large developer pool that this aspect can be disregarded. But for smaller organizations, it is worth foregoing a little bit of native polish for the agility that a “code for all platforms” strategy can deliver.

There’s no convincing the fanboys and fangirls that anything other than their platform of choice will do. But looking beyond the dogma, it strikes me that dismissing HTML5 is a shortsighted and potentially expensive call to make.

1 Comment
  • I agree that if you NEED cross platform, HTML5 is a valid option, but IMO (and feel free to call me a fan boy, cos to be honest, I am…), you will end up with a single app which look like neither iOS, Android, WP7 or any of the others.

    In a lot of cases, and a conference app is a _perfect_ example, this doesn’t matter. I want the info, read only (or with limited client-side like staring sessions I want to go see). It’s a fair bit different with something where I need to use it as an app.

    As Xero and Facebook found out (and others). I’m VERY much looking forward to see what Layton and the Xero people do.

    Of course, and this is where my fanboyism comes in, something like the Xamarin toolset shines. Share as much as makes sense, do platform specific for the bits which don’t (mostly the UI, a lot of things like sensors, camera, etc can be made cross platform, and enhanced for specific platform features)

    good current example:

    http://calca.io/

    (I think windows is coming)

    or iCircuit:

    http://praeclarum.org/post/42378027611/icircuit-code-reuse-part-cinq

    Or to a lesser degree, 2 of my apps, which share a huge amount of code:

    http://educa.co.nz (the iPad and Android ones, not the iPhone one, someone else did that)

    If you just want one platform, native makes a lot of sense. For cross platform there are a number of ways with different trade offs. Horses, courses etc.

  • Pingback: Xamarin Rolls Out Even More Cross-Platform Mobile App Development Goodness « Secured Archives Secured Archives

Leave a Reply