What's New in Qt on Apple Platforms

Note that throughout this blog post, the term "Apple Platforms" will be used to refer to all four Apple operating systems (macOS, iOS, tvOS, and watchOS) as a whole.

I thought it would be a good time to share some of the highlights of what's new in Qt on Apple Platforms with the recent release of Qt 5.8.

New Platforms

To start off, Qt now has Technology Preview level support for Apple TV and Apple Watch devices beginning in Qt 5.8. This completes our offering to support all four Apple Platforms - macOS, iOS, tvOS, and watchOS.

tvOS (Apple TV)

Qt for tvOS is 95% similar to iOS (even the UI framework is also UIKit) and as a result, contains roughly the same feature set and supported modules as iOS, with the notable exception of QtWebEngine.

The major difference between the two platforms is input handling. iOS has a touch-based model that maps fairly well to a traditional point and click desktop interface from a programming perspective, while tvOS has a focus based model. This means that you don't have a canvas which can receive input at a particular point (x,y coordinate), but rather an abstract canvas in which you "move" the focus to a particular object. When an object has focus, you can use the Apple TV Remote to trigger an action by clicking its trackpad or pressing the Menu or Play/Pause buttons.

Qt supports some aspects of the tvOS input model (scrolling and clicking are recognized), but there will be some degree of manual work handling input events in QML to build a tvOS app. Most basic navigation actions on the Apple TV Remote are exposed as keyboard events in Qt, and gesture recognizers can be used for more complex multitouch input. We are still exploring ways to provide mechanisms that make it easier to work with this new input model.

We'd also like to thank Mike Krus doing the initial work of porting Qt to tvOS, and who is now the platform's maintainer.

watchOS (Apple Watch)

Qt for watchOS is also heavily based on iOS. However, it is not possible to run QML or any other Qt based UI on the watch using public APIs because the primary interface API is WatchKit (as opposed to UIKit). Therefore, Qt can currently only be used for non-UI tasks such as networking, audio, backend graphics processing, etc. If the available watchOS APIs change in the future then we can certainly explore the possibilities at that point.

I am also the watchOS platform maintainer, so please feel free to send me any questions or feedback.

Shared Libraries on iOS

Only static libraries were permitted for most of iOS's existence, as many iOS developers are no doubt aware. Apple's App Store requirements prohibited shared libraries even though the underlying operating system supported them since 1.0. Finally, with the release of iOS 8 and Xcode 6 in 2014, shared libraries/frameworks became officially supported by Apple for use in applications submitted to the App Store. Unfortunately, while this feature did not make it in time for the Qt 5.8 release... Qt 5.9 will support them too (also for tvOS and watchOS)!

To build Qt as shared libraries on iOS, all you need to do is pass the -shared option to configure (and this will be the default in the next release). Note that shared libraries require a deployment target of at least iOS 8.0, which will also be the minimum requirement for Qt 5.9.

With shared libraries, you can simplify your development workflow by not having to maintain separate code paths for static libraries on iOS and shared libraries on other platforms. Shared libraries also allow you to:

• When using App Extensions (as both your main application and your extension executables may link to the same copy of the Qt frameworks), reduce memory consumption and reduce disk space consumption on your users' devices as your app will be smaller
• Make your code base easier to maintain through strict API boundaries and the benefits of namespacing
• Speed up linking and thus overall build time

Because the question will inevitably come up: we do not believe shared libraries will have any practical effect for LGPL users. There are other concerns that come into play with the Apple App Store (namely, DRM) which render the point moot. However, we recommend using shared libraries for the technical reasons outlined above. And as always, seek professional legal advice with regard to software licensing matters.

Build System Enhancements

In the past several Qt releases we have also made a number of significant enhancements to the build system on Apple Platforms, including:

• @rpath in the install names of Qt libraries, providing relocatability out of the box (Qt 5.5)
• Standalone .dSYM debug symbols (Qt 5.6.1, Qt 5.6.2)
• Building asset catalogs (Qt 5.6.3 & Qt 5.7.1)
• Bitcode on iOS which allows Qt applications to take advantage of App Thinning (Qt 5.8)
• Precompiled headers on iOS, tvOS, and watchOS, reducing build time by up to 30% (Qt 5.8)
• Combined simulator and device builds, doing away with the confusing separate _simulator libraries on iOS (Qt 5.8)
• Multi-arch ("universal") builds on macOS, back from Qt 4.x (coming in Qt 5.9)
• Automatically embedding Qt frameworks within a Qt app bundle in qmake-generated Xcode projects (coming in Qt 5.9)
• ...and many other smaller bug fixes

One more thing... we've been changing every reference to "Mac OS X" and "OS X" that we can find into "macOS". :)