Is HTML5 Ready for Prime Time vs. Native? (Mobile App Development)

In my last post I compared frameworks for building app-like mobile experiences with Web technologies: Sencha Touch, jQuery Mobile, jQTouch, and Titanium Mobile. For my own app, Pints, I went with Sencha Touch. But in truth there isn’t a clear winner: for a simpler, more page-based app I’d probably go with jQuery Mobile. (David Kaneda wrote a nice comparison of jQTouch and Sencha Touch — both of which he created. Much of what he says about jQTouch applies equally to jQuery Mobile.)

Each of these frameworks can help you toward the same goal: a cross-platform, native-like experience built on Web technologies. The fundamental question is: is that goal realistic? My answer is a qualified yes.

Putting the App in Web App

If you’d rather avoid app stores (and in particular Apple’s opaque submission process), HTML is your only choice. Users will access your app via their mobile browsers, and can add its icon to their home screens.

In the olden days (e.g. last year) this involved significant compromises. Like any website, your app’s UI and data reside on a web server, and must be re-downloaded every launch — a performance problem at best, and an insurmountable obstacle when a user’s connection is weak or nonexistent (e.g. in San Francisco or New York).

HTML5 changes all that. The WebKit-based browsers built into iOS and Android provide multiple ways to keep your app’s UI and/or data offline:

  • HTML5′s offline application cache can store your HTML, CSS, and JavaScript on the device. After the first load (effectively an install), it’ll launch without an Internet connection, just like a native app.
  • The HTML5 localStorage feature lets you store any JavaScript variable you want in a persistent way, so they’re available permanently — like cookies, but easier and more flexible.
  • If localStorage isn’t enough, there’s a full-fledged SQLite database built into WebKit.

Taken together, these HTML5 features eliminate perhaps the biggest functional advantage of a native app. But app stores go beyond functional advantages: they provide exposure, and a way to charge for licenses easily.

App Store Deployment

Thankfully, it’s easy to deploy a Web app inside a native wrapper. The easiest way to do this is via PhoneGap, which also provides access to device functionality not available to the browser alone. It takes the form of a project template for iOS, Android SDK, Blackberry, webOS, Windows Mobile, or Symbian; from there you use the native tools (e.g. Xcode) to compile and run your app. Your HTML, CSS, and JavaScript are included in the app package and run locally (though you could certainly serve them from a Web server as you would with a Web app).

With very little Cocoa knowledge it’s also possible to roll your own wrapper. That’s what I did for Pints/iPhone, not only in the hopes of increasing performance but also to customize its behavior. I’m more than happy to share that wrapper; most developers, though, will find PhoneGap meets their needs.

Thus wrapped, your app is ready to submit to the app store of your choice, just like a native app.

The Down Side

So there’s little a native app can do that an HTML5-based app simply can’t. But “do” doesn’t equal “do well” or “do easily.” Here are the major drawbacks to the Web approach.

Performance:

Native apps perform better than HTML-based ones. More accurately, it takes more work and expertise to achieve decent performance in a Web app than great performance in a native one. A month ago I was ready to give up on the Web approach altogether: page transitions and list scrolling were embarrassingly slow, and Pints was hanging for 10-15 seconds every time its database changed.

Today Pints performs pretty well. Interact with it long enough and you’ll notice a stutter, but it’s perfectly acceptable. Getting there took time and patience. I needed a better understanding of Sencha Touch and its idiosyncracies: some features simply don’t perform well (yet). I had to develop a clearer picture of mobile WebKit and its nuances. A post by Thomas Fuchs (of Scriptaculous fame) got me started and gave me hope. From there, it was a question of trial and error: determining what impact various techniques had on performance and trading that off against features and visual design. The results were significant.

Thomas advocates avoiding frameworks altogether. It’s worth considering, but a good framework gives you a lot; I’d rather spend some time optimizing than start from scratch building my own page transitions, list controls, fixed-positioned toolbars, etc. That said, there’s currently no mobile-specific equivalent to jQuery or YUI, i.e. a lower-level library that provides common functionality without going overboard on UI elements and other objects. (jQuery Mobile is equivalent to jQuery UI, not jQuery itself.) Such a library would be most welcome. That aside, I have no doubt that framework developers will continue to learn and improve performance, even as browser vendors speed up their engines and device manufacturers accelerate their products.

