iPad Apps for Macの紹介

(音楽)

(拍手) ありがとう (拍手) 皆さんにお会いできて光栄です 私はアリ･オザーです 同僚のジェイクとジェイソンと共に iPad AppをMac向けにする方法をお話しします ２つのセッションのうち 今回は基本的な内容についてです このテクノロジーについてや 導入方法の他に 何が変更無しで得られるのか また注意すべき 重要なAPIの違いもお話しします 今週 開かれるもう１つの セッションでは次の段階に進みます そこで取り上げるのは より高度な内容です 既存のAppをより良いMac Appにする方法や 配信のための検討事項についてです

iPad Appを Mac向けにするとは iPad Appを再構築し Mac上で ネイティブに動作できるようにする技術です 詳しく見ていきましょう Macは安定したプラットフォームで あらゆる種類のAppの開発に 適しています パワフルな デスクトップAppや Webベースのエクスペリエンスや グラフィック満載のゲームなどがあり そしてこれら全てのエクスペリエンスをサポートする 専用のフレームワークが存在します ここで忘れてはならないのは UIKitです 現在iOS Appで 使用されている技術です

Macの各フレームワークの ネイティブピアであるUIKitを使って iPad Appを 最上級のエクスペリエンスとして Macへ持っていくことが可能になります では その方法をご説明しましょう

私たちには多くの テクノロジースタックがあり iOSとmacOSで シェアされています そしてそれを最大限活用します またMacに存在しない iOSフレームワークを― Mac上で正しく動作するように 統合します Macの基本構造やUIデザイン ガイドラインに沿いながらです 最後に、重要なのは この作業を簡単に始められるようにしたことです 最初の２点について私が説明し 3点目についてはジェイクがお話しします

ではテクノロジースタックがどんなものかを お見せします こちらがMacのテクノロジースタックです macOS Appがあります これらはフレームワーク上に構築され UIフレームワークと下位レベルの フレームワークも確認できます これらは一例で 実際は何百もの フレームワークが存在します それに加えてデータベースもあります これらは例えばユーザの写真や連絡先　　　　　　　　　　　 環境設定などです またサービスもあります コピー＆ペーストのクリップボードやファイル コーディネーションなどが含まれます これらすべてのサービスの根底がKernelで 私たちのDarwin Kernelです iOSのスタックも 非常によく似た構造です Appと フレームワークのスタックがあり その下にデータベースとサービスが 存在します ここで見られる相違点については すぐにお話しします

さて、シミュレータを使ってMac上で iOS Appを 動かせることはあまり知られていません シミュレータは、自身のある環境で動作する そのスタックの別個のコピーを有しています ですので、フレームワークやデータベースサービスの 特有のコピーを持っています シミュレータの目的はiOS環境を 複製することであり iOS Appのデバッグや テストができます まるでiOS上で 行っているようにです シミュレータはそれを 見事に実現しています しかしMacユーザエクスペリエンスを うまく統合することが シミュレータの目的ではありません ユーザにとって最適な方法で 動作させることでもありません そこでiOS AppをMac上で ネイティブに動かせるように Macのフレームワークを 拡張しました AppKitとUIKitのAppの両方が 必要とするものをサポートするためです 両方に存在する下位レベルの フレームワークの機能を統合します Core Graphicsや FoundationやlibSystemです どちらのスタックからも利用できる コピーを作成するためです

