iPadで複数のウインドウを使用する

(音楽) (拍手) こんにちは iOSのSystem UI（SpringBoard）チームの ケン･フェリーです 私とスティーブ　 そしてジェームスで iPadのマルチウィンドウについてお話しします まず概要です iOS 12以前だと このようなスイッチャーをスワイプし アプリケーションを選べます iOS 13では アプリケーションではなく ウィンドウが表示されます APIのシーンです

今日は これについて お話ししていきます これがあなたのAppにとってどんな意味を持つのか そして、あらゆる機能のすべてを紹介していきます まずはデザインの話 Appにマルチウィンドウを実装する際に 考慮することについてです 次にマルチウィンドウの使い方です　　　　　　　　　　　　 プログラミングモデルの最大の変更点である アプリケーションのライフサイクルから始めます フォアグラウンド バックグラウンドや アクティブの話です ドラッグ＆ドロップの話もします 大抵はこのやり方でウィンドウを作ります それからジェームズが 話してくれるのは Appを良いマルチウィンドウAppにするたに 採用できる次のステップについてです

まずは3つのデザインの問題から始めましょう このウィンドウ またはシーンは 一体何なのでしょう？ ここでのポイントは２つです アプリケーションをマルチウィンドウに 対応させる意義があるかと どんな画面になるかということです どんな動きをし ユーザはどう受け取るか？ AppleのAppの例を見て ご自身の場合と照らし合わせてください まずは Safariです Safariにはマルチタスク機能が すでに存在しています iOS 12のSplit Viewのスクリーンショットです Safariがすでに分割画面をサポートしています iOS 13やiPadOSでは こうなります あまり違いはありません Safariではこの機能はとても重要だったので 残りのOS全体に適用する前に導入したのです

一般化するために 考えるべき ポイントは何でしょう？

まずはSafariには １種類しかウィンドウがないことです それぞれはインターフェイスの複製で それぞれがAppで全てのことをこなします これが重要なのは iPadでユーザは １つの画面から 何でも行うことが可能であるべきだからです 必要ならば 複数の画面が表示可能であるべきです 逆にアプリケーションが動作するために 複数の画面を必要するとしたら 何かが間違っています 常に複製のように 同じ画面である必要はありませんが ユーザーが作成する最初の画面で すべてをできるようにするのは大事なことです

このケースではすべてが同じで　AppleのAppでも ほとんどがこのケースと同じです 一番簡単にできる正しいことです あとで例を見ます システムワイドでのサポートを 導入したため Safariでの機能も向上しました 一方の画面を消して 他のことに集中することもできます すごいでしょう？

次にドキュメントベースAppです

これはPagesです ユーザはどの ドキュメントベースAppでも 複数のドキュメントを 同時に見たいと思います これをサポートする必要があります けれども 画面の左上を見て 驚くかもしれません 各ウィンドウの上に “ドキュメント”ボタンがあります どちらもフルブラウザなのです Safariの場合と同様 今見ているドキュメントから 別のドキュメントに戻ることができます Pagesには1種類のウィンドウしか無いのです

すべてのドキュメントベースAppで必要 というわけではないと思いますが ここでは意義があります 逆のケースも見ていきます

マップの例です ウィンドウは１種類だけです ここでもお話ししたいのは アプリケーションをマルチウィンドウに 対応させる意義です 一見マップは マルチウィンドウにする 必要はなさそうです 行き先を調べたら 閉じるだけですから しかし 実際はそうではありません 食事に行って その後ショーに行く予定を立てていたら ２つのウィンドウで違う道順を見られるのは とても便利です 前の道順を消さずに 調べたり 変えたりできるんです

マップにだけ適応する話のようですが　　　　　　　　　　　　　 他のAppでもこうしたことはいつも見つかりました マルチウィンドウが必要か 不確かな場合でも いつも必要という結論に達しました マルチウィンドウを必要とした例を お見せします ご自身のAppの場合を考えながら聞いてください

