Many software-as-a-service providers have taken the HTML5 and Responsive Design approach when delivering applications to smartphones. But are HTML5 applications as good as native Apps, and who will win in the long run?

What’s the difference?

Native Apps are programs that you download, usually from an App Store, and then run on your smartphone. HTML5 is a new version of the language that browsers use to show pages that, together with a technique called Responsive Design, allows you to run Cloud applications on a small device with integration into the handset for mobile features such as making calls.

Because Apps are running on the smartphone, they tend to integrate better with the handset for making telephone calls, sending emails and linking into other local Apps such as address books and maps. They can also store data locally, so can be used when there is no Internet connectivity.

HTML5 applications are run using the smartphone’s browser. Like Cloud applications, all the software and the data are held in the cloud, so they need an Internet connection. They can integrate into smartphone features such as calling and email, but sometimes not so slickly.

So why bother with HTML5? The reason, for developers, is the number of platforms that need to be supported if you go down the App route.

Platform fragmentation

In the beginning there was the iPhone, and it was good. Apple does a good job of making sure that applications run consistently across its devices, as it controls both the hardware and the operating system. But then along came Android, offered free to handset manufacturers who could tweak the operating system as they wished.

According to the latest figures (Gartner, Q2/2013) Android now has a 79% market share, up from 64% a year ago, with Apple at 19% and Windows Phone at 3%. Android and Windows are implemented by each handset manufacturer, which can result in discrepancies in the way apps can run, the bane of app developers. And now, just to add to the fun, both Mozilla (who make the Firefox browser) and Ubuntu (a popular Linux) are saying that they’ll launch open source handset operating systems as well.

So App developers have to offer an iPhone version, and an Android version, and maybe a Windows version, and then deal with all the different issues that multiple handsets create, plus the multiple versions of each operating system as they get updated. It is the equivalent of trying to offer a desktop product that is available on both Windows and Macs, and possibly Linux as well. You can use development tools to try and write platform independent code, but it is hard work keeping up.

Hence the attraction of HTML5 + responsive design. For cloud application vendors you can just write one product, available on desktops, tablets and smartphones, and the HTML and browser will automatically adjust the page to fit the device, and you can also integrate into device specific features such as calling a number.

Sync, data storage and updates

The good thing about Apps is that they run quickly and, because they can hold data locally, don’t need an Internet connection. However, all those benefits have corresponding drawbacks.

If you hold data locally, you need to sync into the main application sometime. That means that your data may be out of date, and there may be update conflicts when you sync. It also limits the amount of data you can hold – you can’t hold a million contacts on your smartphone.

If you are running the application on your local device then that needs processing and memory resources, which will limit the functionality and speed. Again, you can’t run analysis on a large data set on a smartphone. You’ll also need to update the app occasionally, by installing a new version. Because of these limitations, most Apps from cloud application vendors offer a trade-off between integration and functionality – you can see and update Contacts in your CRM offline, but you can’t kick off a marketing campaign.

You could argue that the whole point of Cloud Computing is to have no local software or data, so native Apps for Cloud applications is a bit of an oxymoron.

Other platform issues

Tablets are an issue for app developers, do you treat them as large smartphones with yet another app, or do you try and accommodate them within the smartphone app? Not an issue for HTML5 developers, we just define different layouts for different device sizes in the same code.

Although HTML5 developers don’t have to cope with multiple operating systems, they do have to cope with multiple browsers, not all of which have implemented HTML5 in the same way. But this is a similar issue to developing Cloud applications anyway. And there are smartphones that don’t support HTML5 at all, but they are a dying breed.

App Stores

Many users will look for your application in the appropriate App store and will want a button on their screen to call up the app. HTML5 developers can solve both issues by developing a minimal “stub” app, that just hyperlinks to your logon page.

Apple makes a lot of money from forcing iPhone users only to download apps from their App Store, and then taking a hefty cut of the sale. Cloud vendors like us offer a free iPhone app, and then make money from subscriptions that are organised outside of the app itself. Apple may decide someday that they won’t allow such apps in their store, but if they do block such apps then vendors like us will just drop Apple completely.


Today, most people agree that a native App delivers a better user experience than a HTML5 one. But HTML5 applications for smartphones are where Cloud Computing applications were 10 years ago – almost as good, but a bit slow, not as slick, lacking some functionality and need a connection to the Internet at all times. All of which was a turn-off for most people then, but are now solved by mobile Internet and better applications.

So we’ll see the same adoption path for HTML5 as happened for Cloud Computing applications – mobile Internet connectivity will become ubiquitous, integration into the handset will become closer. And if the smartphone market continues to fragment at the rate it is doing today then the pressure to use HTML5 will become irresistible.