表示されている図では フレームワークのUIKitとAppKitが １つに統合されていないことに ご注意ください この点について後ほどお話しします 隣にARKitがあることにも注意してください Macには拡張現実の機能が 存在しないため このフレームワークを持ってくることが できません 削除します ARKitは素晴らしい機能ですが まだMacには対応していません 最後にUserNotificationsが 真ん中にあります このフレームワークは Macに取り入れるだけでなく MacのパブリックAPIにもなった フレームワークの例の1つです 昨年このテクノロジーに取り組んでいた 初期の段階で 分かりやすい形で それを実現しました またサービスや データベースも統合しました それにより1つの写真や連絡先― 環境設定のコピーを AppKit AppとUIKit Appの両方から利用できます サービスでも コピー＆ペーストやファイル コーディネーションなどを統合しました iPad AppをMac向けにするための 環境はご覧のとおりです AppKit Appが 快適に ネイティブパフォーマンスの特性を使って 動作する環境とほとんど同じです 次に進む前に AppKitとUIKitの フレームワークについて話します WebKitやSceneKitだけでは あリません 他にも様々なフレームワークが 存在します ２つのコピーをお見せしましょう 確かにそうですよね AppKitとUIKitが 統合されていないため それらに依存しているフレームワークも 統合されません たとえWebKitやSceneKitなど 同じ名前の付いたフレームワーク でもです これには理由がいくつかあります 主な理由はNSViewや UIViewなどのクラスは別個の物で 独自の動きや 構造をしているからです そしてそれらに基いて構築された クラスの 宣言や実装も同様に異なっています 例えばMKMapViewが AppKitとUIKitそれぞれで 宣言されています ご覧の通り事実上 互換性のない定義です システムに これらのフレームワークの コピーが２つ存在します またSDKにもあります しかし心配する必要はありません スタティックリンカや ダイナミックローダが これらのフレームワークの 正しいコピーを正確に見つけ出します リンク中にビルドする時か ロード中に実行する時にです

では話を変えて なぜこれが必要なのかお話しします UIKitをMacへ取り入れる理由は？

理由の1つとして、 ここに表示しているのはごく一部ですが みなさんが作ったiPad Appが 無数に存在しており それらの多くをMacでも使えたら 素晴らしいと考えるからです 無数に存在するMacユーザは みなさんのAppによって 素敵になるでしょう このテクノロジーによって MacユーザにこれらのAppへの アクセスを提供し デベロッパにとって 新たな機会を創造します

このテクノロジーは自分の Appに適しているのか？ 素晴らしい疑問です

では、あなたがiPad Appだけを持っていて　　　　　　　　　 その機能を Macにも取り入れたいとしましょう このテクノロジーについて 考える良い機会です １つのケースとして iPad Appがあっても デスクトップにはAppが無く Webになることがあります それがどんなに素晴らしくても　　　　 Webインターフェイスはネイティブではありません ネイティブAppとは メニューバーやコマンドキー ハードウェア機能へのアクセス ローカルストレージなどを伴う より完全な エクスペリエンスです 別のケースとしてMac Appは 古いままで iPad Appは 追加の機能を持っていることがあります これらは同期していないのです これはMac Appを 更新する方法になり得ます その他のケースはMac Appの リプレイスです ネイティブでもなく最適化もされていないサードパーティの ポーティングフレームワークを使用しているものです iPad Appがネイティブであるなら Mac Appを モダナイズする良い方法になるかもしれません

しかし ここで１つ 重要なことがあります すでにMac上に AppKit Appがあって Mac版が十分メンテナンスされており 最新のiOS版に対応しているとします その場合このテクノロジーは不要で AppKitを使用し続けましょう AppKitは最上級のフレームワークで Mac Appの開発に必要な完全なAPIが揃ってます AppKitはこのテクノロジーが Mac上で提供するAPIセットよりも より完全なAPIセットへのアクセスを提供します

似たような形で、このテクノロジーを適用できない Appも存在します iPhone Appが一つの例です iPhone Appは小さな画面に 最適化されています そのため小さなスクリーンを 生かそうとします Macに持って行く前に 大きなスクリーンを活用する iPad Appを先に準備しましょう 他のケースとしてはモバイル機能を 組み込んだAppも該当します 先ほどご紹介したように ARKitも利用できません ARKitベースのAppは Macでは正常に動作しないでしょう しかし拡張現実の機能が 重要でないならば Appを取り入れたのち Mac上でその機能を削除すればよいでしょう

ではジェイクをステージに呼んで デモを行う前に このテクノロジーをデザインして提供することを 助けるハイレベルな目的についてお話しします