Tools:

Web app development tools have come a long way. IDEs like Aptana, Coda, and Espresso are far better than their equivalents a few years ago. And the ability to do real debugging via Firebug or Safari/Chrome’s debugger is frankly game-changing.

That said, these tools are still behind their native counterparts (as well as those for Flash and Silverlight). The gap is closing, but of course each native platform’s vendor has a vested interest in its tools. And truth is, so many of us are so used to Web development anyway that it’s hard to make this feel like a disadvantage. And it’s worth noting that at least on the iPhone, it’s easier to create a custom look for your app via Web tech than native.

The Verdict

So should you build your app using Web technologies? Here’s my advice:

  • If you’re invested in native technologies already and don’t need to expand to new mobile platforms, stick with native.
  • If your app is extremely complex and highly interactive (and especially if you don’t need to customize the look & feel heavily) — or if any performance issue is going to drive you nuts – consider native.
  • In most other situations, at least consider Web.
  • If you’re targeting multiple platforms, or your expertise is largely Web-centric — and if you’re willing to spend some time optimizing — then I certainly recommend Web technologies.

And one final note: this isn’t an either/or decision. Any native app can contain a Web view. If you need native for only part of a cross-platform app, there’s no reason you can’t code other parts of it in HTML.

23 comments
alisnikol
alisnikol

In terms of app experience, native apps can do more. They can easily get hold of swipe events, mutlitouch even, for those platforms which support it. They can access hardware too, like GPS and camera. And with the user's permission, some platforms provide unfettered access to the operating system. Just try detecting how much battery remains with cross-platform with their web technologies like HTML5!

Cross Platform Mobile App Development

mayurimehta2
mayurimehta2

definitely, cross platform with their web technologies like HTML give quick response to users and its support Multi platform so  developer not  to re create code for various platform thus developer likely to adopt this technology .

zqass1
zqass1

Thank you for the thoughtful review. The main advantage of <a href="http://seotoolster.com/seotoolster/html5-player/html5-video-player-audio-player/ "> html5 music player</a>seems to be for embedding rich media such as audio and video in modern browsers. Although, the structure elements seem to be useful. CSS3 seems to be headed in the right direction, leaving many possibilities for implementation and creativity, 

jimbrwn609
jimbrwn609

A lot of apps developers are there in market and undoubtedly they are doing really good job. I appreciate your work. But reducing the security threats in handling sensitive information via apps is very important. It’s a remarkable and serious issue. You guys should work on this issue. Thanks for sharing your information here.

jimbrwn609
jimbrwn609

A lot of apps developers are there in market and undoubtedly they are doing really good job. I appreciate your work. But reducing the security threats in handling sensitive information via apps is very important. It’s a remarkable and serious issue. You guys should work on this issue. Thanks for sharing your information here.

apple.dev.sh
apple.dev.sh

HTML5 can not achieve the performance of animation effects of native iOS app. In our product, UX is very important factor, which consist of animations,transitions etc. JavaScript and HTML can do something like these, but can not do well. That is why we need give up HTML5 in this case. Welcome for correcting by email apple.dev.sh@gmail.com thanks

dfeldman
dfeldman

@webspin Indeed. There's been a TON of activity in mobile JS libraries since I wrote the post, which is exciting.

dfeldman
dfeldman

@webspin Indeed. There's been a TON of activity in mobile JS libraries since I wrote the post, which is exciting.

gorkem.cetin
gorkem.cetin