マルチウィンドウシステムを使用しているので　　　　　　　　　 何か一つに、例えばディナーの場所にフォーカスしたい場合 スペースを並べ替えてメモを取り出して これは１つのアプリケーションだけでは できないことです

さて メールは 異なる種類のウィンドウがあるケースです

クレッグがKeynoteで見せたように 今までと同じように 返信用のモデルインターフェイスを別に開きます もしくは返信しなければならない画面を Slide Overで開いて積み重ね ToDoリストのようにも使えます この場合でも― 画面の上には“送信”と “キャンセル”ボタンがあります けれど ここから受信トレイに戻って 他のメールを見たりといったことはできません

これらは専用のウィンドウなのです そして これらのボタンを押すとウィンドウは閉じられます クレッグがkeynoteで送信の仕方をお見せしたので ここでは消し方をお教えしましょう タップで複数表示を閉じて 1つのウィンドウだけを表示させて “キャンセル”を押すと こうなります このような動作は 皆さんのアプリケーションでも利用できます

メッセージにも違う種類のウィンドウがあります ただのToDoとは違います 他のケースのように ただのトランザクションや アクションではありません あるスレッドを引っ張ってきて　 ウィンドウにすると そのスレッドだけが表示される 専用のウィンドウになります 使い終わったら “終了”ボタンを押します

最適化するためのツールみたいなものですが 非常に便利なツールです

マルチウィンドウ対応は必要かという 問題に戻ります マルチウィンドウのメッセージは とても便利だと思います 一つの会話の過去のやり取りの内容を 別のウィンドウで 他の人に伝えられます 更に質問されても その都度 戻る必要はありません 一方で何かを参照しながら 他方で別のことができる それが最も基本の原理です

最後に カレンダーを取り上げましょう カレンダーにはイベント用に ドラッグ＆ドロップの機能が すでにあります

ですが マルチウィンドウにすると 例えば 違う週を同時に見られ 別の週へも 予定が移動できるのです そのための特別な設定は 必要ありません Appをマルチウィンドウに対応させることで ドラッグ＆ドロップに対応すれば 両方の機能を一緒に働かせることで パワーを拡大できます どのAppでもある程度 構造がしっかりしていれば マルチウィンドウの恩恵が 受けられると思います あなたのAppはどうかということに 完全に答えることはできませんが 今挙げた例が　自身のケースでは何が使えるかを 考える助けになればと思います

次のトピックに移る前に 今年 iPad Appを Macに持っていく話をしました Macでは複数のウィンドウを扱えるのに このAPIなしでは新しいウィンドウを作れませんでした でも今はできますので ぜひやってみてください

iPadにおける複数ウィンドウの 意義の話はこれで終わります 次にまたデザインの話ですが ユーザが新しいウィンドウを 作る時の操作についてです

最初にシステムが提供する方法で、Appでの実装は不要です 例を見ながら紹介します そして既にある機能をもとに ユーザが期待する操作を見ていきましょう すでにクレッグが話しましたが App Exposeの右上に 新規ウィンドウを開くボタンがあります これは変更なしで入手できる機能です マルチウィンドウに対応させれば 使えます

この機能の他には あと1つだけ すべてのアプリケーションに対応するものがありますが この機能がすべての基礎になります 今 開いているアプリケーションの アイコンを端へドラッグします これは“もう１つのウィンドウをここに開く” という明確な指示になり 動作に必要なコンテキストが揃い 新しいウィンドウを開きます

でも例えば ユーザーがSafari内のタブを ドラッグしてきたらどうでしょう ユーザーは新規ウィンドウが開くことを期待しますが システムはそれをやってくれません　 それを行うAPIを呼ぶのはー 大変ではありませんが 対応作業は必要となります そしてこれは すべてのドラッグ＆ドロップ機能に 及ぶことだと推測できます ユーザーがピックした何かを新しいウィンドウで開きたいと思ったら　　　　　 それができることを期待するのです その期待に応えるべきです

