iPad Apps for Macを次のレベルに高める

(音楽)

こんばんは (拍手) UIKitチームの ジェイミー･モンゴメリーです これから私の３人の同僚と iPadアプリケーションの Macへの移植について説明します

すでに“Introducing iPad Apps for Mac”では― ビルド方法や主要APIの違いについて 基本を話しました 今回は発展的な内容です 優れたMacアプリケーションの作成方法 マルチプラットフォームや デザインの考慮点 アプリケーションの ライフサイクルの相違点や 配布についてお伝えします

まず優れたMacアプリケーションの 作成方法です それには優れたiPadアプリケーションが 必要ですね iPadとMac両方について 説明しましょう

アプリケーションはiPadで iPad miniからiPad Proまで Slide Overを利用して表示します しかしMacでは違います フルスクリーン表示が可能で 縮小表示もできます 27インチのディスプレイは 35インチiPadのようなものです 表示スペースが広いので 開発にはDynamic Typeや Auto Layoutを利用します またリサイズが 素早くできる必要があります レイアウトコードは 60fpsで実行できますか？ できない場合は Instrumentsのツールを使いましょう

次にキーボードの実装です Macユーザは常にキーボードを使います iPadでも使用が増えていますね ショートカット利用には UIKeyCommandを使います ビューコントローラで 標準機能に対応可能です カット コピー ペーストなどです レスポンダのPingにも気を配りましょう 最初のレスポンダを設定すれば キーコマンドが正しく動きます

ゲームの場合は Game Controllerを使えば iOSとMacユーザの両方に メリットがあります

２年前 UIKitによる Drag and DropのAPIを紹介しました 今回 本機能が Macでも使えるようになります Macユーザに 最高のDrag and Drop体験の提供です

必ず最新のAPIを使ってください 最新でない場合は一度見直しをして APIの廃止予定がないか確認しましょう 今年は特に確認をお勧めします 前にもお伝えしましたが iOSで廃止予定のAPIは Macでは利用できません WKWebViewとMetalを使って 開発しましょう これらのツールを使えば iPadとMacで 全作業を行うことが可能です

iOS 13の機能もサポートしています 例えばiPadで マルチウインドウを使うなら Macでも同じように使えます

ダークモードも iPadとMacの両方でサポートしました 今回 詳細な説明はしませんが 興味があれば Webサイトをご覧ください 優れたiPadアプリケーションは Macアプリケーションの基本です

Macアプリケーションに特化した 改良点もあります もっと快適にMacでUIKitを 使っていきましょう 様々な機能が便利に使えます 既存のUIKit APIで 独自のMac機能を可能にしました Mac向けの新APIなので デベロッパにとっても新しいですね

利用可能なAPIを幅広く見てみましょう

Mac独自と聞いて思い浮かぶものは？ 私ならメニューバーですね Mac独自のメニューバーは ユーザが実行する操作を 画面上部に格納しています どのアプリケーションでも ユーザ操作によって メニューがオンオフされます

iPadアプリケーションでは デフォルトを使えば大丈夫です

Interface Builderで メニューバーを構成できます コードを組むことも可能です

お気づきの方もいると思いますが UIKeyCommandでは 新たなスーパークラスができました UIMenuやUIMenuBuilderと連動し メニューバーを 完全にコントロール可能です デモをお見せします

メニューで使ったUIKeyCommandは iPadでも利用可能です コマンドキーを長押しすると 表示されます このAPIはMacだけでなく iPadにも適用できるのです

Macには コンテクストメニューもあります 項目によって コンテンツが動的に変わるメニューです iOSでも使える新APIの UIContextMenuInteractionでは UICommandとUIActionが含まれています ブロックベースの UIActionは使いやすいでしょう このAPIを使えば Macでの表示も従来通りです

詳細は“Modernizing Your UI for iOS 13”で説明しています

以前からのUIKit APIに UISplitViewControllerがあります Macのサイドバーは iOSのSplit Viewに似ていて 詳細の表示に よく使われます Mac上のUISplitViewController 管理ビューでは 列幅のサイズ変更が自動で行われます 新しい primaryBackgroundStyle属性を使えば 左列が Macのサイドバーのようになります

サイドバーの背景を使っている場合 埋め込まれたテーブルビューは ソースリストに表示され Macのホーム画面のようです デモでお見せします

