Cross Platform Apps – Qt vs. HTML5

Although building a separate native app per platform is currently proving to be the most successful approach for mass market consumer apps, there are still a lot of situations where it makes more sense to go cross-platform. In this article we’ll look at the most popular option, hybrid web apps built with HTML5, versus an up-and-coming challenger, Qt.


How do you build web apps? Take the Developer Economics Survey and let us know. Cool prizes await you.

Why Qt?

Those who know the history of Qt may be surprised to see it described as “up and coming”. Qt was originally designed for building cross-platform desktop apps, it’s creators started working on it in 1994! However, Qt became interesting for mobile development after Nokia bought Trolltech, the company developing Qt at the time, and invested heavily into making it the ideal toolkit for building mobile apps. Unfortunately, Nokia was making this strategic decision shortly before the iPhone launched (the acquisition was completed afterwards). This changed the game from building apps for devices with numeric keypads and Qwerty keyboards, to large touch-screen based devices. The former Trolltech engineers recognised that they needed a very different way of creating apps for Nokia’s offering to compete.

When Steve Jobs said that the iPhone was 5 years ahead of the competition at launch, he was not far wrong. Android had managed to close some of that gap, probably due to executives at Google having some advanced warning about the iPhone. Unfortunately, Nokia eventually gave up on it’s own Qt based devices in favour of Windows Phone as the software efforts were taking too long and they were falling a long way behind in the ecosystem wars. They sold Qt to one of their major services company suppliers – Digia – who have recently established a fully-owned separate entity for the product, The Qt Company. Only after being fully disentangled from Nokia has Qt been able to return to its roots as a cross-platform framework and start supporting the major mobile platforms. However, in the mean time, others had seen the great foundation for mobile apps that Nokia’s investment created. As a result the BlackBerry 10, Jolla Sailfish, Ubuntu Mobile and Tizen platforms all have Qt as a core framework.

From a personal perspective, I re-wrote a popular iOS game for Symbian using Qt in early 2011. The UI design and general debugging tools were a bit immature at the time but it was one of the simplest learning curves and most pleasant development experiences I’ve had on any platform (note: I was not paid to say that), even though the core of Qt is using the less than developer friendly but high performance C++. I was able to achieve smooth 60fps performance on some rather low-spec hardware. It was easy enough to learn their new UI technology, Qt Quick, and build the menu screens for the game with it in a couple of days.

Why HTML5, or why not?

HTML5 is the most popular option for developers building cross-platform mobile apps, however, it appears to be falling out of favour a little. Web browsers and web views are available on every platform and web developers are able to transfer their skills from building websites to building mobile apps. Open source frameworks like Cordova (PhoneGap) allow developers using HTML5 to access additional mobile specific functionality and make it easy to package apps in a native format for each platform. The added bonus is that you can usually have a version of your app on the web as well as in the app stores for minimal additional effort. HTML5 is generally more productive for building UI centric applications than native apps. There is also an embarrassment of riches when it comes to libraries and frameworks for building mobile web apps. Hybrid web apps are in the privileged position (on iOS at least) of being able to update their code directly, avoiding the App Store review process for all but major changes.


Given its ubiquity and large developer base, why isn’t HTML5 the default cross-platform approach? [tweetable]Despite many advantages, hybrid web app developers have been struggling with performance[/tweetable] (partly due to crippled or outdated webview implementations, an issue which has been fixed in the latest versions of iOS & Android, although this will take a while to penetrate the entire installed base). There is also an issue with varying levels of support for standards across mobile browsers (again, this is something that’s improving but not entirely fixed yet). Web technologies have also not really been designed for the highly animated UIs that are now expected by mobile users. This is something that the much hyped framework aims to resolve.

A number of very high profile consumer startups have publicly switched from web hybrid to native mobile app approaches. The most common reason stated for these switches has been lack of adequate tooling. It’s certainly possible to make web apps perform well on mobile devices within their limited memory budgets but with the current state of debugging and profiling tools, that’s still not an easy thing to do compared to producing native apps. This said, not all apps need flawless UI animations and we’re not comparing HTML5 with native, so lets look at how it goes head to head with Qt.

Qt vs. HTML5 – Pros & Cons

Supported platforms:

  • HTML5 is supported almost everywhere.
  • Qt is supported on all major platforms (and minor ones that happen to use it for their UI).

