Using HTML5 for Developing Mobile Applications

6 min read

I’d like to dedicate this post to Mark Zuckerberg, even though I fully realize he doesn’t care at all. But still his famous quote with regard to HTML5 being very impactful started many discussions and changed the way how a lot of people saw the mobile technology landscape at that moment.
He’s usually quoted like this:

“When I’m introspective about the last few years I think the biggest mistake that we made, as a company, is betting too much on HTML5 as opposed to native… because it just wasn’t there.”

But he also continued:

“And it’s not that HTML5 is bad. I’m actually, on long-term, really excited about it. One of the things that’s interesting is we actually have more people on a daily basis using mobile Web Facebook than we have using our iOS or Android apps combined. So mobile Web is a big thing for us.”

He said that during TechCrunch Disrupt event which took place in San-Francisco in September 2012.

The most powerful words, characterizing HTML5 technology on mobile platforms, were obviously “the biggest mistake” and “wasn’t there”, and that is exactly what was quoted a lot around the web.

That’s not a rare situation when I’m explaining to business people pros and cons of the HTML5 as a technology to rely on for mobile development. Every time it’s an attempt to reply to either a statement like “We need 100% native application” or to a question like “Why don’t you do this with HTML5?”

In most situations these questions are hardly technical but more of a marketing or sentimental nature. Images of both “native” and HTML5 solutions have been well established by now and not based on rapidly changing reality or facts.

HTML5 is often seen as a “modern”, “future-proof” and “one-size-fits-all” solution. Native applications are considered more robust, reliable and allowing for better and more “native” user interface. Although it’s true to some extent it’s a bit of a stretch as well. At the end of the day it’s more about the code and graphics you can craft, and less about the underlying technology you choose.

But the fact is that not all technologies are created equal and allow you to do exactly the same things within your budget limitations. Depending on your choice, some things will be too expensive, slow to create, hard to maintain, or even all the above simultaneously.


Fragmentation of “native” platforms seems to be an obvious thing, if you develop for both iOS and Android natively you should plan your budget for almost twice more efforts compared to a single-platform application. Almost all your code will be different, if we don’t take into account various cross-platform development technologies.

With HTML5 it’s kinda different. All the platforms that sport modern web-browser will run your HTML5-written application. Some even provide tools to wrap your web application into a “native” shell for distribution in respective application stores. But that’s true only in theory.

Being a relatively modern technology, HTML5 is rapidly evolving, not fully and evenly supported on every mobile platform and therefore fragmented across mobile space even more then on desktop browsers. A number of participants involved into the process of updating specification and developing its various implementations in web-browsers is very significant and includes W3C participants contributing to specification, multiple web browsers and mobile platforms vendors. Hence platform fragmentation, not that obvious form far distance, but well known by any developer who has tried to maintain complex web application for a variety of mobile platforms.

These costs are hard to predict and calculate in advance, even Facebook couldn’t.

Performance limitations

When you develop an application to run in a web-browser you are relying on the browser to execute your code fast and in the way you expect it. For some tasks you are always on the safe side with this assumption, but not for all.

If your resources are limited, like they still are with any mobile device, and your application is heavy you will likely to run into problems optimizing resources usage and tuning application performance. And at some point you may realize that all you have done is not enough, but you cannot move any further. It’s either your budget has drained, or your code is already perfect, but a browser is not running it as well as you want or expect it.

That’s the dead-end situation I don’t want anybody to get into in their projects, but that’s clearly possible.

With “native” technology, where the limit is still reachable, it’s further from you and you can still get a bit more of horsepowers out of the device using various optimization tricks. They could be expensive, even too expensive, but they pretty much always exist.

User interface

It’s definitely possible to create a user interface that will look great, feel responsive, and easy to use with HTML5 on any platform. But if you don’t want your application to look and feel like a mobile website you will have to mimic some of a platform’s features including navigation patterns, common interface elements and many other. Moreover you will have to do it for each target platform.

Very talented designers and developers are required to achieve the state and quality of the user interface which iOS and Android frameworks provide you with out of the box.

It’s equally hard to find classy looking applications for any platform, though, and at the same time, for any platform they do exist.

When to use HTML5 and when not to?

This is the way I see to ask this question correctly. But the answer will depend on many factors, both technical and business. Here are the questions you need to answer first.

Technical questions:

  • Will your application be indifferent to limited resources and performance?
  • Are you OK working within fragmented and rapidly changing environment of mobile browsers?
  • Are you ready to workaround web-browser bugs or wait for fixes?
  • Will it be OK for your application to have unified user interface across all platforms, or are you ready to invest into custom interface version for each one?

Business questions:

  • Do you have enough development and design resources ready to craft your HTML5 application?
  • If your application is not B2C, can you sell it to your potential buyer with “Made with HTML5” tag on it?
  • Do you have a clear understanding of a distribution channel for your application and what will the added cost of this channel be for you and for your customers?
  • If you are in software development business, what are your long-term plans? What expertise do you want to develop and cultivate in your company?

If most of your answers are positive and clear to you, then you are ready to jump onto the HTML5 train and be optimistic about HTML5 future as much as Mark is.