Macでよく使うホバーは iPadにはありません そこで追加したのが UIHoverGestureRecognizerです これでUIKitでホバーが使えます この株アプリではホバーをうまく活用し 該当する株価と連動して 棒が動くようにしました

すでにMacには優れたAPIが存在します その１つが画面上部にある ツールバーです これはMacだけの機能なので NSToolbarを作りました UIWindowSceneのtitlebarで 利用できます こちらもデモがあります

Touch BarもMac独自です MacBook Proではキーボード上部にあり ユーザ操作によってボタンが変化します Touch Barをサポートするため UIKitにNSTouchBarを入れました UIResponderとUIViewControllerから 利用できます

他にも多くのMac機能を使えます 画面サイズの管理も可能です 印刷用APIも iOSとMac両方で使えます アプリケーションの Help Bookを書くことも可能です アセットをカスタマイズして Mac独自の外観や表示を作れます

最後はアイコンについてです 何もしなければ MacにiPadのアイコンが使われます Mac独自のスタイルで 作ることも可能です ユーザが最初に目にするものなので ぜひ工夫してみてください

では同僚のグレンが アプリケーションの変換について ご紹介します (拍手) ありがとう

優れたiPadアプリケーションは Macでも優れたものになります 例を見てみましょう ChocolateChipは レシピのiPadアプリケーションです 以前のデモでお見せしたことは…

少々お待ちください 以前のデモではこのチェックボックスを チェックしました 問題を修正し このようにビルドして実行します

少し待ちます このように新しい期待通りの Macアプリケーションができました ドラッグ可能な画面に コンテンツが表示されています ジェイミーが伝えたとおり サイズの変更をサポートしました このように素早くスムーズに リサイズできますね

実装するとTableViewController内の 既存のコールバックで TableViewController内の行を 並べ替えられます 別の編集モードにはなりません Macの機能です

UIContextMenuInteractionを 使っています 新しいAPIです UIActionやUICommandと共に 構成され― コンテクストメニューは シームレスにMacに引き継がれます ここで“お気に入り”に登録 登録もできますし登録解除も可能です

メニューについては デフォルトのアイテムがそろった メニューバーが使えます

例えばカット コピー ペースト 取り消す やり直す などです Responder Chainにより アイテムはオンオフされます

最後になりますが ダークモードのAPIを使って システムカラーで色を特定します スムーズにダークモードが動きますね 画面が黒っぽくなりました すべてにダークモードが 適用されています コードは１行も書いていません

(拍手) ありがとう (拍手)

アプリケーションを 次のレベルに引き上げるには？ 何をすれば もっとMacらしくなるでしょうか？ ポイントは３つあります サイドバー ツールバー メニューバーです “バー”で もてなすように 説明しましょう

どうも (笑い声)

それでは手始めに― Master Viewを見てください Split View Controllerの Master Viewです これをMacのツールバーらしくします スタイルの設定を見ていきましょう

まずRecipeSplitViewControllerで viewDidLoadをデリゲートします ここでUIKitForMacを入れているので Mac用のビルドのみに適用されます そしてprimaryBackgroundStyleを挿入 “.sidebar”を設定します この１行を書いたら次にやることは…

リビルドです

サイドバースタイルが適用されました Macのサイドバーらしい部分を お見せしましょう 動かすと サイドバーの透明感が分かります その他にも環境設定で サイドバーのアイコンサイズが 変えられます 小さいアイコンを選ぶと 動的に更新されます 大きいアイコンです 中程度のアイコンです 先ほどと同じように 並べ替えておきました

オーケー

アプリケーションを表示します

次はツールバーです 様々なウィジェットが タイトルバーに統合されていて ユーザは よく使うコマンドを選べます アプリケーションの下部に ツールバーがあるiOSとは違いますね 検索条件の設定ウィジェットと レシピ追加のウィジェットを用意します やってみましょう

Sceneデリゲートでは willConnectToコールバックに 接続します

条件にUIKitForMacを設定すると Macだけに適用されます オブジェクトモデルの windowSceneを埋め込んで titlebarを設定します titlebarオブジェクトは ツールバーやタイトルバーの表示を 変更できます ではツールバーを作りましょう

プレフィックスに“NS”があるものは AppKitオブジェクトです

