Using Qt for Mobile in 2023

Having used Qt for the past few years in a cross-platform app, I’ve come across more and more issues that keep piling up on mobile, to the point I’m beginning to think that Qt is not the best choice in 2023. While Qt is still quite good for desktop development, there are several areas it is lacking in mobile dev.

The goal of this post is to highlight these areas for both developers evaluating Qt, and for The Qt Company to understand developer pain points.

Touch Interaction / UI Performance#

Qt handles all rendering of the UI in its own stack, and doesn’t use native components like some other cross-platform frameworks (i.e React Native). This leads to touch interaction feeling noticeably worse than a native or React Native app. For example, the ListView in QML, Qt’s UI markup language, doesn’t support inertial scrolling.

In the above videos, notice how the quick scrolls in Qt’s ListView barely move the view. In React Native, these big and quick swipes move the view considerably, and have an inertia that feels good.

The lack of inertial scrolling comes up in other components, like the SwipeView and Drawer. QML does provide a more generic MouseArea that you could use to try to design this yourself, but unfortunately the result is unlikely to be performant enough to use, due to everything going through Qt’s custom touch stack. The custom touch stack also makes buttons and other interactions feel laggy.

Filesystem#

On desktop, Qt’s file APIs work quite well. On Android or iOS, they are more trouble than they’re worth. With Android’s Scoped storage updates in Android 11, an app can’t access user files without opening a native dialog for them to select them. Once the user selects them, an app gets a content URI that it can read through. Qt’s filesystem APIs don’t account for any of this. This can be seen in Qt’s File System Explorer example which is currently broken.

As a workaround, KDAB has released a sharedstorage library that works nicely.

On iOS, you can try the FileDialog QML type, but it doesn’t work for photos, even if you specify i.e folder: StandardPaths: PicturesLocation.

Text Interaction#

Keyboard Issues#

If your app uses any text input, you’ll probably have to write a lot of code to open and close the keyboard properly and work around other Qt bugs. There are also many issues dealing with autocorrect and predictive text on certain keyboards, i.e Gboard on Android (QTBUG-120238). On iOS, the keyboard sometimes stays open and cannot be closed with Qt’s Qt.inputMethod.hide() method (QTBUG-119601).

Unfortunately, there are many other similar issues, some of which have been open for years, and as Android and iOS get software updates, you can always find keyboard interaction to be broken in some way.

Text Handles, Copy/Paste/Select#

These need to be implemented yourself. This is more difficult than it seems, due to the many edge cases, and the difficulty in getting it to feel smooth or native. In fact, this is currently broken in Qt’s texteditor example.

Permissions#

Qt is currently working on its Permissions API, but it is still a work in progress and only contains support for 6 permissions on Android.

Multimedia#

This module was completely rewritten in Qt 6. Unfortunately, Blueooth input does not work on Android or iOS. On Android, I was unable to get any Bluetooth input using Qt’s audiosource example. On iOS, the Bluetooth device is not even recognized.

Developer Experience#

It has gotten better in the past couple of years, but the developer experience of Qt on mobile is still lacking in my opinion. When using Qt, it’s recommended to use Qt Creator for development/deployment. However, Qt Creator’s Android debugging is flakey at best, and iOS debugging through Qt Creator is currently non-existent for iOS 17 devices (iOS 17 was released ~3 months ago at time of writing).

Aside from debugging, there is an awful lot of discovery work needed to achieve behavior that is included by default in native apps, leading one to question if it’s all really worth it. The Qt community is also small compared to i.e React Native, so there may be no answers online on how to do X with Qt.

Conclusion#

I think that Qt needs to invest more in its mobile APIs and performance. While the framework may fit certain use cases, the performance of the UI (touch interactions, text interactions, loading, etc) make it impossible to make an app with great UX. The lack of mobile APIs can be difficult, but native integration is always necessary to some extent.

On the other hand, Qt may make sense for some teams which already have a large Qt codebase on desktop. While a separate mobile UI would be needed, being able to reuse large portions of existing code could outweigh the UX issues mentioned above. In any case, I look forward to seeing how Qt evolves, and continue to enjoy using it on desktop.

Other options?#

Being able to share UI and code on Android and iOS is still a desire for many developers. As hinted throughout the post, I think React Native may be the only other possible contender. Flutter may also be an option, but I’m skeptical of their choice to handle all rendering and touch interaction themselves.

Like React Native, Flutter uses reactive-style views. However, while RN transpiles to native widgets, Flutter compiles all the way to native code. Flutter controls each pixel on the screen, which avoids performance problems caused by the need for a JavaScript bridge.

- Flutter for React Native developers

I haven’t had time to try RN or Flutter in a serious way yet, but I’m looking forward to doing so in the future.