Although in theory you can target more platforms with HTML5, this is not how most developers are using it in the real world. [tweetable]HTML5 developers are increasingly abandoning the browser and building hybrid apps[/tweetable]. Most mobile developers are targeting some subset of Android, iOS, Windows Phone, Windows 8 and BlackBerry 10. Qt supports all of these and more. In fact, in practice our data shows that Qt developers actually target fractionally more platforms on average than HTML5 developers. As a result, this is basically a tie for most developers with a significant advantage to HTML5 for those who really want to run their software everywhere (feature phones, Smart TVs etc.).


Learning curve:
This one depends whether you’re already a web developer. If you are, learning to build mobile web apps is probably easier than learning Qt. However, if you’re new to either then Qt has significant advantages in terms of having one framework to learn rather than 10s of them to choose from before you even start. Qt also has great documentation, which isn’t necessarily true for all web frameworks. In a fair contest, this is a clear win for Qt.


  • HTML5 is open standards based and there are multiple open source implementations.
  • Qt is open source but dual licensed and effectively controlled by a single vendor.

Clearly HTML5 is more open than Qt. This isn’t always an advantage. The process of creating standards and getting multiple vendors to implement them is slow, Qt can be more agile. If you really need something fixed or a new feature added in open source you can do it yourself or pay someone to do it. If you need to support Internet Explorer and there’s an issue with it, you have to work around or wait for Microsoft. Then again, there’s no vendor lock-in with HTML5 and the web isn’t going anywhere. Someone else could buy Qt and take it in a direction that doesn’t align with your goals. Or they could just put the price up beyond your budget. HTML5 has the edge but it’s not a clear win.


  • Building for HTML5 is free. There are some non-essential paid tools that can help.
  • Qt requires a commercial license for most commercial use on mobile.

Qt’s open source licenses are not compatible with distribution on most app stores. Although the iOS port of Qt is developed in open source, you need a commercial license to ship apps in the store. The lowest cost subscription that allows developing mobile apps for the iOS & Android stores with Qt is $25/month. HTML5 wins.

Cross-platform compatibility:

  • HTML5 has multiple independent implementations of a standard.
  • Qt has one vendor implementing the same runtime on multiple platforms.

Multiple implementations, with several in open source and a large community reporting on and working around compatibility issues makes for a very robust platform. Even so, having a single vendor making sure all platforms behave in the same way is almost always better for compatibility of your app. Qt wins.


  • HTML5’s DOM was not built for modern mobile apps.
  • Qt Quick’s (QML) scene graph is built directly on top of OpenGL ES.

Both environments use JavaScript. However, with Qt it’s much easier to drop down to native code if you really need native platform functionality or performance. The performance penalties for switching between JavaScript and native code are much lower with Qt. The biggest difference however, is graphics performance. People looking for serious graphics performance with HTML5 resort to complex schemes to avoid touching the DOM as much as possible. Building the entire UI on top of WebGL seems like the most promising path to future performance, now that WebGL has much wider support (Apple adding this in iOS8 is key). Qt has a massive advantage here, it also has more extensive animation options than CSS3 for web app developers.

Native user experience:

  • With HTML5 you rely on either a 3rd party framework like Ionic or building your own clones of native interface elements.
  • With Qt you can use components that clone native interface elements, or use real native UI calls.

Being able to call native APIs in Qt potentially gives it the advantage here but in reality this loses cross-platform compatibility. In practice neither option is really well suited to situations where you need a genuinely native user experience. Both can emulate one adequately for a subset of possible apps. In general it’s best to use a cross-platform approach where a fully custom UI is needed, or a native look and feel is not essential.


Comparing across these metrics, Qt has a slight edge over HTML5. However, there are other metrics you could use that would give the opposite result. In practice the technology needs to be selected to fit the project. Both options have merits and if you’re an HTML5 developer who’s not already familiar with Qt’s offerings, they’re worth a look. I also didn’t mention that Qt apps can display HTML5 content in a webview, meaning that it doesn’t have to be one or the other, it can be both.


Which one do you prefer? Take the Developer Economics Survey and let us know.


Pros and Cons of the Top 5 Cross-Platform Tools

As the market temperature for cross-platform tools (CPTs) continues its steep climb into hotter territory, it’s understandable why many feel we are witnessing a mobile fragmentation that is perhaps much larger and more significant than the recent wars waged over the desktop. If this fragmentation tells us anything, it’s that [tweetable]cross-platform tools for mobile development are often not a “one-size-fits-all” solution[/tweetable] – and that there are numerous veteran users of these tools that do not believe the problem has been solved as well as it could be….yet. In our Developer Economics Q1 2013 report, the breakdown of the top CPTs looks like this:


How many of these tools do you know? Test your skills in the new Developer Economics Survey and win awesome prizes.