identifierを設定 先ほども設定しましたね 最後にこの１行を書きます 先ほど作成したtoolbarです ２行でタイトルバーが付いた ツールバーができました これ自体は特に 興味深いコードや結果ではありません 実際のアイテムを使って 構成してみましょう

コードを見てください まずrootViewControllerを ToolbarDelegateの イニシャライザに渡します Delegateを設定 ツールバーのカスタマイズを 可能にします “.navigationItem”は 先ほど説明したフィルタです titleVisibilityを “.hidden”に設定 これでタイトルが ナビゲーションアイテムに 重なるのを避けられます では早速…

再コンパイルとビルドです ツールバーができました ツールバーには 食事を選べるフィルタもありますね 朝食にはドーナツを選びます

ランチはピザ 夕食はパスタにします デザートはパスタではなく…

チョコチップクッキー！

アイテムを追加するウィジェットもあり 新しいレシピを追加することができます

オーケー

ではメニューバーのカスタマイズをして ユーザが必要なコマンドを 便利に使えるようにしましょう 必要に応じてコマンドは 有効化または無効化されます 一方 ツールバーは よく使うコマンドのみ表示します

前のセッションでは この操作を XcodeのInterface Builderを 利用して行いました 実行時のメニューの制御を 改善したい場合はコードを書きましょう

まずFormatメニューを削除します このアプリケーションには 編集可能なテキストがないので フォントや行の調整は必要ありません ２アイテムを ファイルメニューに加えるため 新レシピ追加のための コマンドを設定します ウィジェットの時と似ていますね

お気に入りをオンオフするコマンドも 加えましょう コンテクストメニューと似ています

では設定方法です

AppDelegateを開き １つのメソッドをオーバーライドします

buildCommandsにbuilderが入り UICommandBuilderに渡されます 以降のシード値で これはbuildMenuと呼ばれ buildオブジェクトを伴い UIMenuBuilderへ 現在のシード値を扱う場合は 気をつけてください まずメインメニューの構築であることを 確認します ここでメインシステムではないことを 確かめます “.context”を使えば コンテクストメニューです

次はbuilderの設定です このbuilderで削除されるのは―

個別メニューです ここでフォーマットメニューを 削除します コード補完されるので とても便利ですね 削除可能なメニュー名が補完されます

クイックビルドをして実行します EditとViewの間のFormatが 削除されました

このコードに戻ります builderは自由度が高く 構造全体を置き換えることや 選択的な編集など何でもできます

次はコンテンツの挿入をやります まずbuilderに insertChildを設定しましょう

ここには“.file”と書きます

次のコードを見ましょう

ここにコマンドを…

選んで加えていきます １つ目はnewRecipeCommandです UIKeyCommandに― createRecipeメソッドを 設定していきましょう inputに“f”を取り そしてオプションを入れます これでコマンド“f”を入れれば UIKeyCommandが発動できます UIKeyCommandの利点は クロスプラットフォームなことです コマンドを見つけやすくなっています iPadでも同様です 条件を設定することなく MacとiOS両方で有効です

次はmakeFavoriteCommandです 等価キーを持たない通常のコマンドで toggleSelectedRecipeFavoriteStateを 起動します

最後にメニューです グループで構成されるのは newRecipeCommandと makeFavoriteCommandです 特にお伝えしたいのが オプションのdisplayInlineで これによりコンテンツが メニューと一緒に表示されます オプションを省略すると メニューは昔のMacのように 階層的に表示されます

見え方をチェックしましょう

ここにmenuを入れていきます

クイックビルドをして実行します

New Recipeコマンドができました ウィジェットの時と同じですね

Make Favoriteもあります チョコチップにハートがつきました 取り消すこともできます まとめましょう 今お見せしてきたことはすべて無料で iPadアプリケーションを 再構築しただけでした サイドバー ツールバー そしてメニューバーを作り アプリケーションのレベルを 引き上げました 次はデザインについて ジェイミーが話します (拍手) ありがとう

これまでは 技術的な詳細について話しましたが 今からはデザインについてです

まずは ナビゲーション ユーザはアプリケーションを どう使うのでしょう Macのサイドバーや iPadのSplit Viewを使わない方は タブバーを検討してください Macではツールバーで Segmented Controlを使いましょう

次はレイアウトです 画面サイズについては 大画面を活用したいものです UIのリフローや再設計 ハードウェア関連のコンテンツを 書き換えることができます