最も一般的な例は メールの主画面を開いている時です 左手にテーブルビューがあり 各セルは1つ1つのメッセージを表します セルの一つをタップしたら そのメール全体が見れますよね ユーザはラッグ＆ドロップで新しいウィンドウが開くことを期待します

ほとんどがドラッグ＆ドロップですが 明示的なアクションでウィンドウを作成することもできます Safariや他のアプリケーションで リンクを長押しするのです “新しいウィンドウで開く”と メッセージが表示されます メッセージを押すと 新しい画面が開きます

いつでも呼び出せる新しいウィンドウを開く UIKitのAPIがあるという事です 音声認識など 指示の仕方は他にもたくさんあります クシャミをしたら クシャミを分析するための新しいウィンドウが開くとか ちょうどShazamのようにです

そんなことも可能ですが まあ やめておきましょう でも 面白そうですけどね

前に言った様に 自動的に新しいウィンドウを開くのではなく ユーザーの指示で開くべきです 新しいウィンドウを開くことを ユーザーが明確に認識できる必要があります この“新しいウィンドウで開く”のようにね それを各アプリケーションで 設定しなければなりません

デザインについては これくらいです どのように対応させるかという話を スティーヴ･ホルトがします

(拍手) どうも

UIKitチームの スティーヴ･ホルトです 皆さんは この新機能の 例の数々をご覧になって どうやって導入すればいいのかと 思われたでしょう その説明をしていきます これらの新機能を使用するにあたって iOSとiPadOSで必要になる２つのクラスがあります UIWindowSceneと UISceneSessionです

UIKit内のUIの構造はご存じでしょう スクリーンがあり ウィンドウか マルチウィンドウがあり ウィンドウの中にはビューが ビューコントローラーと並んであります UIWindowSceneはスクリーンと ウィンドウの間に入ります アプリケーションや UIの構造をあまり変えずに ウィンドウが 一つのインスタンスを 含めるようになります

つまり あなたのUIが含まれるシーンを 要求に応じてシステムが作るのです ユーザがドラッグ＆ドロップや AppのUIから新しいウィンドウを 開くことを要求すると システムはUIをスクリーンに 表示する様要求します シーンがバックグラウンドになり インタラクティブでなくなると システムがその状況を判断し 不要になったシーンを削除してくれます シーンは消されますが 使っていたアプリケーションは まだ Appスイッチャーにあると ユーザは当然思います

スイッチャーに何があるのか 把握する必要があります サスペンドされたAppが表示していた インターフェースに依存せずにです そこでSceneSessionの登場です

SceneSessionは ユーザーがアプリケーションでで操作した インターフェイスの 最後の状況を保持しています

これらは明確なシステムの役割を 持っています デバイス上や外部ディスプレイで 行うインタラクションの 標準的なアプリケーションの インターフェイスなのです

システム上で新しいウィンドウが 開くたびに アプリケーションはApplicationDelegateを通して 新規セッションの知らせを受けます そしてユーザーがウィンドウを消す度にー APIを通してか、スイッチャーで消した場合ー セッションが消されたことが通知されます 前のスライドで見た UIのシーンは アプリケーションのライフタイムを通して セッションに接続したり切断したりします

これは皆さんもお気付きの通り アプリケーションのライフサイクルに興味深い影響を与えます

分かりやすくグラフにしてみました

このアプリケーションは 3つのセッションを持っています インターフェースを表示する別々のスペースを システム中に３つ持っているのです 今は接続が切れていますので　 バックグラウンドです アプリケーションのステータスは バックグラウンドとレポートされます

そこで１つのセッションを起動すると

ステートが接続されたシーンと一緒に アクティブなフォアグラウンドまで上っていきます シーンをバックグラウンドに戻すと アプリケーションのステータスがシーンと共に下がります 他の2つのセッションのうちの 一つに切り替えたとしたら アプリケーションのステータスは フォアグラウンドアクティブに留まり アプリケーション全体のステートは 変わっていないことを表します