Thanks for the nice discussion and a comparison between native vs HTML5 apps. Just a heads up: Gideros Mobile (http://www.giderosmobile.com) has just released Gideros Studio, a platform-independent IDE and SDK to easily develop games. It can be used to develop iPhone/iPad games now, but will add Android support soon. And since the application is native, you can benefit from the 2D acceleration feature of the underlying mobile platform. Disclaimer: I personally know the founders of the company.

gorkem.cetin
gorkem.cetin

Thanks for the nice discussion and a comparison between native vs HTML5 apps. Just a heads up: Gideros Mobile (http://www.giderosmobile.com) has just released Gideros Studio, a platform-independent IDE and SDK to easily develop games. It can be used to develop iPhone/iPad games now, but will add Android support soon. And since the application is native, you can benefit from the 2D acceleration feature of the underlying mobile platform. Disclaimer: I personally know the founders of the company.

Changqing Zhou
Changqing Zhou

Hi, Very nice discussion. I came from web dev old school. I like the flashy native apps, but I know as a large company we simply can not deliver cutting edge stuff due to bureaucracy and lack of skill set. So I have been waiting for the moment to come - use web technology for native app. I understand the trade offs. I am willing to take a hit on performance and less flashy UI, since being be able to level my web skills and hosting infrastructure has many pluses for me. My question to the gurus here is, for a simple search app like mine: https://www.lww-trans.com/clinicianSearch.laww (minus the tedious text on the site), would html5 wrapped in PhoneGap be a good starting point? My goal is to be able to deploy an app via appStore and Android Market. The app will speak html5 to my web server that has all the existing java Spring backend stuff. Your comments would be greatly appreciated! Changqing Zhou Minnesota

Changqing Zhou
Changqing Zhou

Hi, Very nice discussion. I came from web dev old school. I like the flashy native apps, but I know as a large company we simply can not deliver cutting edge stuff due to bureaucracy and lack of skill set. So I have been waiting for the moment to come - use web technology for native app. I understand the trade offs. I am willing to take a hit on performance and less flashy UI, since being be able to level my web skills and hosting infrastructure has many pluses for me. My question to the gurus here is, for a simple search app like mine: https://www.lww-trans.com/clinicianSearch.laww (minus the tedious text on the site), would html5 wrapped in PhoneGap be a good starting point? My goal is to be able to deploy an app via appStore and Android Market. The app will speak html5 to my web server that has all the existing java Spring backend stuff. Your comments would be greatly appreciated! Changqing Zhou Minnesota

Dave
Dave

@Andry, I do think the easy distribution and monetization aspect of Apple's store are pretty powerful. But remember you can package an HTML5 app up using PhoneGap or another wrapper and put it in the App Store just like a native app to take advantage of those. That's exactly what I'll do with Pints. Thanks for the info on journaling apps. I'm always looking for a better way to keep notes that syncs in the cloud. (Currently using TaskPaper, which I know isn't quite the same type of app but there's overlap.)

Dave
Dave

@Andry, I do think the easy distribution and monetization aspect of Apple's store are pretty powerful. But remember you can package an HTML5 app up using PhoneGap or another wrapper and put it in the App Store just like a native app to take advantage of those. That's exactly what I'll do with Pints. Thanks for the info on journaling apps. I'm always looking for a better way to keep notes that syncs in the cloud. (Currently using TaskPaper, which I know isn't quite the same type of app but there's overlap.)

Andry Haryanto
Andry Haryanto

Dave, I have seen a lot of articles comparing HTML5 vs native apps deployment, but has yet to find a review as extensive as yours. The previous one covering all of the frameworks was a particularly helpful snapshot. I notice that a lot of developers still favor native apps because it is so easy to monetize - you set a price, list it on an app store, the users buy the app, you make money right away (minus the 30% commission to AAPL). And it is just a much simpler distribution effort because users keep on returning to the app store in pursuit of new apps, giving the products there a higher likelihood to get discovered. Conversely, if you deploy an HTML5 app, I imagine that you would have to run all the "marketing" effort yourself and also set up a payment gateway. Plus the economics would most likely be a subscription model because you are paying for hosting, etc. It is just amazing how Apple has removed so much of this "administrative" barrier of app creation. By way of example, I compared some journaling apps I personally use. There is a service called penzu.com with a web access and HTML5 app (really smooth, btw) - they charge $20/yr. And there is another iPhone+iPad app called Chronicle, one-time cost of $3 each, but it syncs to each other and Dropbox. I would imagine that the latter would be easier to monetize; it would have been much more complicated to deploy and sell were the dev have to do the same in HTML5. There is a place called OpenAppMkt for HTML5, but it does not seem ready for primetime. That said, what is your take on these non-technical aspects (monetization and distribution) of HTML5 vs native platform?

Andry Haryanto
Andry Haryanto

Dave, I have seen a lot of articles comparing HTML5 vs native apps deployment, but has yet to find a review as extensive as yours. The previous one covering all of the frameworks was a particularly helpful snapshot. I notice that a lot of developers still favor native apps because it is so easy to monetize - you set a price, list it on an app store, the users buy the app, you make money right away (minus the 30% commission to AAPL). And it is just a much simpler distribution effort because users keep on returning to the app store in pursuit of new apps, giving the products there a higher likelihood to get discovered. Conversely, if you deploy an HTML5 app, I imagine that you would have to run all the "marketing" effort yourself and also set up a payment gateway. Plus the economics would most likely be a subscription model because you are paying for hosting, etc. It is just amazing how Apple has removed so much of this "administrative" barrier of app creation. By way of example, I compared some journaling apps I personally use. There is a service called penzu.com with a web access and HTML5 app (really smooth, btw) - they charge $20/yr. And there is another iPhone+iPad app called Chronicle, one-time cost of $3 each, but it syncs to each other and Dropbox. I would imagine that the latter would be easier to monetize; it would have been much more complicated to deploy and sell were the dev have to do the same in HTML5. There is a place called OpenAppMkt for HTML5, but it does not seem ready for primetime. That said, what is your take on these non-technical aspects (monetization and distribution) of HTML5 vs native platform?

Timo Pietilä
Timo Pietilä

Great post! My company Zonear develops customized mobie map applications and we've also embraced the mobile web approach and I must say that nowadays there's not much difference in user-experience between native and browser-based app. check out: http://zonear.com/2010/12/industrial-tampere-mobile-tour/ For us the only tricky thing we've not found a proper solution yet is the pinch-to-zoom as in some Android browsers (at least in HTC desire) the meta-tag for disabling the browser's own pinch-to-zoom doesn't work. This understandably causes some layout problems when both the app and the browser tries to zoom.

Timo Pietilä
Timo Pietilä

Great post! My company Zonear develops customized mobie map applications and we've also embraced the mobile web approach and I must say that nowadays there's not much difference in user-experience between native and browser-based app. check out: http://zonear.com/2010/12/industrial-tampere-mobile-tour/ For us the only tricky thing we've not found a proper solution yet is the pinch-to-zoom as in some Android browsers (at least in HTC desire) the meta-tag for disabling the browser's own pinch-to-zoom doesn't work. This understandably causes some layout problems when both the app and the browser tries to zoom.

Dave
Dave

Jouni, Thanks for the interest! I just posted a follow-up answering the first part of your question. Let me know if that helps. http://t.co/LsnGpBR As to the Cocoa wrapper: I doubt there's much peformance difference there vs. running in Safari proper. It's the same engine in a different context.

Dave
Dave

Jouni, Thanks for the interest! I just posted a follow-up answering the first part of your question. Let me know if that helps. http://t.co/LsnGpBR As to the Cocoa wrapper: I doubt there's much peformance difference there vs. running in Safari proper. It's the same engine in a different context.

jouni
jouni

Hey David, Great post. Would you be able to share the css/js optimisations that gave you the most performance boost in the browser? I've played around with jQuery Mobile but like you say, list scrolling and page transitions are somewhat choppy compared to native performance. Also - do you see a large performance increase when you wrap your app inside a native Cocoa wrapper? Thanks!

Trackbacks

  1. [...] previous post took a high-level look at HTML5 vs. native for mobile apps, concluding that HTML5 is ready for prime time but not necessarily for everyone. I also mentioned [...]

  2. [...]  Is HTML5 Ready for Prime Time vs. Native? (Mobile App Development) [...]

  3. [...] Touch, jQuery Mobile, jQTouch, and Titanium Mobile. Setting aside differences among frameworks, I tackled the question of native vs. web and gave a nuanced answer, even a hesitant yes. A year later I’ve abandoned HTML5 and begun [...]

  4. [...] post short, there is a good comparison on the pros and codes of native vs. web technologies here: http://interfacethis.com/2011/is-html5-ready-for-prime-time-vs-native/ and many other comparisons that you can find on the Internet. But you will appreciate the [...]