iPadのデザインはMacより大きいので フォントサイズも違います テキストはiOSでは17 Macでは13ポイントが一般的です そのためAppKitの表示と比べて UIKitのコンテンツを77％拡大しました つまりUIKitはAppKitのポイントよりも 小さくなるのです ビットマップ画像も同様で UIKitでは AppKitよりも77％小さくなります アプリケーションに対して スケーリングはグローバルです フォントサイズを直接変えたい場合は “Font Management and Text Scaling”をご覧ください

メニューバーには どんな内容を入れるべきでしょうか メニューには コマンドが集められており ユーザの状態により アイテムがオンオフされます つまり内容が変わらないように ビルドは起動時の１回だけです アプリケーションの全機能を考え メニューバーから起動可能にしましょう

iPadはタッチに最適化されており 中でも独特なのはマルチタッチです Macにはタッチがありませんが キーボードやトラックパッドがあります 入力デバイスとして ジェスチャを使う方法を考え Macのトラックパッドに 再実装したいですね アクセシビリティの考慮も忘れずに

今回は手短に説明しましたが “Human Interface Guidelines”には 多くの情報があります ぜひ参照してください “Designing iPad Apps for Mac”も お勧めです UIKitでMacアプリケーションを 開発するのに役立ちます

iPadのアプリケーションを Mac用にする方法について話しました 次にニルスが話すのは MacにおけるUIKitの独自な点― アプリケーションライフサイクルです (拍手) ありがとう こんにちは AppKitチームのエンジニア ニルス･ベックです これからアプリケーション ライフサイクルについて話します

iOSとmacOSのアプリケーション ライフサイクルは異なり UIKitはiOS特有の動きになっています Mac上でiPadアプリケーションを 実行する時に どのようにiOS APIを マッピングすればいいでしょう

まずはiOSの既存ライフサイクルを 見ていきましょう スライド右側の図を ご覧ください

iPadのアプリケーションを 操作している状態は フォアグラウンドでアクティブです

別のアプリケーションの下にある場合は インアクティブで イベントは受信しません コントロールセンターが 前面にあるような一時的な状態です

バックグラウンドの場合は アプリケーションは使われていません App スイッチャーなどで 前面に出ていない状態です タスクはバックグラウンドで動き それがなければ一時停止します

一時停止すると CPUサイクルも消費されません システムは通知せずに アプリケーションを強制終了できます

メモリ上にも存在しない時は アプリケーションは停止です

これらをまとめて iOSとmacOSの実行で起こり得る 状態変化を見てみましょう でもその前に シンプルに整理したいと思います iPadアプリケーションは Mac上でもiOSと同様に デリゲートされ通知が来ます

ApplicationDelegateもありますが ここに示したものに加え NSNotificationもあります

これらの通知を使いましょう 新たなMultiple Windowsでも機能し デリゲートコールの省略にも 対応できます iOSでも同様です またMultiple Windowsの アプリケーションの状態は 個々のシーンの起動状態に依存します つまりシーンごとに 状態変化を処理しましょう でも今回は ライフサイクルのみに注目します

デリゲートと通知に加えて macOSでは状態変化の順序も iPadと同じです

では状態変更通知の順序を 詳細に見ていきましょう

起動時はdidFinishLaunchingと didBecomeActiveが動きます

その次にwillResignActiveと didEnterBackgroundです

アプリケーションの終了時は willTerminateが動きます まだ一時停止状態ではありません

最後にバックグラウンドの状態から willEnterForegroundと didBecomeActiveになります

通知と順序は 両プラットフォームで同様です macOSで遷移がある場合のため 変更しました 後ほど解説します

iOSに戻りましょう 状態変化に対して 対応できるコードを書きましょう 例えばwillResignActiveで アプリケーションを止める場合に 他にも必要なことがあります 表示コンテンツの フレームレートの削減や 不要な機能の停止 タイマーやキューやクエリなどですね またゲームを中断するなど 他の影響もありそうです

同様にdidEnterBackgroundで バックグラウンド状態に入ると iOSのアプリケーションは 全レンダリングを停止します CPU利用を最小限まで減らすのです メモリも解放されます 他の影響もあるでしょう 例えばコンテンツを非公開にする場合は スクリーンショット撮影前に 非表示にできます

macOSへの変換時に状態変更のコードを すべて書く必要はありません しかしアプリケーションは Mac用になります その仕組みは？ Mac固有の考慮があります