まず簡単に取りかかれることです これに関してはチェックボックスがあります 昨日もご覧いただきましたが この後もお見せします そしてシングルソースベースで 作業を行えること シングルソースベースであれば コードが分岐せず iPadとMac Appの バージョンを同時に進化させられます 自分のAppの中身が iPad Appだと思って欲しいのです それが今までiOS SDKで 開発してきたやり方です iOSのSDKやコンセプトに関しては これまで通りに考えて欲しいのです 最後にAppの外観をMac Appにのように見せます ユーザにとって最上級の Macエクスペリエンスになります

ではジェイクをステージに呼んで どうスタートするか話してもらいます (拍手) こんにちは 皆さん iPad AppをMac向けに することについて少し学びましたね ではその作業をXcodeを使用して 行ってみましょう これまでは全く異なった UIフレームワークを学び 新たなコードを 書く必要がありました しかしXcode 11を使えば 既存のプロジェクトやソースコードを 再利用できます 見ていきましょう

これは事前に用意しておいた レシピ管理のiPad Appです まずXcodeでプロジェクトを 開きましょう

Deployment Infoの下にある― Macのチェックボックスを チェックします これはAppがiPadを サポートしている場合のみ利用できます ではチェックボックスを チェックしましょう Xcodeでプロジェクトが変更される 旨のポップアップが表示されます Enableをクリックします

では何が起こったか 見ていきましょう まず気が付くのは スキームセレクタに実行先として My Macが表示されています これでMac向けAppのビルド、デバッグ テストが可能になります

バンドルIDフィールドの下に 新たなラベルがあります このテクノロジーを使って取り入れられた すべてのiPad AppとExtensionは 特別なプレフィックスを使用する　　　　　　　　　　　　　 新しいバンドルIDがデフォルトで与えられます

ハードコーディングされた参照 またはそのApp ExtensionのバンドルIDがある場合は それを考慮するために 一緒に変更する必要があるかもしれません 署名やプロビジョニングや 配信への影響については 次回のセッションで 学ぶことができます “Taking iPad Apps for Mac to the Next Level”です 次に機能について話します iOSではAppはInfo.plistに使用の 目的を文字列で指定する必要があります カメラやユーザーロケーションのような保護されたリソースに アクセスするためです Xcodeはこの情報を使って Mac Appに 同等のエンタイトルメントを自動的に追加します これでiOS上での動きと 同じような動作が得られます 例えばiOS Appは デフォルトで外部ネットワークへ 接続できますが 一方でMac Appでは エンタイトルメントが必要です Signing and Capabilitiesエディタで Xcodeが自動的に ネットワーククライアントエンタイトルメントや 他のエンタイトルメントを 追加しているのが分かります これはAppのInfo.plist内の 使用目的の文字列に基づいて行われます

次はフレームワークと App Extensionです ほとんどのiOSフレームワークは macOSでサポートされています しかし２つのSDKの間には 異なる点があります 私は主にXcodeの プロジェクト設定に注目します 続いてジェイソンが APIの違いについてお話しします ではXcodeがプロジェクトを 更新する時 自動的に利用不可のコンテンツを Macビルドから除外します これには利用不可のシステムの SDKフレームワークや 利用不可のApp Extensionタイプや Apple Watchコンテンツなどが含まれます General tabに戻って

Frameworks, Library and Embedded Contentセクションで Xcodeがすでにいくつかの依存性を 除外したことが確認できます ARKitとWatch Appは iOS向けのみビルドできるとマークされています

ではMac向けにビルドしてみましょう

エラーを確認すると 依存フレームワークの １つに互換性がないためとなっています iOSシミュレータ用に ビルドされていたためです iOSシミュレータと macOSフレームワークは x86向けに ビルドされています ならば これらをMac用 iPad Appで再利用できるか 答えはノーです プリコンパイルされた バイナリライブラリについては Mac用iPad App向けに コンパイルされたバージョンを ベンダーから 提供してもらう必要があります プロジェクトの一部としてソースから 構築されたフレームワークは デフォルトで自動的にMac向けに 設定されます

