昨年から社内名でマジパン プロジェクトとして知られていましたが、ついに最終的な名前がわかり、私たちの中にも加わりました。 iOS (より具体的には iPad) から直接 Mac アプリを作成する可能性。これにより、デスクトップにはない基本的な機能(たとえば、 Twitter スタイルの一部のインターネット サービス)、また、 iOS プラットフォームを使用し、ほぼ同じ労力で macOS エコシステムにフィードを提供できる膨大な数の開発者を利用します。
しかし、 Project Catalyst とは一体何なのでしょうか? Mac 上で iOS アプリをエミュレートする仮想マシンを検討しているのでしょうか?リアルタイム翻訳？ iOS ライブラリからの呼び出しを Mac の呼び出しに変換する何らかの形式の適応?この記事では、これらすべての質問に答えていきます。
Project Catalystの中核
Federico Viticci (MacStories の責任者) とソフトウェア エンジニアリング担当上級副社長の Craig Federighi による AppStories ポッドキャストのインタビューの中で、彼は、Apple チームが自分の仕事の中で、非常に役立つ iOS 用アプリがあることにどのように気づいたかについてコメントしました。しかし、驚くべきことに彼らは Mac 向けではなく、ワークフローを簡単に完了することができませんでした。あるいは、非ネイティブのサードパーティ ライブラリを使用した低品質のバージョンを使用する場合もあります。
Mac アプリと iOS アプリは、インターフェースの構築にまったく異なるライブラリを使用します。ただし、どちらも Core Graphics の上のレイヤーであり、Quartz エンジンの抽象化であり、要素の描画を担当します。インターフェイスにボタンを配置するように要求すると、システムには、ボタンを描画する命令 (行ごと、点ごと、色ごとなど) を認識するクラスがあり、これらは Core Graphics に渡され、クォーツ描画エンジン、どのピクセルを、どこに、どの色でペイントするか。 Core Graphics の下には言語基盤ライブラリ、次にシステム ライブラリ自体、そしてシステム コア全体の下に Darwin があります。
Quartz エンジン、Core Graphics、およびその他の要素は、iOS と macOS の両方で同じフレームワークです。初代 iPhone がリリースされた 2007 年以来、ずっとそうされてきました。問題は、2007 年以来、同じライブラリの 2 つの異なるバージョンのように、それぞれが独自の方法で進化していることです。さらに、AppKit は独自の方法で「その内容」を要求し、UIKit も同じことを行いました。
Apple が行ったことは、まず、 UIKit と AppKit の下にあるすべてのフレームワークを、すべてのシステムに対応する 1 つのフレームワークとして統合することです。そして、UIKit を AppKit に変換する代わりに、前述の共通レイヤーを使用して UIKit の命令とクラスを取得し、それらを使用して Mac 上で UIKit 要素を描画します。ただし、UIKit 要素を iOS ではなく Mac スタイルで「ペイント」するように求められます。そのため、私たち開発者はほとんど労力を費やすことなく変更を取得でき、システムのパフォーマンスは少しも低下しません。
このようにして、翻訳も仮想化も行わないため、完全な実装が実現されます。単純に、UIKit は、オブジェクトをシステムのグラフィックス エンジンに直接変換する、macOS 上のそれ自体のネイティブフレームワークになります。そして、システムのグラフィックス エンジン、プログラミング基盤、システム ライブラリ、コア、さらには写真、連絡先、好みのデータベースに加えて、クリップボード サービスやファイルなどもすべて、iOS 用の同じ単一バージョンに統合されています。 Mac の場合はとてもシンプルで効果的です。
実際、Apple は今後も AppKit を進化させていくつもりであり、AppKit を放棄するつもりはなく、誰もが UIKit に切り替えるつもりもありません。システム内には 2 つのライブラリが共存し、 2 つの作業方法と、アプリの作成方法を選択する 2 つの方法が存在します。実際、Mac 上の新しい宣言型インターフェイス作成フレームワークである SwiftUI は、AppKit (UIKit ではなく) に基づいて構築されており、この新しいライブラリがインターフェイスを描画できることを保証するために AppKit を抽象化したものになります。
ソフトウェアに基づくシステムの統合
理解しておくべき重要なことは、Project Catalyst は単に Mac 上で UIKit を動作させることだけではないということです。Appleは、両方のシステム間で共通のコード ベースを実現することを目的として、Mac 用の 40 のシステム ライブラリ (両バージョン間) を渡したり統合したりしました。 iOS の ARM アーキテクチャと macOS の x86 の両方。そしてはい、あなたが考えていることはわかります。ARM を搭載した Mac ですか?はい、このステップはその瞬間にとって重要です。
Apple 側のこの取り組みは非常に明確であるため、Project Catalyst で作成されたアプリは、何も変更することなく、Mac 上に既に存在するものと同じビジネスおよび配布モデルを使用できるようになります。 Catalyst で作成したアプリを Mac App Store にアップロードすることは必須ではありません。この外部で配布したり、弊社 Web サイトに掲載したりして、Apple に一切依存せずに独自のビジネス モデルを構築する可能性があります。唯一の条件は (他のアプリでも同様に) 公証を受ける必要があることです。
Apple が私たちに伝えているのは、まず私たちの iPadOS アプリが Mac 上で意味があるかどうかを考えるということであり、Mac 上で非ネイティブのサードパーティ テクノロジを使用するアプリがある場合は、Project Catalyst について考えるように勧められています。名前は言いませんでしたが、それはそうです。もちろん、彼らはエレクトロンについて話しています。これについては、少し前にここで話しました） 。このことから、Spotify や Slack など、現在このライブラリを使用している多くのアプリが、iPad アプリを搭載することで Project Catalyst を使い始めるのではないかと考えられます。これにより、リソースの使用量が少なくなり、より最適な操作が可能になります。
考慮事項
ただし、調整されていない、または組み込まれていないライブラリがあるため、アプリでそれらを使用している場合、iPad アプリの Mac バージョンを作成する場合は、それらを削除する必要があります。たとえば、 ClassKit 、 HealthKit 、 ARKit 、またはHomeKitは、Mac には同等の機能がない特定の機能に特化した iOS ライブラリであり、最初は教育アプリ用 ( ここで説明します)、健康アプリ用のHealthKit 、拡張現実用のARKit (意味がありません)。デスクトップ上）とHomeKitですが、Mac にはライブラリとして同等のものはまだありません。これらに、CarPlay やドキュメントをスキャンするための新しい VisionKit などの他のロジックが追加されています。
変換には考慮すべき他の要素があります。すでにバイナリ ( .framework ) にコンパイルされているサードパーティ ライブラリを使用する場合、Xcode 11 で Mac 用にコンパイルされた特定のバージョンがなければそれを使用できません。そのため、次のようなライブラリを使用する必要があります。 Firebase は新しいバージョンを待つ必要があるため、一時的に削除する必要があります。
また、各プラットフォームがどのように動作するかにも留意する必要があります。位置ライブラリ (Core Location) は iPad アプリから Mac 上で動作しますが、Mac には GPS が搭載されておらず、移動するように作られていないため、位置精度だけでなく機能も制限されています。
デバイスの動きを使用して何らかの要素を制御するゲームやアプリがある場合は、別の方法を見つける必要があります。タッチ コントロールを使用するゲームがある場合は、両方のシステムでキーボードまたは対応するゲーム コントローラによるサポートを提供する必要があります。
同様に、通話ライブラリ、NFC または Bluetooth にも、両方のシステムの機能が異なるため、明らかな違いがあります。または、WebKit を使用して iOS 上で Web ブラウザ ウィンドウを表示するような基本的なことは、Mac では意味がありません。Mac では Safari (またはデフォルトのブラウザ) を開くリンクに変更する必要があります。メディア プレーヤーでも同様です。再生中のビデオは含まれないため、コンテンツを再生する別の方法を見つける必要があります。
システム間で異なるコードや部分について話す場合は、 @available修飾子を使用するか、 UIKitforMacと呼ばれる新しいシステムで#ifコンパイル条件を使用する必要があります。これにより、実行時に特定の機能を追加できるようになります。または、Mac 上で動作しない環境がビルドに含まれないようにします。
拡張機能を使用すると、アクション、オーディオ ユニット、通知サービス、コンテンツ共有、スポットライト、またはネットワーク拡張機能が利用可能になりますが、iMessage 拡張機能、Quicklook プレビュー、サービス プロバイダー ファイル、Siri インテンションなどの特定の iPad 機能は利用できなくなります。インテンションインターフェイス、写真編集、ステッカーパック、パスワード自動入力、カスタムキーボード、今日セクションのウィジェット、またはコンテンツブロッカー。これらは両方のシステム間で非常に異なる関数であり、Mac アプリはそれらをコンパイルに含めないため、明らかに意味がありません。
すべてが仕事というわけではありません。無料のものもあります
アプリを Mac に適合させ、システム間の通常の違いを明確にすると、 Apple は開発者側で何も作業しなくても、一連の追加の利点を提供してくれます。このアプリには、調整なしでアプリのデフォルト メニューと、自由にサイズ変更できるウィンドウ管理が含まれます。設計内で制約を適切に配置すると、インターフェイスはリアルタイムで自動的に適応します。デフォルトでフルスクリーン機能が含まれており、他には何もせずに別のモニターやサイドカーに送信することもできます (Mac 上の iPad アプリを iPad に送信します…ほとんど時空のパラドックスです)。自動ダークモードもサポートされる予定です。
もう 1 つの大きな変革は、iOS アプリでシステム設定にアプリの設定を追加したことです。 Mac での作業方法は異なり、通常、環境設定はアプリの専用メニュー (名前が付いているメニュー) にあります。 iOS にいくつかのオプションがある場合、Project Catalyst はそれらを引き継ぎ、Mac 上に独自の環境設定オプションを作成します。また、ダイナミック テキスト タイプのサポートにより、Mac でタイポグラフィを自動的に再スケールすることにより、フォント サイズの違い (iOS では 17 ポイント、Mac では 13 ポイント) にも対応します。
ナビゲーションに関しては、Apple は iPad アプリのタッチ モードでの作業方法をマウスで使用するように変更し、その解釈方法を変えました。通常、iPad 上でボードをタップしたり、押したりすると、ボードが動きます。でも画面に触れないといけないんです。 Mac では、マウスまたはトラックパッドのスクロール ジェスチャがスクロール動作として自動的に変換されるようにするには、カーソルを (押さずに) テーブル上に置くだけで十分です。これは水平方向または垂直方向の動きでも同様に機能します。また、システムによって使用されるテキスト フィールドまたは要素の Touch Bar の標準機能も自動的に適応されます。
さらに、 UIKitforMac使用する場合にのみ含まれるコントロールを配置したり、操作に関連付けられたアプリに特定のメニューを配置したり、 Mac で動作しないものやユーザーに混乱を引き起こす可能性のあるものを適応させる作業が必要になります。欲しい結論として、それが機能するように形状と外観を調整します。
今後の記事では、私自身が iOS 用の完成したアプリ (マジパンで既にテストしたものと同じ) を Mac で動作するようにどのように変換したか、またどのような変換や考慮事項を行ったかを段階的に説明する予定です。従うこと。