Macでは画面の同時共有が一般的です

その１つがfrontmostApplicationで キーイベントを受け取り メニューバーを表示します

多くがコンテンツの可視性に影響します 例えば画面が重なり合っていたり 最小化されたりする場合です 別の操作スペースに あるかもしれません

コンテンツ自体が 表示されていないこともあります アプリケーションが隠れていたり 画面がなかったりする場合です オフスクリーンで 実行されている可能性もあります つまり仮想空間に VNCでアクセスする可能性が あるということです

最新状態や コンテンツの実現可能性によらず Macのアプリケーションでは 劇的な変化は起こりません iOSと違う点です

すべてのアプリケーションには 役割があります 前面に出ていないものでも スクロール クリック ホバーなどを 受信するのです ゲーム中のユーザは アプリケーションの切り替え時でも 必ずしも停止を望みません 仮想画面上の VNCセッションを使うような時です

状態変化時の処理を変更したと 先ほどお伝えしました このとおりです 既に説明しましたが macOSにおいては 全iPadアプリケーションを 前面に表示しアクティブにします インアクティブになるのは バックグラウンドの時だけで アプリケーション終了や バックグラウンド起動が該当します つまりアプリケーションが ユーザに見える時は フォアグラウンドで アクティブということです

繰り返します UIKitが状態変化した時の通知は メニューバーのオンオフや 画面の重なりでは呼ばれません

つまりリソースの消費は 減らないということです しかし全アプリケーションには App Nap機能が適用されます これはmacOSの機能で システムがアプリケーションを監視し 使用中か否かを判断するものです アプリケーションが 本当に利用されているかどうかを調べ

安全だと判断すると 自動でスロットルを適用します

終了時とバックグラウンド起動時には 状態が変わります 終了時を見てみましょう

iPadからmacOSへの変換で デベロッパが注意すべきことは 変換前後のアプリケーションが 同一ではないということです iOSのバックグラウンドで音楽再生中に アプリを切り替えるのは Macで前面のアプリケーションを 変えるようなものです ユーザが実行中だと 認識されるからです

一方でアプリケーションを使わず 音楽再生もない場合は Macの終了に似ているかもしれません 最終的にアプリケーションが 終了するからです

macOSでの iPadアプリケーションの終了は iOSでのアプリケーション切り替えと 同じ状態遷移です 例えばApp スイッチャーです

状態はフォアグラウンドアクティブから インアクティブを介し バックグラウンドに遷移します ユーザにとっては アプリケーションの停止に見え 残りの画面は見えなくなり メニューバーのコントロールも不可 ドックの表示ランプも消え アプリケーションは タスク切り替えで使用できなくなります

実はバックグラウンドのタスクは 完了可能です UIApplicationの通常のAPIで タスクが生成された場合です

iOS同様 バックグラウンドタスクの 有効期限切れが心配です １つ例外があります バックグラウンドの Plistエントリは無視されます オーディオリクエストがあっても プロセスが終了し ユーザには終了したように見えます そのためバックグラウンド状態では メディアフレームワークにより 再生が一時停止するのです

ただしmacOSではバックグラウンド オーディオは不要です アプリケーションを切り替えても フォアグラウンドアクティブだからです

更にユーザがバックグラウンドで 起動しようとすると フォアグラウンドアクティブが 返されます App スイッチャーで 切り替えるのと似ています この再起動が可能なのは バックグラウンドタスクの処理中だけで willTerminateの 同期処理後ではありません そのためこのフェーズは 最小限にしましょう

バックグラウンドタスクが終わると プロセスは中断せずに終了します デリゲートコールと通知は iOSと同様です 今回の場合はwillResignActiveと didEnterBackground そしてwillTerminateです iOSとは違ってプロセスを終了します

MacでのiPadアプリケーションの終了を 話しました Mac上のiPadアプリケーションが バックグラウンドになる別の方法は 直接バックグラウンド起動することです iOSにはバックグラウンド起動を 選べるAPIが多くあります 更に詳しく知りたい方は “Advances in App Background Execution”をご覧ください

これらのAPIのサブセットは Mac用でサポートされています

バックグラウンドダウンロード用に 設定されたURLセッション

APSディクショナリ指定のコンテンツを 利用したサイレントリモート通知です 例えばサーバからアプリケーションの コンテンツを更新する時に使えます

