HTML 5 vs Native Apps : Platform Capability & UX

13 Apr 2011 - 6:46am
5 years ago
5 replies
1942 reads

I would like to build competence on advising customers to go for HTML 5 app vs Native Apps, in terms of both platform capability knowledge and user experience.

Come forward and share your thoughts.


15 Apr 2011 - 10:03am
Adam Korman

A few reasons to dive in to making a native app:


  • Push notifications. Don't use push notifications just because you made a native app, but do make a native app if push notifications would deliver real value to your customers.
  • Offline access to data. Would your customers want/need to use your product  outside of cell/wifi range (on an airplane for example)?
  • Rich media. Streaming/buffering/caching and format support are much better with a native app.
  • Other native features. If you need integration with the camera, for example, then you have to go native. 


If you just want to create an experience that mirrors what you do on the web, then the HTML5 route is a much easier/faster/flexible path than building (and supporting) a native app. At least for the iPhone, the tools are out there to make a mobile version of your site that looks and works almost exactly like a native app if that's all you really need.

15 Apr 2011 - 11:36am
Jo Packer

  • Analyse your traffic to work out which mobile devices your customers are on to inform your decision. In some cases this could lean way over to iphone, in others android or a real mix. Be aware changes in the market can effect traffic fast.
  • The app stores are a great way to get your brand and app out there, particularly if the app store providers like your app and feature it.
  • Have the 'does this app need to work offline conversation' really early on.

15 Apr 2011 - 4:54pm
Jared M. Spool

This is exactly what Josh Clark is talking about in his UIE Web App Masters Tour talk:

Mobile Apps: Native or Web-Based

If you can't make the 2-day event, you can listen to the podcast on the site. We'll be publishing the audio and slides of his presentation later this summer when we make the full event's program available on our site.

Hope that helps,


Jared M. Spool
User Interface Engineering
510 Turnpike St., Suite 102, North Andover, MA 01845
e: p: +1 978 327 5561  Blog:  Twitter: @jmspool

16 Apr 2011 - 5:43am

I think there is also an ethical perpective to consider here. The web is an open, standards based, device independent platform. If you build using web standards you are contributing to, and pushing forward, the future of shared knowledge, open access and interoperativity. If you build native apps you are contributing to closed ecosystems.

That is a bit simplistic, idealistic and unrealistic. But nevertheless, from your client's point of view, web technologies are a much more future proof investment. Mobile browsers will get developed to bridge the gaps in functionality - chrome is a good example of how Google are already making this happen (e.g. speech input, geo-location). Think of native app platforms as the new Flash. For  a while Flash seemed to offer so much more richness and possibility, but now any company that heavily invested in Flash for their website looks pretty dumb and is incurring cost.

So I think ethics and future-proofing go hand in hand. Of course you have to build something good, but you can also mitigate risk and support interoperability by building as much as possible using standards (whilst also pushing the capabilities of what is possible with standards).

16 Apr 2011 - 9:39am

A few more considerations - coming from overalll product management perspective including UX, Tech and Business.


I am helping a startup define their product roadmap (a mobile product) and suggested going for web base version first as


  1. it's cheaper
  2. the idea needs a lot of customer feedback to refine , native app requires re-installations
  3. Single development can be used for multiple platforms
(Adam's points above cover other capabilities related requirements tied to the purpose of the app)



Native allows for smoother interactions (compare gmail on iPhone browser v/s native apps) , I think a large part of that is because media/images are already loaded in a native app. How ever for the standard app designs there are enough framework available for web that this gap is narrowing. 

Other element to consider is that Android's native design can change with each phone manufacturer. This means standard components like colors of the tabs are controlled by the phone manufacturer's version of OS. 

Every now and then, I also hit into a need that's not natively supported by the APIs but would help UX, so you have to build custom. This becomes and expensive affair and the cost considerations might lead to compromize on UX side.

Supporting Multiple Platforms:

HTML offers a nice cost--effective way develop for multiple platforms. There are frameworks like Titanium where one codes in js and that is complied into a native code for iPhone and Android.  The challenge becomes that Titanium has it's own limitations - it is a sub-set of native APIs. 

This also applies to custom components, it'll far more easy to build it in HTML then natively.

Supporting Multiple Versions

Most applications would have a web based backend. If so you would need to test for backward compatibility for any new releases where backend is updated.


Hybrid Approach

I have not played enough with this, but another approach is to build the app in HTML+CSS+Js and then build a native app that just loads that in a browser within the app. I have not studies but looks like Netflix does this for iPad. 




Alok Jain

Syndicate content Get the feed