この記事は The Qt Blog の What’s New in Qt on Apple Platforms を翻訳したものです。
執筆: Jake Petroules, 2017年1月30日
※注: この記事内で使われる「アップルプラットフォーム」はアップル社が現在提供している４つのすべての OS (macOS, iOS, tvOS, watchOS) を指しています。
今回私は Qt 5.8 リリースにおけるアップルプラットフォームについて紹介したいと思います。
新しいプラットフォーム
まず初めに、Qt は 5.8 で Apple TV と Apple Watch の技術プレビューレベルの対応をいたしました。これによりすべてのアップルプラットフォーム (macOS, iOS, tvOS, watchOS) に対応することになります。
tvOS (Apple TV)
Qt の tvOS 対応の 95% は iOS と同じで、対応している機能やモジュールについても、QtWebEngine 以外は iOS と同じ状況になっています。
これらの二つのプラットフォームにおいて、一番の違いは入力デバイスの制御です。iOS はタッチでの動作が基本で、これは昔ながらのデスクトップ環境でのマウスのクリックとプログラミング的には一緒です。tvOS はフォーカスをベースにした仕組みが取り入れられています。これにより、(x, y) のような２次元座標的に入力を受けとるのではなく、フォーカス状態に応じてイベントを受け取ることができるようになっています。あるオブジェクトにフォーカスが当たっている場合には Apple TV Remote のトラックパッド操作やメニュー、再生、一時停止などのボタンに応じたアクションを実装する事が可能になります。
Qt は (スクロールやクリックを認識する) tvOS の入力システムをある程度はサポートしていますが、tvOS のアプリ向けの QML で入力をハンドリングするにはいくつかの手作業が必要になります。Apple TV Remote のほとんどの基本的なナビアクションは Qt のキーボードイベントとして利用可能で、より複雑なマルチタッチもジェスチャーとしてハンドリング可能です。今後導入予定の新しい入力処理機能ではさらに簡単にこれらを扱うことができるようになる予定です。
Qt の tvOS をリードしてくれた Mike Krus に多大な感謝を述べるとともに、彼がこのプラットフォームのメンテナであることをここに記します。
watchOS (Apple Watch)
watchOS 向けの Qt も iOS のコードを最大限利用しています。しかし、Apple Watch では基本的な API が (UIKit ではなく) WatchKit なため、QML を動かしたりその他の Qt の GUI を表示することはできません。このため、現時点では UI 以外の部分（ネットワークやオーディオ、UI 以外でのグラフィックスの処理）などでのみ Qt を利用可能です。将来的に watchOS の API が変更になった場合には、GUI の部分も利用できるようにする予定です。
私は watchOS のメンテナもしているので、質問やフィードバックは私の方までお願いします。
iOS での共有ライブラリ
多くの iOS 開発者の方はご存知のとおり、iOS ではこれまで静的ライブラリのみが許可されていました。Apple の App Store requirements では、OS レベルでは 1.0 からサポートされている共有ライブラリは禁止されていました。しかし、2014 年に登場した iOS 8 と Xcode 6 にて共有ライブラリ／フレームワークの App Store に提出するアプリケーションでの利用が Apple によって正式にサポートされました。残念ながら Qt 5.8 には間に合いませんでしたが… Qt 5.9 では正式にサポートする予定です。
iOS 向けに Qt を共有ライブラリとしてビルドするのは簡単で、configure のオプションに -shared を追加するだけです（これは Qt 5. 9 ではデフォルトになります）。共有ライブラリの利用は iOS 8.0 以降が対象になるため、Qt 5.9 の iOS 対応も 8.0 以降が対象になります。
共有ライブラリが利用可能になったことで、これまで iOS 向けは静的ライブラリ、その他のプラットフォームでは共有ライブラリを使用するようにしていたコードが共通化できます。また、以下のメリットがあります。
- App Extensions を使う際に（メインのアプリケーションとエクステンション側が共通の Qt の共有ライブラリにリンクできるため）、メモリの消費量とエンドユーザーのデバイスのディスクの消費量を削減することができます。
- 厳密な API の境界と名前空間により、コードのメンテナンス性が向上します。
- リンクにかかる時間の短縮化とビルド時間の短縮が可能です。
これにより自然とこの疑問が生まれます。共有ライブラリは LGPL ユーザーには影響がないと思っています。Apple の App Store（のDRM) をどうするかとういう問題はありますが、前述のような技術的な観点から共有ライブラリの利用を推奨します。そしていつも通り、ソフトウェアのライセンスに関しては法務の専門家の助言にしたがいましょう。
ビルドシステムの機能追加
最近のいくつかの Qt のリリースにおいて、アップルプラットフォーム向けのビルドシステムの機能の追加を行ってきました。
- Qt ライブラリのインストール用に @rpath を使用し、ライブラリの移動を可能に (Qt 5.5)
- .dSYM デバッグシンボルの分離 (Qt 5.6.1, Qt 5.6.2)
- アセットカタログの生成 (Qt 5.6.3 & Qt 5.7.1)
- App Thinning に記載のある Bitcode に対応 (Qt 5.8)
- iOS や tvOS、watchOS でヘッダのプレコンパイルを利用することでビルド時間が最大30％短縮 (Qt 5.8)
- シミュレーターとデバイスのビルドを統合し、iOS での _simulator が名前に含まれるライブラリを撤廃 (Qt 5.8)
- macOS でのマルチアーキテクチャ(universal)を Qt 4.x 以来対応 (Qt 5.9)
- qmake で生成した Xcode のプロジェクトにおいて Qt のフレームワークを自動で Qt のアプリケーションにバンドル(Qt 5.9)
- そして数え切れないほどのバグの修正
最後ですが、”Max OS X” と “OS X” という名称をすべて “macOS” にする対応を継続中です。
