[zanny]

Qt just released 5.1, which has prelimiary ios and Android support. By the end of the year, you will be able to write a Qt application, and use a QML ui. You can even use one single UI across all devices, where the UI dynamically adds or substracts elements depending on screen size. IE, responsive design for applications.

It is pretty close to write once, run anywhere. The only downside is if your app is the first qt app installed on an ios / android device, it forces a download of the shared libraries which are quite large. You also have to build the applications against individual platforms, since you are using C++, and the finished binary is a native application that uses the qt libraries to launch the qml engine and v8 for the javascript parts.

One experiment I am anxious to see come to fruition in the qt space is the KDE project to get qml apps running in the browser : https://projects.kde.org/projects/playground/www/qmlweb. Since QML is inherently javascript, a web app could only use javascript / qml to create a restrcited sandbox (or nacl / other browser equivalent for the c++ parts) and the entirety of qtquick is designed around high latency elements, so it can support network transport.

[grey-area]

On iOS at least dynamic libraries are not allowed outside those Apple provides, so I'm not sure how that would work. I imagine they'll have to compile in the Qt runtime on iOS at least. I'll be interested to see their efforts in this space, but Qt everywhere is not particularly attractive to me, nor is working in C++ or javascript with qml.

I do wish these platforms were a little more agnostic to the technology used in their API, and had simple C bindings anyone could write glue code for to use their favourite language. Learning yet another markup language and using C++ in order to create apps doesn't really appeal. Whatever the platform insists on as glue is what we'll have to use though, as usual. Personally I'm going to look into the webapp support in Ubuntu Phone to see if it supports local web apps, and hope that I can use that glue to get at any device state that I need to access.

As to qml in the browser, I'd really rather have web apps on the desktop than start writing websites in qml, I'd be very surprised if that catches on.

[lukifer]

> The only downside is if your app is the first qt app installed on an ios / android device, it forces a download of the shared libraries which are quite large.

How does this get around sandboxing on iOS? My fuzzy understanding is that components would need to be downloaded for each app independently. And is there a reason those shared libraries can't be bundled?

[zanny]

No idea, never tried it. A cursory browsing of qt documentation suggests it can't, and it also can't use qtquick2, which is where qml becomes really useful (which is also when it starts using v8).

[sho_hn]

That's incorrect. QML has used v8 since its initial appearance in Qt4. In fact, it will move away from v8 in Qt 5.2 is the current plan.

[zanny]

http://blog.qt.digia.com/blog/2013/03/05/qt-for-ios-preview/

According to the qt blog, only qtquick2 depends on v8.

[sho_hn]

You're right, sorry - replacing JavaScriptCore with v8 indeed only happened for Qt 5. However, v8 is indeed on the way out again, as mentioned: http://blog.qt.digia.com/blog/2013/04/15/evolution-of-the-qm...