またユーザがフォアグラウンドではない 通知を起動する場合もあります ユーザ通知を使ったメッセージを 気に入れば アプリケーションをバックグラウンドで 起動し サーバに通知ができます 更に新たなBackgroundTasks フレームワークを作りました BGProcessingTaskに加え 従来のバックグラウンド更新に使える BGAppRefreshTaskもあります アプリケーション更新機能は この新たなAPIでのみ使えます

バックグラウンドランタイムと プロセスの優先度の制限は iOSと同様です そのため時間がかかると アプリケーション停止や削除の リスクがあります

バックグラウンドのアプリケーションを 起動しようとすると フォアグラウンドアクティブに 移行します 先ほどの停止時の動作と似ています

バックグラウンド起動でも 全状態遷移はiOSと一致します この場合は didFinishLaunchingと バックグラウンド起動APIに 固有のコールバックのみが表示されます

完全にユーザが起動した時のみ willEnterForegroundと didBecomeActiveが表示されます

macOS上でiPadアプリケーションが 停止することは まれです 通常終了ではアプリケーションは 停止せずに排他的に終了します macOS用に変換しても バックグラウンドや停止になりませんが バックグラウンドで直接起動した場合は 停止する可能性があります

iPadで終了の可能性があるのは 特に停止状態で リソース不足の場合です macOS上で iPadアプリケーションが停止すると メモリ不足に陥っていなくても すぐに終了します

メモリに関しては Macのメモリ方式が適用されており 処理が重い時でも終了しません

これは もろ刃の剣です 実行時間が長くなるのでリークの蓄積で パフォーマンスが低下します VMのスワッピング発生時に 特に起こり得ます

リークを防ぐためテンプレートや Instrumentsを使ってください iPadにも有効です

では振り返りをしましょう

macOSでiPadアプリケーションは 大抵フォアグラウンドアクティブです

アプリケーションの終了や バックグラウンド起動で フォアグラウンドインアクティブや バックグラウンド状態になります

バックグラウンドにすると オーディオ再生は継続しません macOSでも― iOSと同様に 状況変化に対応することが可能です

それではクリスが MacへのApp配布について話します (拍手)

ありがとう

皆さんはアプリケーションを 構築してきました

App Storeへの配布や TestFlightの使い方 開発者署名やad-hocなども ご存じですね これからは― Macのアプリケーションも 売ることになります コードベースは同じです その方法は？ Macで違うことは？ 両アプリケーションを 顧客にシームレスに使ってもらうには？ これから説明します 最初に戻りましょう Xcodeでエディタを開き Macサポートを有効にします アプリケーションの調整は完璧です その時 コード署名について 心配になりました いいでしょう 皆さんは署名について調べようと考え “Signing & Capabilities”タブを 開きます すると様々な処理があることが 分かりました 見てみましょう まず自動署名を有効にしている時は すべてをXcodeが処理します 変換も非常に簡単なので 利用をお勧めします

自動署名を使うとXcodeは プロビジョニングプロファイルを MacとiOS向けに生成します ここは少し改良しました iOSとMacで違うものではなく 統一した開発者証明書を 使うことにしました (拍手) Macサポートを加えると Xcodeは自動署名を使い 予約済みのバンドルIDを登録します Mac用のプリフィクスは “uikitformac”となっていますね 重要な点はバンドルIDを コードや認証で利用してきた場合は 両アプリケーションへの影響を 考慮することです

iOSで使ってきた認証ファイルは Macへの署名時に共有されます

Macサポートが有効な場合は XcodeはMacに必要な機能を加えます Hardened RuntimeとApp Sandboxです 例えばinfo.plistに カメラの設定をした場合― XcodeはMacで動くように 認証ファイルを更新します

iCloudのDefault Containerは バンドルIDをベースとしています つまりXcodeは認証ファイルを調整し iOSでもMacでも既存のコンテナを 明示的に示します デフォルトのContainer APIを使えば 利用可能です

Xcodeは自動で移行処理をします しかしiOSとMacで機能を共有する場合は 手を加えることが必要です

キーチェーンを利用する場合は Xcodeにキーチェーン共有を追加します iOSではデフォルトで iCloudキーチェーンが使えますが MacではIntentの宣言が必要です

プッシュ通知を使う場合は アプリケーションに通知を送ります iOSとMacのアプリケーションに 通知されます