アプリケーションのクラスと デリゲートクラスに関して 今までは 残りのシステムの インターフェイスと組み合わせて ApplicationDelegateと Applicatonオブジェクトを使いました これはもう あまりよく機能しなくなりました そのため これを分けました

アプリケーションは前と変わらず システムプロセスの状態を表します ApplicationDelegateは プロセスの起動 終了などの イベントとデリゲート通知を扱います しかし シーンは UIステータスを 全部カプセル化します ステータスバーが行っていたことは 今度はシーンが行います

SceneDelegateに特定の状況で URLを開いたことが通知されます

バックグラウンドや フォアグラウンドへの行き来などです そして 永続的なUIのステータスを表す SceneSessionがあります

複雑なAPIだと思うかもしれません 現在 このようなコードを使っていれば 実装メソッドを 大きく変える必要があります このようにです

出来るだけ以前と同じにしました applicationの "didFinishLaunching“ は ”willConnectTo”に “EnterForeground”はそのままで applicationからsceneに変わっただけです

さて State Restorationで 障害となるものがあります　とても重要なことです ユーザーがスイッチャーのステータスを確認したり あるスペースに行った時- 去った時そのままの情報を 取り戻せるようにするのです それを可能にするため HandoffからAPIを借りてきました そして State Restorationを NSUserActivityで表すことにしました どんな情報でも ライフサイクルのどの段階でも SceneDelegateからリクエストできます リストアを行う時 接続デリゲートのコールバックとして 引き渡します

そのセッションのシーンが もう存在しなくても stateRestorationActivityに 直接アクセスできます バックグラウンドでフェッチを行い セッションをアップデートする必要がある場合 変更するべきデータを 見つけることができるのです

デモンストレーションをしましょう このAPIを導入するのが どんな感じかお見せします

ここに―

同僚のジョンが作った アプリケーションがあります 僕のお気に入りの アプリケーションの１つです もうすぐ起動します

シミュレータが立ち上がったら

CollectionViewFlowLayoutのすべてを取り入れた 見事なギャラリーAppをお見せできます

重要な点も ご紹介します 魅力的なアプリケーションです アプリケーションの１つの例から マルチウィンドウを出しましょう

このアプリケーションを使うと 同時に複数の写真を見たくなります

もう少々お待ちください お待たせしました (拍手) 立ち上がりました

すばらしいアプリケーションです 見たい写真を選んで すぐに一覧に戻れます

App Exposeが 使えないのは マルチウィンドウの機能を 備えていないからです

実装するためには―

まずXcodeを使います

Generalのタブの下― “Supports multiple windows”を チェックします すると どうなるか？

info.plistが編集されます

確認してみます Application Scene Manifestが エントリーされています これは アプリケーションがサポートするシステムが 新しいライフサイクルのインターフェイスを サポートすることを意味します どの役割ための どのインターフェイスを使用するか 静的に宣言することができます 今回は事前にエントリーを済ませたので これは削除します

そしてこれを使います

これが事前に作成したものです

既存のStoryboardは移動されています 基本的なSceneDelegateのクラスが 1つのウィンドウを宣言します 基本的なテンプレートのクラスです

動かしてみましょう

最初に戻りました いいですね

しかし―

もしここで Dockのアイコンに アクセスできたとしたら ドラッグしてiPadのインターファイスの横に 新しいウィンドウを作成できるはずです info.plistが許可しているので でも もしホーム画面に戻って

アプリケーションを閉じて 再起動しても

ご覧のように　以前と同じレベルの State Restorationを得ることができません　

取り戻すために

いくつか実装しましょう

state restorationを実装するには 既存のstateRestorationActivityを 持ってきます

ウィンドウはシーンの新しいstateRestoration Activityであるデリゲートコールからこれを返します

実装の深いところに設定された アプリケーションインスタンスは もう必要ありません

ローカルのウィンドウシーンに 組み込みます