As you’d expect, each approach comes with trade-offs. Let’s examine the top five cross-platform tools (PhoneGap, Appcelerator, Adobe AIR, Sencha, Qt), as identified in our research, and list out the more salient pros and cons of each. This is not an exhaustive list, of course, as each platform can’t be explored in depth in one post alone. Want toexplore more cross-platform tools we’ve identified? Check out the CPT section on our ToolFinder tool atlas

Apache Cordova/PhoneGap

Apache Cordova (known by many as “PhoneGap“) holds the top slot in developer mindshare. Cordova/PhoneGap developers write their mobile applications using HTML, JavaScript and CSS. These assets run in a “WebView” inside a native application container on the target platform. It is, conceptually, a web application packaged within a native application container where your JavaScript has access to device-level APIs that normal web applications would not (more on that below).

The name “PhoneGap” is quite possibly one of the more recognizable names in this space. Originally created by Nitobi, the name was changed to “Apache Cordova” when it was donated to the Apache Software Foundation. Adobe purchased Nitobi – including rights to the PhoneGap name – and now distributes Cordova under that name.


  • Regardless of server side platform & language experience, a significant number of developers have experience with HTML, JavaScript and CSS. Apache Cordova allows developers to immediately leverage these existing skills. The value of this can’t be overstated – as it reduces training and can enable a quick-to-market stance in companies ready to adopt it.
  • Cordova apps install just like a native application, and are able to leverage app store discoverability.
  • Cordova follows a plugin architecture, which means that access to native device APIs can be extended in a modular way. There are a lot Cordova/PhoneGap plugins to choose from – enabling developers to focus on the web-based skills they already have. (This is a weakness as well, as we’ll see in a moment.)
  • Cordova is open source and free, so there are no licensing costs (also a potential weakness, mentioned below).
  • Cordova/PhoneGap solutions existed in this space early on, and have matured to the point where value-add offerings on top of the basic CPT are the norm. For example, both Adobe’s PhoneGap Build and Telerik’s Icenium enable developers to build for supported target platforms in the cloud, without local SDKs (meaning non-Mac users can build iOS applications). In addition to Icenium’s cloud build services, Telerik also provides Kendo UI Mobile (an MVVM framework targeted for performance on mobile), app analytics via EQATEC and a Backend-as-a-Service (BaaS) offering named Everlive. Adobe has integrated PhoneGap Build capabilities into Brackets (a web based IDE) and Dreamweaver.


  • Of course, being free is no guarantee of success. In fact, the emergence of PhoneGap Build and Icenium are clear demonstrations that a “bare bones” Apache Cordova is woefully incomplete. The strength of being open source – and leveraging the talents of a wide array of contributors – is both a blessing and curse. If you need to extend your app with a custom Cordova/PhoneGap plugin, odds are you will find one. Yet it may be out of date and not support the target platforms you need.
  • The plugin architecture works well if you can find the plugins you need or if your web developers are capable of changing gears to write their own custom plugin(s) as needed. However, odds are that you chose Cordova, in part, to avoid the need for specialized native platform skills.
  • The performance of Cordova/PhoneGap apps has often been criticized. Native UI will always outperform a hybrid solution, but improvements in device hardware and WebView implementations have narrowed the gap. Your web developers will need to pay close attention to performance, which means their knowledge of profiling tools as well as which web UI frameworks are mobile-friendly is essential.


Appcelerator’s Titanium provides a unified (across devices) JavaScript API, coupled with native-platform-specific features. Developers write JavaScript and utilize a UI abstraction (the Alloy MVC framework) that results in the use of native UI components, greatly aiding UI performance compared to other hybrid options.


  • The use of native UI components is a performance win, and the Alloy framework attempts to normalize UI across platforms.
  • The use of JavaScript to normalize code across platforms enables you to leverage existing skills on multiple target platforms.
  • Appcelerator provides value-adds such as a Backend-as-a-Service (BaaS), app analytics and a marketplace for 3rd party components.


  • Developers are required to manage target platform SDKs locally. It’s highly recommended for your team to establish a controlled build environment/CI process if you choose to manage SDKs locally, especially if you target multiple platforms. SDK version & build-related issues can be a horrific time sink, when you really need your team delivering features.
  • Normalizing the UI across platforms, while arguably a “pro”, is also a “con” in that your team will need to train on a proprietary technology to gain skills that are not directly transferrable outside Titanium.

Adobe AIR