Frameworks, Library and Embedded Content セクションでは プラットフォームのドロップダウンを 使用して 互換性のあるバージョンが得られるまで Macのビルドから非互換のライブラリを除外します また機能がMac Appに適していない ライブラリも除外します しかし重要な機能がフレームワークに 強く依存している場合 Macに移植する前にベンダーからの 更新ライブラリを待つ方が賢明です

今回はベンダーから提供された 更新ライブラリがあります これをプロジェクトに追加しましょう まずは既存のフレームワークを 削除します

新しいフレームワークをドラッグします

お気づきのようにこれは 通常のフレームワークではありません この更新ライブラリはXCFramework としてデリバリされています これはXcode 11の新機能で ライブラリの開発者は複数のプラットフォームからの- ライブラリを１つの配信可能な バンドルへまとめることができます これをXcodeプロジェクトで 利用できます AppをMacに持って行くのに　　　 XCFrameworkは必ずしも必要ではありません しかし非常に簡単に マルチプラットフォームにおける 依存性の管理ができます “Binary Frameworks in Swift”の セッションで詳しく学べます Objective-Cでも同様に 動作します

次にAppをMacに持って行く際に 最も大切なのは自分のコードです 先ほどXcodeが自動で不要なフレームワークを ビルドから除外する様子をお見せしました それに加えてソースコードの調整が 必要かもしれません ハードウェアやユーザーエクスペリエンスの違いにより　　　　　 利用できないフレームワークに含まれる― APIへの参照を取り除いて コンパイルできるようにするためです

SwiftのTarget Environment Platform Condition またはObjective-CのTarget OS Macrosを使えば 条件的にコードをコンパイルできます

では見ていきましょう 再度ビルドを行います

ARKitは利用できませんね さて… 拡張現実でレシピをプレビューする 方法を追加したいと思っていましたが そうする必要はないでしょう 食べ物の最適なエクスペリエンスは 現実世界で味わうことですから ここをコメントアウトします ここで使用できるサンプルコードが 確認できます

“#if”でARKitを囲みます

対応するAPIも同様に“#if”で 囲みます

ではもう一度ビルドします

別のエラーです 分かりました　今回は… StoreKitフレームワークは Macで使用できるようですが しかしここで利用している 特定のAPIが利用できません マーケティングチームが 何をしたいのか不明ですが おそらく重要ではないでしょう #ifdefで外してしまいます では… TODOを残しておきましょう

“TODO: 他に何か?”と… できました これでAppを実行できます しかしその前にこのMac Appに対しての キーとなる改良点について考えてみます デフォルトでUIKitは iPadと同じアイコンを使用しています 角が丸い四角形のデザインです ここにおいしそうなクッキーの アイコンが見えます Mac Appは従来から 精密なアイコンを利用しています 最大サイズは512ポイントです デザイン性と柔軟性を高めるため 透過を利用しています AppをMacのアイコンでカスタマイズして より目立たせましょう “What's New in iOS and macOS Design”セッションで 素晴らしいアイコンをデザインする方法を 学ぶことができます Mac専用のアイコンを追加するため XcodeのAsset Catalog Editorを 使います ではAsset Catalogを選び App Icon Resourceを選択します

Inspectorへ行き

Macチェックボックスをチェックして 新しいスロットを開きます

ここに新たなアイコンを ドラッグします ここでは事前に用意しておいた アイコンセットを使います ドラッグします

おっと…

よかった　できました

ご覧のように素晴らしいアイコンが できました

ではもう一度やってみましょう 再度ビルドを行います iOS向けからMac向けのビルドに変更したため 時間がかかるかもしれません すべてのコードやリソースを 再度ビルドする必要があります

しばらく待ちましょう

ビルドに成功し Macで実行されました ご覧の通り… ありがとうございます (拍手) タイトルバーや ウインドウの赤青黄ボタン メニューもあります ウインドウはリサイズ可能で おいしそうなクッキーのアイコンも 見えます 期待通りです AppをMacに 移植できたら XcodeでProduct内のArchiveを クリックして アーカイブを作成し Organizerを開きます ここからMac App Storeで 配信でき― Developer IDを使って 独自に配信することもできます

