That’s a long post about what could be the ways for making a native looking and feeling, and behaving Qt app for iOS and Android, so here’s a table of contents:
- Qt and mobile apps
- What’s needed for app to be native-enough
- What’s possible for making the native-enough app
- Experiments to perform
- Your opinion
Coming from strong Nokia background I like Qt and mobiles. I used to be a Forum Nokia Champion, Qt Ambassador, created a number of Qt/QML apps for Nokia N9 and Symbian, possibly created the first ever 3rd party app available from MeeGo, Symbian and Android app stores and built from the same source code. Nowadays I am spitting out Jolla Sailfish apps (including the app more popular than the system Clock app) with the machine gun speed just because I love to see power of Qt and QML come to action on the fully-Qt device.
I am also a UI standards maniac (not necessarily a succeeding one) and it drives me crazy that I cannot use my favorite Qt and QML for building mobile apps for mass market (read: Android and iOS), now that it is technically possible, but in practice only low level graphics examples exist and nobody seems to care much about native or native-looking toolbars, gestures, sharing dialogs, integrating to notification services, you name it.
Right now I am flying for a New York reunion of my day job company (BTW, have a look at pretty cool interactive images service we make, sure we have mobile apps for creating these on the go too) and drafting this post for outlining a set of experiments to proof or decline the ability to create native-looking iOS and Android apps already today or tomorrow. I will probably try implementing a couple of these and some will be beyond my skills. So if you are into the same stuff, grab a topic, do an example on github and post it to comments, I’ll add it to the post.
So what’s needed for an app to be native enough. Two things: native look&feel and integration to the system services.
Buttons, toolbars, gestures (e.g. iOS 7 Back gesture), native text input, view transitions, theming according to the current device theming. Sure it’s better for these to be fully native, but looking at what modern mobile HTML5 app frameworks are able to achieve, I think it’s okay at least for now if your app will look almost native. For example, if you implement view transitions yourself so that they look almost native and make buttons that look like the default phone theme only, I won’t be ashamed for shipping such an app to app store. As a rule of thumb: if you would feel okay showing the next Instagram-Twitter-Foursquare app done this way to potential investors, I’d say UI is looking native enough.
There are non-visual or partially non-visual services that user got to expect from the native apps nowadays (and not immediately supported by Qt). Two prime examples are system sharing sheets and system accounts integration (logging in/signing up with Facebook, Twitter, Google+). As the secondary examples I would add being on the receiving side of the sharing interaction and working in the background when started by the system notifications service or just because your app is registered for the background execution. Sure you could add many more examples, but if the ones above are covered, everything else should be doable to and you will probably be able to modify the existing proof-of-concept demos for it.
There is a number of approaches available:
You get a rectangle and you draw there whatever you like. That is the way the current most cool mobile Qt demos are made, performance seems to be good enough for cool effects and fast animation on all the relatively modern devices. That could be a good approach for creating a cross-platform mobile game nowadays where you anyway are likely to have non-system looking controls and not much system interaction.. except for in-app purchases.
- Pros: You can use power of the full Qt and QML, manipulate your C++ objects and QML and create whichever effects you want easily
- Cons: If you are not creating just a demo game, cloning system toolbars and view transitions could be a daunting and boring task. Possibly an easy one, possibly a complex one
That is the primary way forward for Qt for Android. There is an effort led by Bogdan Vatra for making existing Qt Quick controls look real native and even fetching colors and font sizes from the system theme. The problem is that most of these goodies are [probably] coming in the end of 2014 the earliest and are for Android only anyway. Meanwhile you can grab the current, quite desktop-looking controls and with a bit of hammer and swearing make them look good enough for you. There is even a couple of open source projects aimed at it.
- Pros: Full Qt/QML power is still here, you will definitely find at least PageStack and Page elements useful, possibly some controls won’t look that bad.
- Cons: You won’t get theming for free, possibly making even semi-okay looking controls will be difficult, native looking transitions and gestures will also be on you
Qt 5.2 SDK already includes an HTML5 app template and, well, it is pretty much just a Webkit view with HTML inside, so you can use some modern mobile app frameworks for the native-looking buttons and toolbars. Advantage you get from using these frameworks in the HTML only mode is [potentially] easy integration to the C++ side on your code. I think you could access C++ side objects injected to HTML or made accessible by it (e.g. Settings or file system or your proven network comms engine). And/or you can go the other way around and modify web page DOM elements from C++.
- Pros: Native-enough look nearly for free. You can still use your Qt libraries and shift much of the complexity to the Qt side
- Cons: No QML, Qt-HTML integrations could be difficult and unusual (e.g. could signals and slots be used anyhow?), no good debugging and profiling tools
A variation of the above for the apps centered around large main controls such as lists, map of the local restaurants or a painting board. It is likely to be possible to paint these using Qt/QML though performance and ease of debugging of such an option are to be studied yet. Controling lifetime of such objects could also be tough.
- Pros: You get native enough-looking controls nearly for free while using Qt/QML exactly where it matters most and where you want to polish the UI.
That is sort of a reverse approach. You can have a QML app that devotes 100% of it’s space to a web view or you can even have a non-visual QML component running side by side with the web view instantiated the C++ way. Then you can paint 100% of UI using HTML5 UI frameworks while having app logic in QML. If you go one step further, you can even create a whole presentation layer in QML that just maps itself into as lightweight as possible HTML5 UI.
- Pros: Native enough-looking controls from HTML5, all the logic in Qt/QML, property bindings included
- Cons: It could be tough to establish one-two one mapping between QML and HTML5 when reading and writing data
I.e. main UI list done in QML injected into web view created by a QML app. Just because we can 🙂
I am far from being sure it is easy to do, but if it happens to be easy, you could get the best of both worlds: controls and view interaction only from HTML5 frameworks, power of QML logic and graphics for everything else.
- Pros: HTML5 only where it’s really needed (just for native looking controls/transitions) and nothing else. Everything else in Qt/QML
- Cons: Could be too tough to do that many levels of injection
QML is not the only Qt way for contracting UI. You can still use a form designer for getting a QtWidgets app and manipulate the generated form from C++ (technically from QML too though you are not likely to do it).
Nowadays both Android and iOS have a way to define UI declaratively and certainly you can use native code for adding more controls. Well, you could define such layouts in the native tools and then instantiate and manipulate them from Qt/QML, possibly even painting a couple of particular controls yourself.
- Pros: Native look and feel, no compromises whosoever!
- Cons: Quite platform-specific way for integration, injecting your own controls inside can be tough
That is the area I am not really familiar with unfortunately so can’t outline many approaches. I only know that it should be possible to communicate with the Android side via JNI and some way for accessing iOS APIs should also be possible. How easy or hard it is and whether you will be able to use e.g. platform-specific Facebook SDK for logging people in is to be studied.
So here is a list of proof of concept demos I think are needed for validating the approaches outlined. Once I implement some of them or figure out an existing demo about the same, I’ll add the links to here. Demo projects could about whatever topic, I guess a basic Flickr browser could make a good reference app.
- Looks and feel
- Plain QML or plain QML + just PageStack from Quick controls. Just make them look native(ish)
- QtQuick controls styles to look like iOS/Android
- QtQuick controls styles to look like iOS/Android
- HTML5 (with some mobile UI framework) + interaction with the Qt objects
- HTML5 with some area inside painted by Qt/QML, ideally a couple of different controls in a couple of different pages
- HTML5 inside QML app and manipulated from QML
- And QML inside HTML5 inside QML
- Native iOS layout(s) manipulated from Qt
- Native Android layout(s) manipulated from Qt
- System integration
- Logging in with the system integrated Facebook/Twitter/Google+ (probably many different platform-specific projects)
- Passing link/photo to Android sharing framework
- Passing link/photo to iOS sharing framework
- Receiving link/photo on Android from sharing on Android
- Receiving link/photo on iOS. Okay, that’s not very important as I think on iOS the sharing source has to exactly know your app for sharing to you
- Sharing link/photo using exactly Facebook/Twitter/G+ SDKs for fully optimized native look
- Waking up on system notifications
- Waking up on geofencing event or something like that
- Just running in the background sometimes
What do you think? I created this list first of all for my own understanding. I am likely to actually try a couple of approaches, but will probably stop once I figure a good enough solution for some real app to make or if I give up due to the complexity. Then this proof-of-concept catalog could continue only if there’s an active interest from somebody to make consumer grade Qt apps a reality on iOS and Android.
Does this list of approaches make any sense to you?
Do you know of some existing projects already trying these? Is something important missing?
Do you think the whole goal of making cool looking Qt apps for iOS and Android is worth studying at all while there are good 100% native platform-specific tools already and even HTML5 for those into the cross-platform UI dream?