前と同じところを取り除きます

stateRestorationを実行するため ユーザーアクティビティに戻ります 試してみます

まだstate restorationが 実装されていません シーンが接続する時に もう１つ 手を加えます

シーンがSceneSessionと接続する時 オプションとセッションレファレンスが得られます 今お見せしているテンプレートの中で Handoffや他のシステムを通して得た- ユーザーアクティビティを探してください

これらのアクティビティを優先したいのは 実際にユーザーが行ったことだからです

しかし―

stateRestorationActivity は特別で セッション上にあります ユーザアクティビティがなければ stateRestorationActivityを使います ビルドをして実行すると

アプリケーションが 再起動した時に戻ります

以上がアプリケーションに マルチウィンドウを設定する方法です 既存のアプリケーションデリゲートロジックを使い シーンへ動かせば 実行できます

さて ケンがお話ししたように 推奨されるインターファイスの方法は アイテムをドラッグ＆ドロップすることです

いくつか解決策を ご紹介します アプリケーションがinfo.plist上で 既存のユニバーサルリンクを使用するか- ファイルURLを参照することを 宣言していれば 問題なく動作します さらにカスタマイズしたいのであれば

NSUserActivityを使います DragItemのNSItemProviderに 違うオブジェクト表現として含められます これを残りのシステムへドラッグして放せば システムが定義した場所で- ターゲットとドロップポイントに当たります ちょうど他のAppのアイコンドラッグのようにです

このあとはジェームズがお話しします

ありがとうございました (拍手) ありがとう

話をまとめるために あと３つお話しします まずUISceneSession APIを詳しく見ます 次にインターフェイスを複製する際に よく発生する問題を紹介します 最後に この新しいライフサイクルに対応するため 廃止(deprecate)が宣言されたUIApplicationについて 手短に話します まずSceneSessionとは何か について話しましょう

冒頭の図に戻ります Appスイッチャーに アプリケーションの ４つのウィンドウがあります ユーザはこれを 4つのウィンドウと見なしますが 開発者の皆さんはシーンや SceneSessionと思ってください この違いは大切です ユーザが目にするのは スナップショットだからです シーンはアプリケーションに ロードされていないかもしれません

ウィンドウは現れたり消えたりします しかしセッションはいつでもそこにあるので ウィンドウのプログラム制御に 使われます

これは今年 マルチタスク機能に加えられた APIのうち最もワクワクするものでしょう プログラムで新しいウィンドウを作成したり Appスイッチャーのスナップショットを アップデートしたり ユーザの操作や ドキュメントの期限により ウィンドウを閉じたりといったことが できるようになります いつ どんな方法で使うのか サンプルコードを見てみましょう

まずはrequestSceneSessionActivation APIです 既存もしくは新たな アプリケーションのシーンを提示します 例えばドキュメントを開くとします アプリケーションのどこかに 既存のシーンがある場合 APIに渡せば提示されます ドキュメントが未開封なら あとで開くために NSUserActivityを作成できます 新しいシーンを作るために nilを渡します

次はrequestSceneSessionRefresh APIです 新着メッセージのプッシュ通知や カレンダーのイベントの変更に このAPIを使うと便利です このメソッドを呼び出すとUIKitが アップデートをスケジュールします バックグラウンドでシーンが接続される 未来のある時点にです UIがアップデートされ スナップショットが Appスイッチャーに保存されます スティーブがお話しした stateRestorationの アップデートにもこれを使うことができます

最後はrequestSceneSessionDestruction APIです シーンを閉じるのに使います これの凄いところは オプションのオブジェクトも付いていて シーンの閉じ方に合わせ セマンティックなアニメーションを選べます メールではメッセージを送るとき シートがアニメ化して 画面から消え去ります 下書きとして保存すると それをリマインドするため スライドダウンします 同じアニメーションを シーンや Appにも使えます