開発プロジェクトの設定について 説明しました

アプリケーションの配布時は まずアーカイブを作成し iOSではエクスポートしたIPAを App Storeにアップします 一方 Macの場合は XcodeがApp Storeにアップする時は パッケージとして送られます

App Storeへの更新方法は iOSと似ています プロジェクトを開き “Product”を選びます 実行先を“My Mac”に変更し “Archive”を選択 するとmacOS Appsで アーカイブができます そこから“Distribute App”を選べば 残りは従来通りです

もちろんコマンドラインからも 同様の処理が可能です

処理の自動化については 2017年に紹介しました “What's New in Signing for Xcode and Xcode Server”です

App StoreにMacのアプリケーションを 送る前に行うことがあります まずApp Store Connectで プロダクトページを作成 iOSの時のように もう一度作ってください

この手順を踏めば プロダクトページと “uikitformac”で設定したIDが 結びつきます

アップロードの際は ビルド番号も更新しましょう macOSはビルド番号で リリース順を見るのがiOSとの違いです これでXcodeから App Storeにリリースできました

Macの利点はインストール方法に 自由度があるところです App Storeからのダウンロード後は 他のMacにコピーして実行できます 注意事項があります App ThinningはmacOSで使われません アプリケーションは どのMacでも 実行可能なリソースを持ちます

コピー対策としてレシート検証の実装は デベロッパ次第です 起動の度に正規購入か否か チェックする必要があります

レシート検証について更に知りたい方は 2017年の“Advanced StoreKit”を ご確認ください

一度App Storeに上げれば ツールを使えるのが利点ですね App Store ConnectやApp Analytics XcodeのCrashes Organizerなどが あります

またStoreKitや GameKitのAPIも使えます APIを使うためには App Store Connectで設定が必要です App内課金や定期購読を使う場合は App Store Connectで Mac用に再設定してください 購入履歴をiOSとMacで共有する場合は Server側で同期処理を行いましょう

ゲームの場合は Game Centerのグループを使い Leaderboardや アチーブメントを共有します

マルチプレイの場合は Multiplayer Compatibilityを 更新してください そうすればiOSやMacの適切な版と 確実にマッチできます

ここで注意することがあります 当面の間 App Storeは uikitformacの更新を受け付けません プロダクトページは作れますし StoreKitやGameKitを 使うことは可能です 夏の間にアップロードの受け付けを 始めますので練習できますね Xcode 11のリリース後は レビューの投稿ができます

配信について説明しました

(拍手) App Storeを使わない 配信方法もあります 顧客に直接配信する方法で 開発者ID証明書で署名し Appleに認証される必要があります

認証はMacの進化で セキュリティも向上します Mac上で実行するアプリケーションは 開発者署名があり Appleに認証されたものになります

レビューがなくても 適切なポリシーが実施されているのです

署名や認証を行う コマンドラインツールも用意しました

TestFlightはMacで使えないので 認証はAppの共有にも役立ちます この方法で署名すると App Storeの機能は使えません GameKitやStoreKitです

署名や認証は すべてXcodeから実施可能です まずAppをアップロードします ここでXcodeは開発者ID認証を Appに付与し Appleはマルウェアをチェックします 数分後Xcodeは通知を受け取り アプリケーションを認証 アプリケーションのエクスポートや Zipで固めることができます

セキュリティモデルなどについて 更に知りたい方は 今年の“All About Notarization”を ご覧ください

配信オプションについて話しました 他の配信方法としては 開発署名があります

開発署名はiOSのものと同じで チーム内でのテストに適しています 新たなMacを使う時は デベロッパポータルでの登録を忘れずに

開発署名ではStoreKitと GameKit APIをテストしてください この時 Sandboxテスターアカウントが使えます 検証で課金する必要はありません

Macでの配信を説明しました

ご認識のとおり―

多くを話しました たくさんのことを学びましたね 皆さんは私と同様に iPhone開発者になり― テーブルビューなどを会得しました

そして次に取りかかったのが iPadアプリケーションです マルチタスクやDrag and Dropに 挑戦しました

次に手がけるのはMacです 画面のサイズ変更に取り組みました Macで何ができるか楽しみです Appの発展を楽しみましょう ぜひ挑戦してください 関連するセッションも聴講し WWDCをお楽しみください ありがとう (拍手)