これがXcode 11を使って iPad AppをMacに持って行くやり方です 再びアリに登場してもらいましょう 変更無しで得られるユーザエクスペリエンスの 向上について話してもらいます (拍手) では変更無しで手に入るものについて ご説明しましょう ホールで食べられるランチのことでは ありませんよ Mac AppのためのUIKitから 受けられるものです 無料で得られるものは 数多く存在します 先ほどお見せした全フレームワークの全てのスタック データベースやサービスなどの大部分は 自動的にMac Appで 動作します ここで強調したいのは 単に変更無しで得られるだけでなく 自動的にMacの枠組みやMacが処理するやり方に マッピングされることです では最初にジェイクが使ったレシピの Appを見てみましょう デモでご覧になったように デフォルトのメニューバーがあります 機能的なメニューバーにはMacユーザの期待に応える 多くのメニューアイテムがあります

次はウインドウ管理です リサイズやフルスクリーン Split Viewなどがあり ウインドウのストップライトと 呼んでいるものもあります タイトルバーにある３つの ボタンです さらに注目点を述べます iPadがそばにあれば Mac用iPad Appのウインドウを iPad上に表示することができます (拍手) ダークモードも自動的に 適用されます より快適なiOSダークモードAppにするため 新しいAPIを適用すれば それも自動的に引き継がれます スクロールバーも期待通りに Macで動作しています オーバーレイスクロールバーの 機能にマッピングされています ユーザの期待通り スクロール機能は ウインドウが非アクティブでも ゼスチャースクロールで動作します スクロールバーを常に 表示させるユーザー設定なら それも自動的に アプリケーションで機能します では設定についてです このレシピAppに 設定はないので ボイスメモを開きます iOSではAppがSettings Bundleを特定し これらの設定コントロールが iOSの設定Appに表示されます 例えばこちらはボイスメモの 設定です Macのデザインガイドラインでは メニューアイテムを通して Appの設定にアクセスします ですから、Appに設定が存在する時は メニューアイテムを追加し 自動で設定をMac prefpaneにマッピングします では横に並べて表示してみましょう これが自動的に行われるのです (拍手) すべてのアプリケーションが 使えるTouch Barに対する― 基本的なサポートが得られます AVPlayerViewControllerや UITextViewなどのAPIを使う場合 App内のテキストTouch Barのメディアにも 自動的にアクセスできるようになります ご覧の通りです

他にもDocument Pickerも 自動でマッピングされます これがUIDocumentPickerViewControllerが どのようにNSOpenPanelとして見えるかです ユーザの期待通りです

自作のカスタムビューも 意図した通りに表示できます これはボイスメモです カスタマイズした波形ビューも 両方のプラットフォームで同じように表示されました

他にもほとんど同じに表示できるものについて お話しします Newsのフォームシートを 見てみましょう こちらはiPadのNewsです こちらが通知を管理をする フォームシートです こちらはMacのNewsですが 同じフォームシートが表示されています ご覧の通りこれらのフォームシートは コンテンツ内のUIを入れ替えても そのままです では並べてみましょう これが私たちのゴールの１つです Appのソースの互換性を

可能な限り高めることです AppにAppKitのコントロールや メトリックスをフルに与えることは 混乱を引き起こすでしょう UIKitはコントロールと　　 レイアウトを個別に行って 同じように表示するので Appにとって最大限の互換性が得られます

次にテキストサイズです iOSでは基準となる フォントサイズは17ポイントです Macでは13ポイントです 隣に並べると大きさが 違うのが分かります この理由は２つあります iOSのディスプレイは 相対表示密度が高い上に タッチ操作にも対応しています Macアプリケーションとの インタラクションの一貫性を提供するため コンテンツエリアを77％に縮小します 画面上のデータは均一に縮小され Mac用にウインドウをデザインし直す 必要はありません 後の "Font Management and Text Scaling"セッションで このトピックについての詳細を確認できます