セッションはウィンドウの管理以外に ご覧のように 状態のリストアも 行えるようになりました たくさんのAppにとって 特にHandoffなどの テクノロジーをすでに使っているものなら 簡単に状態を保存できるようになります

しかし既存のState Restorationロジックを 備えたAppと NSUserActivityを 統合することを望まないかもしれません それにはpersistentIdentifier プロパティが役立ちます すべてシステムにより 作られた文字列です State Restorationに使う データベースやファイルに 自由に書き込んで構いません Appを起動するたびに 同じシーンに 同じ識別子が使われます バックアップや デバイスの復元にもです

終わりに userInfo Dictionaryを 紹介します シーンごとのカスタマイズなど 少量のデータを保存するのに便利です サイドバーの表示や インクピッカーで 最後に使った色などを保存できます 何が適しているかを見つける良い方法は　 すでにユーザデフォルトに保存している データを調べてみることです App全体で包括的に保存するには 適していないものもあるからです

以上がUISceneSessionの 新しいAPIです Xcodeでマルチシーンをサポートして ビルドと実行をした後 次は何をすべきか お話しします それはデバッグです カスタマイズされたAppには コードがたくさんあります フレームワークがサポートするよう 努めていますが 変更の必要があるかどうか また その内容を完璧に予測することはできません でも 多分あると思います 過去に書いたコードを 思い浮かべてみてください この新しいライフサイクル 特にマルチシーンが 想定していたアプリケーションの機能を どのように変えることになったでしょう インターフェイスも ビューコントローラーの インスタンスも １つだけではないのです

テストを自動化しているなら 素晴らしいです しかしバグがテストに 引っかからないかもしれません それは想定に対して加えた変更のせいです 問題を見つける１番の方法は アプリケーションを使ってみること ２つのコピーを同時に使ってみるのが 意図していたのと違う点を素早く見つける 良い方法です

2つの事例をもとに 典型的なバグを見てみましょう 双方ともステートが共有された事によって 問題が発生しています さて よく使われるクラスを 並べてみました これらは一般的で実用的な Cocoaのクラスで 便利なシングルトンのプロパティです Appの深部にあるモデルオブジェクトに入って UIデバイスのシングルトンまでたどり 実行中のデバイスの設定を読むのは 効果があります しかし これにも問題はあります レイヤーとデータが疎結合だと データがアプリケーションのどこを流れているのか見失いがちです 誰がどうやって読み取っているのか しかし扱いやすいので有効な方法です 皆さんはシングルトンを 書いた経験があるでしょう グローバル変数のようなシングルトンとは 違うものを使っているか- キットの既存のシングルトンに 便乗してるかもしれません もしくはファイルシステムを使っているかもしれません これは それ自体がAppがシェアする1つの大きなデータ保管庫のようなものです シングルトンや共有される状態が 悪いと言っているわけではありません シェアの方法や必要性について 考えてみることをお勧めしたいのです データを整理すると ユニットテスト時間の軽減など 多くの利点が生まれます

例を見ましょう まずはState Restorationから サンプルのアプリケーションを使い 見ていきます スケッチパッドの編集ソフトです タイプしたテキストは 再起動しても見れます デモに従い マルチスクリーンを埋め込みました なかなかいい感じです 再起動すると こうなります 残念ながら両方に同じ内容が 表示されます 思っていたのと違います データベースを見たら 原因が分かりました テキストファイルを Appコンテナの同じ所に 保存していました つまり片方を保存すると もう１つも上書きされます 私のAppのコードなので UIKitが 何も変更せずにできることはありません そこで２つの処理をします シーンのセッションの永続的な識別子を 正しいシーンと関連付け ファイルを複数保存するため ロジックをアップデートします

