[Interest] Qt mobile apps v native

Jason H jhihn at gmx.com
Sat Jul 11 17:43:07 CEST 2015

> Amongst all the debate around the Indie license, some mention was made of Qt Mobile not quite "being ready yet".
> So, for someone considering Qt for lots of things including mobile, could someone please answer these questions for me:
> 1. Which Qt features do not currently work on iOS or Android?

Qt 5.5 seems to (finally) have everything in sufficient completeness. The issues I deal with are more of feature parity between platforms. Mainly I am referring to image capture, flash, etc. And completeness. By that I mean there is some mobile concept (i.e. Gallery) that you have to write your own code for because it isn't covered yet. (Adding images to the Gallery app is very different on iOS and Android, and there is no Qt API yet). But there should be.
> 2. Which Qt features are likely never to work on those platforms and why?

I can't speculate. I think it'll all work eventually.

> 3. How does the performance of a Qt mobile app differ from a native one (if at all)?

I don't have hard numbers. But from what I can tell, startup is a bit slower due to the additional Qt libraries over a native app. I don't notice any execution speed problems. 

> 4. Are there APIs or features of either iOS or Android that Qt cannot access?

No. Qt can access the frameworks of iOS and Java via JNI on Android.
> 5. How does the look and feel of a Qt mobile app compare to a native one?

This issue is a bit of a red herring IMHO. If you want one code base for all the platforms, you're going to run into issues like no back button on iOS, so your app has to provide one. This then means you won't look native without additional effort to hide the back button which you need on iOS.

That said, the Android port has/is working on a native style. I think there is a community contributed iOS style. But in my apps I use neither. I go for a middle ground that way it's the same app experience on all platforms.

> 6. How does Qt integrate with standard mobile controls and features like tumblers for date selection, word auto complete and auto correct, custom keyboards for each scenario like entering an email address, URL, phone number etc.?

Qt doesn't at this point. However we made one that is 90% of the iOS one in a few hours. Usually we can get something that looks damn close in a few hours, then we re-use it. Keyboards work as expected. Qt has Qt.Imh* constants to specify the keyboard type (Numbers only, etc). 

> 7. How does Qt integrate the native mobile browser in such a way that the standard effects and transformations that can be applied to other Qt objects be applied?

I have no idea what you mean? 

> 8. Are there any legal restrictions on what a Qt app can do on mobile platforms or in relation to suitability for App Store distribution?

IANAL. But we have not encountered any.

> 9. What are some good examples of existing Qt apps running on iOS and/or Android?

We have one app published for both iOS and Android, and another in development. They look very different. A designer was given a few hours of instruction on QML and turned out a great looking app (that's the one in development) and the first one will be retrofitted with his theme. But it looks like however you want it to look. 
Make that it looks however you MAKE it look. 

> Answers to these questions will greatly assist in my decision making process so I would be very appreciative if one or more people could respond to them.

I love Qt. But it has its annoyances. And that is a very loaded statement. I can't possibly break it all down. But:
1. 90% of what you want it to do it can do out of the box.
2. 5% is done wrong, isn't the same, or isn't as good as it could be on one or both platforms. These are usually handled via: if (Qt.platform.os == 'ios' ) {...}
3. The remaining 5% is not yet attempted, and you'll find some stack overflow question that will tell you how to do it natively that you have to shoe-horn into Qt, or  use the C++ parts of Qt to construct a solution and expose it to QML (easily done)

Aside from those issues my only other frustration comes from not knowing native SDKs and App store innards. Launch screens on iOS are a terrible mess (Apple's fault) Their app submission web UI is terrible. XCode is an IDE unlike any other I've used. Android isn't as bad but has similar quirks. Qt empowers you to write an app for both stores, but you'll get some frustration with the learning curve. You must use XCode to upload the app, and those instructions are out of date in Qt's documentation. The only trick for Android is knowing how to sign the release build.


More information about the Interest mailing list