On HTML5 and native

A few months ago I wrote on my disbelief of HTML5 being the right tool for everything�. Some people took that as me saying HTML5 is useless.

That’s obviously not true and it’s certainly not what I think.

It’s my opinion there is room for HTML5 and there is room for native applications and the decision on what to use should not be taken lightly.

Here are a few questions that may help you to make a wise decision.

 

Target user

Is it corporate? Is it consumer?

Corporate devices are usually under control and users may not be able to install software.

Or traffic may be filtered and users cannot browse to your website to use your webapp and getting the authorization will take months, therefore they give up before they have even started using it.

Or they may be on a slow Internet connection and using that HTML5 webapp that took years to develop and add all those nice effects is hardly possible due to megabytes of JavaScript and images needing to be downloaded.

As for consumers, despite having full control of their systems, it’s not roses either: not all consumers know how to install software and/or they may be scared by UAC dialogs (hint: always sign your software with a certificate whose signature chain reaches VeriSign).

 

Target device

Is it a computer? Smartphone? Tablet? Web browser?

If a computer, is it a PC running Windows? Linux? Mac? All of them?�Are you trying to reach as many platforms as possible?

How old of a computer are you targeting? Pentium 4? Core 2 Duo? Core i5? How much RAM? Try a fancy website with a lot of HTML5 niftiness on an old computer and you’ll probably be surprised at how slow HTML5 can be, even on modern browsers.

 

Deployment

Deploying native applications in corporate environments is a bit of a nightmare due to different operating system versions, hardware, etc

Deploying native applications in consumer computers is only a problem if you are targeting�low-skilled users.

HTML5 is easy to deploy, provided that you can get the user to use a proper version of the browser. This is workable with consumers but often impossible with corporate, so if you go for HTML5 for a corporate application, make sure you support everything from at least down to Internet Explorer 8.

For mobile devices (smartphones and tablets), it doesn’t really matter whether it’s an HTML5 or native application: it has to be installed on the device, the device goes with the user everywhere and when the user moves to another device, re-installing all the applications is a matter of accessing the Apple Store, Android Market or equivalent and say “download it all”.

 

Performance

If you need high performance, then native is going to be the best choice in most cases.

There are a lot of HTML5 libraries, frameworks and toolkits but HTML5 is still far from native performance-wise on all the platforms where a native (or almost native*) SDK is available (which is all of them).

* almost native = .NET on Windows Phone 7, for instance.

 

UI

If you need your application to melt into the platform, then native is the best path: native applications call the platform-specific API, which may have changed from one version of the operating system to another. But it will certainly look as it should. Always.

HTML5 may or may not look good. It may look good today but may not with the next update to the operating system. You may find yourself in need to update to a newer version of the HTML5 framework just to get the application to look native, i. e. no new functionality but a lot of work and cost just to make the application look good in iOS 7.0 or Android 5.0. It’s one of the dangers I described in “HTML5 for everything?” back in January.

 

Connectivy

Applications running fully on device, no matter whether they are native or HTML5, need no data connection.

Applications which access an external server (website, database and/or alike) need a data connection and this may be a problem, especially if the user is out of his area. Roaming charges are steep.

On the other hand…

 

DRM

Native applications can use all kind of tips and tricks, especially on computers (Windows, Mac, Linux, etc)

HTML5 applications running “on device” are quite limited in that regard. You are essentially limited to what the Store or Market provide.

Applications which access an external server (website, database and/or alike) are in the best position for copy-protection: the only way users have to not pay is to find a hole in your authentication system, account creation mechanism, etc. Difficult.

 

Future-proof

Native code is native and that’s good. Dynamically-linked native code always calls the native APIs and those APIs do the right thing when a new version of the operating system is available.

On mobile platforms, HTML5 is almost native these days but supporting several versions of browsers and/or browser engines is becoming a hassle. It will become a very serious problem soon.�Wrapping HTML5 around a WebKit to have a “native” application (like PhoneGap does) gives you the advantage of supporting only a few browser engines, although you still have the

On desktop platforms, HTML5 is not native by any means and the pace at which browsers are being updated make is almost impossible to adapt to. Even if you are using libraries (jQuery, ExtJS, Kendo), frameworks (Rails, CodeIgniter, Wicket), etc

There is a third approach some libraries (such as Unity 3D) are taking: use a plugin. Be it a “private plugin” (Unity Web Player) or a “generally available plugin” (Flash). In my opinion, both of them are a recipe for trouble and should only be used as a last-resort mechanism to reach a platform quick.

 

Resources

Human resources, I mean.

If you want to be native on each platform, do you have enough developers to reach all the platforms you want to reach?

If you don’t, can you afford them?

Are your developers skilled enough? If they have to learn each platform’s technology on the spot, your project may be too late.

HTML5 toolkits allow to you develop a single application for all platforms. They may not look perfect but you shouldn’t dismiss HTML5 if you are tight on resources.

 

Time to market

Time to market is everything. If your application is too late, you may lose all your potential business to some competitor.

Do you want to release for all the platforms at the same time? As each platform’s application is ready? Maybe first use HTML5 to quickly reach all platforms, then replace that with native applications on mobile platforms?