ではもう少し変更無しで得られるものを 確認しましょう コピー＆ペーストや ドラッグ＆ドロップ、プリントの機能を実装していたり マルチウインドウや iOS 13のマルチタスクAPIを― 利用している場合 これらは自動でMacに引き継がれます MacではAppの ライフサイクルはMacのパラダイムへ調整され ライフサイクル管理のための コールバックも自動で引き継がれ動作します 詳細は“Taking iPad Apps for Mac to the Next Level”でお話しします 他にもAppをより良いMac Appにするのに 役立つものがあります これらは一例です アイコンについては ジェイクがお話ししました 残りは別のセッションで お話しします iOSとmacOSのデザインについての セッションでも触れます ありがとうございました では次はジェイソンを 呼びましょう (拍手) ありがとう アリ

こんにちは ではiPad Appを Macに持って行く際に遭遇する― APIの相違点をご紹介します

３つのカテゴリーに分かれます

まず 同じ動作をするAPIです 幸運なことにほとんどのAPIが 予想した通りに動作します

次にmacOSの機能に自動的に マッピングされたAPIです これらはiOS APIを利用しますが 結果的にmacOSの動作となります そして最後に 様々な理由で 利用できないAPIです さて最初の項目については 省略します ２つめについては アリがお話ししましたね ３つめの項目に入る前に 追加で話しておきたいことがあります マウスとタッチイベントです iOSはダイレクトなMulti-Touchの 操作に対応したモデルで macOSはインダイレクトで カーソルベースのモデルです Multi-Touchアプリケーションを Macに移植し 快適に動作させるのは 大変な作業です 私たちができるだけ多くの動作を 自動的にマッピングできるよう努力しているにもかかわらずです

私たちはUIHoverGestureRecognizerを 導入しました マウスカーソルがビューの上を 通ったことを知らせます

またマウスの左ボタンドラッグは 単一の合成タッチシーケンスにマッピングされます これはシングルタッチを認識するように設定されている タップ、パン、長押しジェスチャ認識機能によって 自動的に認識されます

Mac上では 標準のシステムジェスチャは ハードウェアかドライバレベルで 認識されます そして上位レベルのジェスチャイベントが システムに送られます UIKitアプリケーションが上位の ピンチや回転ジェスチャを受け取ると タッチのペアを統合し カーソルのあるビューにデータを送ります これにより自動的に ピンチや回転の― GestureRecognizerを 起動させます

もしユーザがシステム標準の スクロールジェスチャを行った場合は タッチを統合しません しかしUIKitは自動的にカーソル下の UIScrollviewをスクロールします

カスタムMulti-Touch動作は 自動的にマッピングできません 直接UITouchを扱っているか カスタマイズしたGestureRecognizerを記述している場合 Macの様々な入力デバイスから― カスタムジェスチャへは 自動ではマッピングされません アプリケーションがこれらに 依存している場合 Macに移植した時 同じ動作を させるためには別の方法が必要です

では３つめの項目に入ります 利用できないAPIです これは４つのグループに分けられます まずサポート対象外のフレームワーク 次にMacに存在しない iOSの機能と結びついているため 利用できないフレームワーク Macに存在しない特定の ハードウェア機能やセンサーに― 関連しているフレームワーク 最後は何らかの理由で macOSで利用できないAPIや 動作が異なる フレームワークです わかりやすいようにアノテーションが付けられ Xcodeのエラーが発生します もう少し詳しく見ていきましょう

通常廃止(deprecate)が宣言された フレームワークであっても しばらくは利用できます しかしこれは iPad Appにとって― 新たなプラットフォームなので― 廃止が宣言されたフレームワークは 利用できると考えるべきではありません これを機に廃止予定のフレームワークを 別のものにリプレイスしましょう これにより Macに移植できるだけでなく iPad App自体にも 利点となります

現在Mac上にはない機能を持つ iOSのフレームワークがいくつかあります ClassKitフレームワークはアプリケーションと スクールワークAppとの― 連携用にデザインされました しかしそのアプリケーションは Macには存在していません HealthKitやHomeKitは― 基本機能が存在しないため 現時点で利用できません