Adobe AIR is “a cross-operating-system runtime that lets developers combine HTML, JavaScript, Adobe Flash® and Flex technologies, and ActionScript® to deploy rich Internet applications (RIAs) on a broad range of devices including desktop computers, netbooks, tablets, smartphones, and TVs.” The problem with that description is that you cannot use HTML & JavaScript to write Adobe AIR applications for mobile applications (Flash/ActionScript skills need only apply).


  • Adobe AIR has impressive reach – running on a wide array of desktop and mobile devices. In addition, if you plan to have a more involved/animated UI (and don’t plan to use a native approach), using AIR over a HTML/JavaScript/CSS approach may help.
  • Most Flash/ActionScript developers consider the IDE tooling for these technologies as mature.


  • The “elephant in the room” for many mobile developers is the fact that Adobe purchased Nitobi (and the rights to the PhoneGap name), clearly signaling to many that AIR may not be a long term strategy for mobile development. This combined with the rapid decline of Flash erodes the confidence many developers might otherwise have in choosing AIR.


Sencha Touch is an HTML5 mobile application framework for building web applications that look and feel like native applications. Apps built with Sencha Touch can be used with Apache Cordova/PhoneGap or Sencha’s native packager – either which will package the application in a native container and enable access to select device-level APIs unavailable to traditional web apps.


  • Sencha have produced a larger quite of interoperable products, from “Sencha Architect” (a visual HTML5 app builder) and “Sencha Touch Charts” (for data visualization) to IDE integration with the Sencha Eclipse Plugin and an secure Enterprise app deployment story with Sencha Space.
  • Sencha Touch offers an MVC style architecture, a library of UI components, an extensible API and UI themes among other features.
  • Native packaging is possible via Apache Cordova/PhoneGap or Sencha’s SDK.


  • Mobile apps written with Sencha Touch can suffer from the same performance pains as Cordova/PhoneGap apps if developers aren’t disciplined in writing efficient JavaScript and DOM structure(s).
  • Many developers already have established opinions and experience with preferred frameworks for building HTML5/JavaScript/CSS based apps. Sencha’s emphasis on its own stack will be perceived as vendor lock-in.
  • Extending a Sencha Touch app with access to additional native APIs will likely involve writing custom Apache Cordova/PhoneGap plugins. This will require specialized platform skills (or training to acquire them).


Qt (“Cute”) is a cross-platform development tool that targets a number of embedded, desktop and mobile platforms. Developers write using “QML“, touted as a “CSS & JavaScript like language”, and apps are backed with an extensive set of C++ libraries, and utilize graphics/UI components written in C++. [UPDATE: As clarified by @qtproject, “Qt exists as a free and open source version from @qtproject and a commercial offering on top, from @QtbyDigia“]


  • Qt provides a substantial set of libraries containing intuitive APIs for things like threading, networking, animations and more.
  • Qt’s IDE tooling (Qt Creator IDE & Qt Designer) appear to be solid development tools, and code profiling is available in QML Profiler.
  • Qt Linguist enables translation and internationalization in applications – giving you the support of multiple languages within your app (in a single binary).

Cons [updated thanks to new information from Digia]

  • Qt’s tools are advertised as a “complete tool chain”, and QML is a proprietary language specific to Qt’s stack. Committing to this approach could be seen by many companies as ‘platform lock-in’, given that most businesses are seeking to re-use existing skill sets when adopting a CPT, not fragment skills further. (The leap from JavaScript to QML may not be as far as a leap from web-based skills to Objective-C, for example – each team just needs to evaluate what it can handle).
  • [Updated] Originally we listed pricing as a “con”, since full commercial support could exceed €4,000 (this includes plug-in development, platform development, device modification as well as unlimited support and updates). The cost of this kind of support is significantly higher than support costs for the other CPTs we’ve looked at. However, Digia reached out with a link to the recently announced Qt Mobile Edition. According to Digia the monthly fee will be $149 (approximately €110) and will launch in the coming weeks after the release of Qt 5.2.  This pricing level puts Qt’s mobile development costs more in line with the alternatives we’ve discussed. (It’s also important to note that Qt supports an open source LGPL v2.1 license.)

Reality: You’ll Probably Use More Than One

In our Developer Economics 2013 report, we noted the following:

Developers most often use several cross-platform tools; on average CPT developers will use 1.91 CPTs, confirming the lack of maturity and niche nature of cross platform tools much like we observed in our dedicated CPT survey just over a year ago. Moreover, we found that one in four developers will use more than three cross platform tools.

What CPT(s) do you plan to investigate or adopt? Check out the full list of CPTs we’ve identified.


Which of these are your favourites?  Test your skills in the new Developer Economics Survey and win awesome prizes.