It might even be the case you can afford (both on money and technical criteria) to reach all the platforms at the same time but you want to do some A/B testing (using one platform as A and the other as B), therefore you want slightly different applications?

 

Download size

There are two things to consider here: application size and toolkit size.

The application size may vary depending on whether you use native toolkits (be it native code or the platform-blessed HTML5 toolkit) or a cross-platform toolkit, but that’s generally not important.

Applications developed with cross-platform toolkits are usually a bit smaller because those toolkits usually provide a lot of functionality you don’t need to code yourself.

Problem is the cross-platform toolkit size.

If you use Cocoa on iOS, Silverlight on WP7 and Java on Android, then you don’t need to download anything in addition to your application:

But if you use a cross-platform toolkit, if it’s the first time the user downloads an application that requires that toolkit, there is an additiona download involved. And that download may be in the tens of megabytes, which is a lot over 3G, which means users will only purchase your application when on wifi.

	Using platform-provided toolkit	Using cross-platform toolkit
Application size	Whatever	~Whatever
Toolkit size	0 (zero)	1-20 MB

 
 

Footprint

A second problem caused by cross-platform toolkits is your application will need more space on disk (installation size) and more memory (RAM) than if you develop an application specifically for one device.

If you want to reach the users running the first smartphones, which had only 192 MB of RAM or even less, using a cross-platform toolkit is almost immediately a no-no.

If you are thinking in static linking to reduce the download size and/or footprint, better think about it twice: some app stores may not allow it.

 

Maintenance

How long will your application live?

Is it a one-off application that will reach its peak, you make money and forget about it? Or do you intend to provide updates and/or keep adding features for a long time?

If the former, maintenance is not a big hurdle: you have essentially decided there will be little or none.

If the latter, then you better consider maintenance.

As I said above, HTML5 applications suffer from the “web moves too fast” syndrome and you may find yourself in need of releasing a new version of the application just because a new version of some browsing engine is available. Sooner or later that will boil down to releases which add no new features but just fix the behavior for a new version of WebKit or Trident. Wrapping your HTML5 application into a native WebKit wrapper provided by you (via a cross-platform toolkit such as Qt) may be an option worth considering: it “freezes” the browser engine your application will use.

Native applications may also suffer from changing APIs but when that happens is usually due to a bug or change in app store policy. There is more stability in the native world.

If you are going to keep adding new features to your application, using a cross-platform toolkit ensures you will only need to add them once (maybe with some platform-specific code some times). Instead of implementing the same feature for iOS, Android, BlackBerry 10, Windows Phone 8 and Symbian, you can implement it once in Qt.

 

Licensing

Vendor-provided toolkits are generally free: iOS SDK, Android SDK/NDK, a variety of SDKs for BlackBerry, etc.

Most HTML5 and cross-platform native toolkits are available for free (support being available only via forums, mailing lists, IRC, etc) and also offer a paid version which includes support. You are in fact essentially paying for premium support, something some vendor SDKs do not offer.

If support in the form of a guaranteed response in a reasonable time is important for you, you should know using a third-party development toolkit offers you this possibility. Prices are usually around US $1,000/developer/platform/year.

 

My advice

If you can afford it

• Native mobile app for iOS using iOS SDK
• Native mobile app for Android using Android SDK/NDK
• Native mobile app for Windows Phone 7 using .NET
• Native mobile app for BlackBerry using the Qt SDK (Cascades)
• Native mobile app for Symbian using Qt
• Native desktop app for Windows, Mac and Linux/Unix using Qt
• Web app using Wt and Kendo widgets (check their grid)

You will be able to share code in all the Qt versions (at least the backend, maybe some UI stuff too).

You may also be able to reuse some of the code from the Qt version in the web version via the wtwithqt library.

Depending on how old the Symbian device you are targeting, you may be limited to Qt 4.6. Check the support table over at qt-project.org.

If you are tight on money

• Native mobile app for iOS, Android, BlackBerry and Symbian using Qt (useful links: Qt for iOS, Qt for Android)
• Native desktop app for Windows, Mac and Linux/Unix using Qt
• Web app using Wt and Kendo widgets (check their grid)

The main problem with Qt on iOS and Android is the download size and the footprint. If you are targeting first generation devices, this may not be possible.

No, I have not forgot about Windows Phone in this “category”. But it’s such a niche market that deciding on developing something for WP7 requires careful study on ROI. As for WP8, very little is known about the SDK yet, but Qt support for WP8 (via WRT) is expected soon.

If you are really tight on money

HTML5 version for everybody using PhoneGap or similar (consider making it native by adding a WebKit wrapper)

or

Web app for everybody using Wt and Kendo (this will require network access, so it may not be an option unless your application can require network access for some feature)

If you need a something done quickly

Use Flash or something like Unity 3D for every platform (including the web: Unity Web Player).

You need to be aware anything that requires a plugin is quickly getting deprecated and/or may even not be available to a large segment of users (e. g. Android 4.0 no longer includes Flash, neither Unity nor Unity Web Player are available for Linux, etc). If you intend your application to live long, you may need to replace it later with one of the recommendations I’m giving above.