iOSデバイスの特定のセンサーや そこにしか存在しない機能に― 関連するフレームワークもあります これらもMacでは 利用できません あなたのアプリケーションがこれらを利用しているなら 移植の前に調整が必要です

iOSデバイスの特定のハードウェアに関連する フレームワークの中には Macにとって 意味のあるものもあります しかしそれらのAPIの 利用や機能は限定的です Macが互換性のあるセンサーを 持たないことが多いためです

場合によっては セルラー接続を持たないiPadも同様です そのままでもAppは 正しく動作しているかもしれません もう少し 相違点の種類についてお話ししましょう Core Locationは動作しますが MacはGPSチップがありません 特に位置の変化の感度が良くないことを 覚えておきましょう ゲームのコントロールで Core Motionを使う場合は Macには必要なセンサーがないことに ご注意ください これは快適なユーザエクスペリエンスには なりません Mac上でゲームをコントロールするには 代わりのメカニズムを追加すべきです

メディアに関連するフレームワークには 相違点のあるものがいくつかあります Media Playerフレームワークは 基本的にはMacと同じ機能を持ち Now Playing Info Centerや Remote Command Centerなどにアクセスできます しかしライブラリアクセスや プレイバックサポートはありません AVFoundationフレームワークを使って iOSデバイス上の 画像や動画をキャプチャしている場合 UIKitのUIImagePickerController を使えば Macの内蔵カメラを 使用してキャプチャできます

他のフレームワークも同様に 違いがありますのでご紹介しましょう Metalはどのプラットフォームでも ほぼ同じです iPadのMetal Appは Macに移植しても 大きな変更なしに動作するでしょう Memoryless Textureのような 最新のGPU機能を使う方のために― 新たなGPU用のAPIが設けられています それは様々なレンジのGPUファミリーで 実行するコードを条件に応じて調整します UIKitのUIWebViewは Macには存在しません 使用している場合は WKWebViewに移行します

APIの違いを見てきましたが すべてをご紹介する時間はありません そこでiPad AppをMacへ持って行く際に どのAPIが利用でき― どれが利用できないかを 自分で見極める方法をお話しします

Macに移植したiPad Appは macOS SDKに対してビルドされています そのため利用できないフレームワークは SDKに含まれていません またiOSとmacOSで 異なるフレームワークの場合は 明確にするために必要に応じて アノテーションが付けられています APIのアノテーションは Swiftでは“@available” Objective-Cでは“API AVAILABLE”です iOSアプリケーションにとって 注意すべき点はここだけです

iOSで有効ならばMacへ 移植するiPad Appでも 利用可能であるということは良い知らせです 前にも言いましたが 大部分のAPIは利用可能です そのためAPIを確認している時に これを見ることになるでしょう

可用性に相違点がある場合も アノテーションで示されます これはMac上での iPad App専用のAPIの例です このようなAPIは非常にまれです Macへ移植するiPad Appで　　 見られるAPIの違いのほとんどが― そのAPIをiOSでは利用できても Macでは― 利用できないという違いです ほとんどの場合 UIKitForMacは利用不可であると― APIに明確に アノテーションが付けられています

同じコードをそのまま移行できる のが理想的です しかしMacでは 含められないコードがある場合 そのコードを除外するために “targetEnvironment”条件を使います Objective-Cを使っている場合は “TARGET OS UIKITFORMAC”が 同様の機能を持ちます もちろんこれはMacにのみ関連するコードを 含めるためにも使えます

Data Protectionは Appファイルを保護して 不正なアクセスを阻止する iOSの機能です ファイルの読み込みや書き込みは通常通りできますが システムはこれらの暗号化と復号化を自動で行います

これはファイルシステムに対してファイルを書き込む際に、 4つあるうちの1つの記述オプションを指定したアクセスです