このようにマニュアルで State Restorationをしたら データをクリーンアップしましょう UIKitがNSUserActivityを 管理する場合は データを削除したら 書き込みする場所を処理してくれます しかしAppのシーンのライフタイムに関連付いた 大きなファイルを受信する場合は 新しい didDiscardSceneSessions APIを 使ってクリーンアップしてください sceneSessionと一緒にコールされ 不要なデータを 取り除くことができるのです Pagesなど ドキュメントベースの Appの場合 ドキュメントは ファイルシステムに保存されます でも構成や設定はもう必要ありません Appが起動している時にユーザーが シーンをAppスイッチャーでスワイプすれば このメソッドが すぐに呼び出されます もしくは再起動の後のある時点で マルチセッションのセットを受け取ります

次はUserDefaultsです これも一般的で便利な アプリケーションクラスです 設定の保存に便利で 実際に今も使っています 字数を数えるカウントバーは トグルをオンにすると表示されます しかし ビューコントローラーの設定が 見えている方にしかトグルがありません 両方のウィンドウに表示させたいし すべてのアプリケーションで使いたい 問題の原因を探りました ビューコントローラーと 設定ビューコントローラーのデリゲートがあります 設定の変更をデリゲートに伝えると テキストエディタビューコントローラーが UIをアップデートします 自己完結型のプロセスです このアプリケーションの2つ目のシーンには どんな変更も知らされないのです

Key-Value Observingを使うのが 洗練された解決方法です ステップは２つ まず extensionを使って UserDefaults上にプロパティを定義し Key-Value Observing用の Key Pathを得ます isInforBarHidden: ブーリアン プロパティを UserDefaults上にある Getメソッドと Setメソッドに実装します 次にビューコントローラーを見ます 標準のUserDefaultsに 監視機能を登録しました extensionで定義したKey Pathと 値が変化するたびに 実行したいワークをカプセル化する changeHandlerがあります

更に重要なのは この登録に 初期のオプションを渡したので 設定した時に changeHandlerを 変更なしに1度呼び出すので コードを複製する必要はなく ビューがロードされて アップデートを受け取るたびに 1つのメソッドを呼び出すのを覚えておく必要もありません 今表示されているかどうかに関わらす 1つの真のソースだけがあります これでAppのインターフェイスの 一貫性が保たれます

これで完了です

あなたのアプリケーションについて考えるときの 少しでも参考になれば幸いです アプリケーションでベストプラクティスを実行しているなら 今見てきたようなことの いくつかをすでに取り入れていて 何も変更する必要はないかもしれません

廃止(deprecate)が宣言されたUIApplicationについて もお話ししたいと思います UIのステートと プロセスのライフサイクルは UIApplicationDelegateとは 別扱いにしました UIApplicationとも分けました アプリケーションのマルチシーンを 一度に表示して 1つは明るいステータスバー もう1つは暗いステータスバーにすることもできます バリューを1つだけ返すのは 不適当です なので UIApplication上の これらのプロパティを廃止(deprecate)し ウィンドウシーンの 新しいプロパティを追加しました

マルチウィンドウを使う予定がなくても 新しいプロパティを採用することをお勧めします 今後 もしマルチウィンドウを使いたい時の 役に立つでしょう

最後に話を振り返ってみます ケンが 新たにマルチタスク機能に 加わった便利な機能を 自身のアプリケーションで使用している ところを想像するお手伝いをしました とても便利な機能なので 今後は当然の機能として ユーザーから期待されるでしょう ぜひ採用してください

既存のアプリケーションでも 採用しやすいAPIです また新しいアプリケーションでは これがベストプラクティスです このUIシーンのライフサイクルを使ったものが 新しいXcodeプロジェクトの デフォルトテンプレートにもなります

ライフサイクルを変えると 問題が起こるかもしれませんが ほとんどが簡単に対処できます 前回のWWDCでお話しした ベストプラクティスを含めてです

廃止(deprecate)が宣言された UIApplicationを取り除き UIWindowSceneを使用してください iOS 13やiPadOSでは これらはいつでも使えます マルチウィンドウを採用する必要もありません

マルチタスク機能の詳細は 別のセッションでお話しします マルチタスク機能の ラボも開催する予定です

本日はありがとうございました (拍手)