macOSではこのような Data Protection APIは機能しません このサンプルのように記述し コードをコンパイルし実行できますが データはファイルシステム上に 安全に保存されません データを安全に保存したい場合 いくつかの選択肢があります パスワードと関連データを キーチェーンに保管したり FileVaultでディスク上の すべてのファイルを透過的に暗号化できます しかしこれではまだ 十分ではないかもしれません ディスクに書き出す前に コンテンツを暗号化するには CryptoKitのAES.GCMが 利用できます ご覧の通りデータの暗号化が 簡単にできます あとはデータをディスクに保存し キーチェーンにキーを書くだけです 保存や復号の方法についての詳細は ドキュメントをご確認ください

次にお話しするのはアプリケーションの バンドルフォーマットです iOSのアプリケーションバンドルは フラットバンドルです Macに移植するiPadアプリケーションを Xcodeがビルドすると iOSで使うフラットバンドルより深い macOS仕様のバンドルでビルドされます

アプリケーションのリソースを NSBundle APIを使って参照していれば すべてを トランスペアレントにできます しかしバンドルの相対パスを ハードコーディングしている場合 macOSのバンドルフォーマットで 扱えるように修正が必要です

iOSは様々なExtensionを サポートしています ただしiPad Appを Macに移植した時に すべてが利用できるとは 限りません これらはサポートされているExtensionですが いくつかAPIの相違点があります これらのExtensionは自動的に AppKitとUIKit App両方で動作します 例えばアプリケーション内の Share Extensionは― AppKitアプリケーションの Share Extensionと並んで― 共有メニューに表示されます

またmacOSでは利用できない Extensionもあります これらはmacOSでは 意味のないものです ステッカーパックやCustom KeyboardsやiMessageなどです 対応する機能がmacOSに 存在しないからです そしてFile Providerなどは macOSのFile Provider Extensionに 直接置き換えるべきです

Macへ移植するiPad Appに　　 影響を与えるAPIの違いを見てきました　　　　 では実際にどのように対処するのか デモをご覧ください

レシピアプリケーションでは お気に入りのレシピをマークできます その状態を示すハートが 名前の隣に表示されています Appにはお気に入りかどうかを切り替える カスタムMulti-Touchジェスチャがありますが お話しした通り Macでは動作しません 代わりにカスタムメニューアイテムを 追加しましょう

まずはカスタムGesture Recognizerを オフにします 該当の箇所を“target conditional”でラップして カスタムGesture Recognizerを無効にします おっと…

少しお待ちください

では… 次に行うのは

Gesture Recognizerから呼び出されるメソッド ”toggleSelectedRecipeFavoriteState”に行き “IBAction”のアノテーションを 追加します これをIBが認識します 最後にMenu Validationメソッドを 追加します これは現在選択している レシピがお気に入りかどうかを見て お気に入りとして登録するか 除外するかの切り替えを行います

さらにカスタムメニューを 追加する必要があります

Storyboard Editorに移動し メインメニューをドラッグします

失礼 間違えました

メインメニューです Fileメニューに新しい メニューアイテムを追加します インラインメニューセクションを 追加します 必要なのは１つなので 他は削除します ここを“Make Favorite”に 変更します 同じ処理をコマンドキーにも 割り当てます

次に必要なのは first responderと接続すること

そしてGesture Recognizerが呼び出す メソッドと同じメソッドを呼び出させさせます アプリケーションを ビルドして実行させましょう

ここが違っていました

新しいメニューアイテム“Make Favorite”が確認できます クリックするとお気に入りのアイコンが表示され 同じように削除することも できます ショートカットも 正常に動作しました (拍手)

このようにiPad Appを Macへ持って行くのは簡単です 適切なAppをお持ちなら、Macのチェックボックスをオンにして ビルドと実行をしてみましょう 最新情報はドキュメント リリースノートをご確認ください このセッションの後 私たちはラボにいます 木曜の“Taking iPad Apps for Mac to the Next Level”にもぜひお越しを プラットフォーム固有の機能を 組み込むことにより Appをより快適に Mac上で動かす方法をご説明します 今日の“What's New in iOS and macOS Design”では iPad AppをMacへ移植する際の デザイン的な配慮についてお話しします 最後に“Font Management and Text Scaling”では 新しいフォントやiPad AppをMacへ移植する際の フォントの取り扱いについて詳しくお話します この後も お楽しみください (拍手)