Background Assetsの新機能

♪ ♪

「Background Assetsの新機能」 へようこそ ソフトウェアエンジニアのJaredです Background Assetsの新機能について お話しします この一年で幾つか変更がありましたが 去年の私のセッションも ぜひご確認ください このセッションの元となる 詳細情報があります ここではBackground Assetsの 概要を説明し なぜアプリに採用すべきかお話しします そして今年の新機能をご紹介します お見せするのが楽しみな まったく新しい機能もあります そしてダウンロード可能な Background Assetsの サンプルをご紹介し この技術の適用が アプリのユーザー体験を どう向上するかをご説明します またApp Extensionのデバッグについて 詳しくお話しします ではBackground Assetsの概要を 簡単にお話ししましょう

Background Assetsの一番の目的は 待ち時間の削減です ユーザーはアプリを起動して ダウンロードを待つのを嫌います Background Assetsはフレームワークと App Extensionでこの問題を解決します この新技術はmacOS Venturaと共に iOS 16.1で登場しました CDNプロバイダかサーバで アプリのコンテンツのダウンロードを サポートします 例えばアプリのインストール時や アプリの更新時 もしくは不使用時に定期的に コンテンツをフェッチするのです App Extensionでアプリの不使用時に 実行するコードを書くことができます この技術はmacOSとiOSと iPadOSでサポートされ 好きなプラットフォームで使用できるのです Background Assetsの特徴は アプリを起動する前から Extensionを実行できることです アプリがインストールされ次第 アセットをフェッチできるのです またExtensionは定期的に バックグラウンドで起動され ユーザーがアプリを起動した時に 既に新しいアセットが使用できるのです またアプリの非動作時に ダウンロードを手助けします 例えばダウンロードが完了すると Extensionが起動しファイルを最終点に 移動させることができます ただしExtensionのランタイムは 限られています これはデバイスの電力と パフォーマンスを最適化するためです 詳細は後ほどお話しします またみなさんが開発するExtensionは 特別なサンドボックス内に収納されます これはBackground Assetsでの コンテンツ管理を保証するためです もしサンドボックスに その機能及びAPIがない場合 Feedback Assistantでご連絡ください 3つのシステムイベントで App Extensionは起動されます アプリのインストールと更新時と 定期的なバックグラウンドでの起動です ではこのサイクルを見てみましょう

Extensionのライフサイクルは App Storeでのインストールか デバイスでの更新で始まります システムサービスに通知され アプリの起動を防ぎます アプリバンドルを点検し Info.plistを読み BAManifestURLキーを探します そのキーが参照する マニフェストをダウンロードし App Storeにその進行状況を報告します ダウンロードが済むと インストール及び更新の コンテンツリクエストを システムが発行します コンテンツリクエストには マニフェストへのパスが含まれ Extensionはそれを使いURLや ファイルサイズやアセットの ダウンロードスケジュールを決定します どのアセットをダウンロードするか決まれば それらのダウンロードを BADownloadsとして返します システムはApp Extensionを 停止か終結させ デバイスの電力と パフォーマンスを節約します そしてダウンロードが始まり それが完了すれば Extensionに知らされます

定期的なコンテンツリクエストは インストール時とほぼ同じで 唯一の違いはそのタイミングを デバイスが決定します その決定はユーザーの 使用状況で決まります 低電力モードや バックグラウンド更新 どれだけアプリを起動するかなどが 考慮されます ではExtensionがいつ 定期的に実行されるか その決定に貢献する要素を見てみます

デバイスのパフォーマンスと 電力使用が重要なため Extensionのランタイムに 制限が設けられています これにはExtensionのメモリ使用量も 含まれています Extensionがメモリ設定値を超えると システムにより遮断されます ですので大きいファイルには メモリマッピングをご検討ください ストレージがサポートする メモリマップデータは この制限には含まれません

アプリがインストールされると 一日に数分のランタイムが デフォルトで割り当てられます 十分には思えませんが 適切にデザインされたExtensionには 十分な時間です また使用状況でランタイムが変わります あまり使用されないアプリなら Extensionの実行が システムにより削減されます 例えば滅多に使われないアプリは ランタイムが非常に制限され よく使われるものには時間が与えられます

BADownloaderExtension プロトコルはExtensionの エントリーポイントの関数を定義します システムに関数が呼び出されると ランタイムが始まり 関数がそのスコープを出ると ランタイムが止まります 関数がスコープを出たり ランタイムを使い切ると システムはExtensionを停止か終結します 後に例をお見せします

しかしランタイムを 管理する関数スコープに例外があります もし非同期排他制御APIが呼び出された場合 完了ハンドラが呼び出され返されるまで Extensionは実行し続けます ユーザーがExtensionのランタイムを 管理できる場合もあります 例えばデバイスが低電力モードの場合や デバイス全体であれ個々のアプリであれ バックグラウンド更新が無効なら Extensionは実行されません 先程 Extensionのランタイムは 関数スコープで決まると言いました それを理解するため例を見てみましょう

バックグラウンドダウンロードを 管理するExtension インターフェイスのコードです BADownloaderExtensionプロトコルは システムが Extensionに実行する関数を定義します このプロトコルに準拠するため 必須の関数を追加しましょう Downloads for request関数は Extensionへの主要な エントリーポイントの一つで BAContentRequestはその呼び出しが アプリのインストール時か更新時か バックグラウンドでの 定期的なものかを定義します manifestURL引数は Extensionが呼び出される前に ダウンロードされたファイルへの パスを提供します マニフェストファイルは 現在ダウンロード中のものと サーバにあるダウンロード可能なものの 比較に使用されます 関数定義の戻り値の型は BADownloadに準拠する ダウンロードオブジェクトを要し この関数のリクエストの返答には 関数がスコープを出る前に ダウンロードが必要なコンテンツを 同期的に戻す必要があります しかしこの不自然な例で parseManifestという 関数を呼び出すことにします この関数はマニフェストを読み ダウンロードが必要な BADownloadオブジェクトを返します

しかしparseManifest関数の 実行が不十分で ダウンロードの解析と構成に 30分かかるとします その場合Extensionの ランタイムを大幅に超え Extensionは終了させられます Downloads for request関数が 呼び出された瞬間から スコープを出て戻されるまでの間で Extensionランタイムが 計算されることを 忘れないようにしてください では別の問題例を見てみましょう

BADownloaderExtensionプロトコルの 関数がスコープ外に出ると Extensionは中止され 終了されるかもしれません 変更中プロトコルが どの関数も定義しないのには 理由があります Extensionが終了すると どのインスタンス変数も メモリ内の状態も保存されません Extensionの状態維持が必要なら 状態をディスクにシリアライズすべきです 次にダウンロード管理にExtensionと アプリの両方から使用するAPIについてです フレームワーク内の ダウンロードマネージャは Background Assetsシステムサービスとの プライマリな通信方法で アプリを通し使用される シングルトンオブジェクトです バックグラウンドでの アセットダウンロードを スケジュールし 予定済みのダウンロードを フォアグラウンドに押し出します また先程話に出たように アプリの起動前に Extensionにスケジュールされた 現在進行中のダウンロードを 管理することもできます またアプリとExtensionが 同時によく似たオペレーションを 実行していないか確かめる 同期メカニズムもあります 最後にダウンロードマネージャには BADownloaderExtensionプロトコルに似た ダウンロードに関する コールバックを受けるデリゲートがあります もしBADownloadManagerに デリゲートを登録すると Extensionの代わりに コールバックを受け取ります これはアプリが動作中に ダウンロードを管理でき便利です ダウンロードの管理を おさらいしたところで 既にデバイスにあるファイルを どう管理するかお話ししましょう

Background Assetsでダウンロードした ファイルはすべてパージ可能と示され 危機的状況下ではシステムにより 消去されることを意味します システムセキュリティアップデートや 子供の第一歩の録画たど 考えてみてください

しかしアセットを変更したり拡張すると システムに追跡されなくなり パージが不可能になります アセットの変更やデータの抽出には 十分に気を付けてください アセットを間違って管理すると デバイスのバックアップのサイズが増えたり 重要なセキュリティ更新を ダウンロードできなくなります アセットはキャッシュディレクトリに 保存すべきです そうすれば危機的状況下で パージが可能になります すべての機能をおさらいしたところで Background Assetsの 今年の新機能をご紹介します

今年初め アプリが インストール中か更新中に コンテンツをフェッチできる 必須ダウンロードを導入しました つまりダウンロードがiOSホーム画面や LaunchpadそしてApp Storeに 完全に統合されるのです ユーザーにはアセットのダウンロードが アプリがまだApp Storeから ダウンロードされているように見えます つまりユーザーは 必須ダウンロードの最中に アプリを起動できず インストールのキャンセルか 一時停止しかできません 一時停止がサポートされるため 続行が可能になるよう サーバはHTTPレンジをサポートすべきです アプリのインストール時に起こる 必須ダウンロードはほかより優先されます 見てみましょう すべてはアプリがApp Storeか TestFlightでリクエストされて始まります アプリのInfo.plistに essentialアセットキーがあれば 進行はデバイス上で設定され このフローを従います ダウンロードとインストールが済めば コンテンツリクエストで システムがExtensionを起こします これにはリクエストが アプリのインストールか 更新か定期的フェッチかが含まれます この時にマニフェストのダウンロードのため 認証チャレンジが送られるかもしれません Extensionは必須なものと 必須でないダウンロードの 組み合わせを供給します 追記ですがExtensionがダウンロードを 素早く供給せねばダウンロード進行状況が この関数が戻るまで フリーズのように見えます

Extensionがダウンロードを供給次第 必須ダウンロードが直ちに始まります この時にExtensionは更なる 認証チャレンジを受け取るかもしれません 必須ダウンロードが終われば Extensionは終了され ユーザーはアプリを 起動できるようになります そしてExtensionは成功及び不成功の ダウンロードを受け取ります 不成功のダウンロードがあれば BADownloadManagerで必須ではない ものとして再エンキューできます Extensionが必須ダウンロードの 終了メッセージを受け システムは直ちに必須ではないアセットの ダウンロードを始めます 必須ではないダウンロードは ダウンロードが終われば Extensionに送られます ではiOSホーム画面で 必須ダウンロードが App Storeインストール進捗状況に どう統合されるか見てみましょう プログレスインジケータは ベースアプリをダウンロードする時間 インストールの時間 そして必須アセットを ダウンロードする時間に分けられています アプリのInfo.plistで定義される BAEssentialDownloadAllowanceキーが 最初の全体的プログレスインジケータの 設定に使用されます そしてcontentForRequestが Extensionに呼び込まれ Extensionaがダウンロードを返すと それぞれの必須ダウンロードの ファイルサイズが合計され 実際のダウンロード量が決定されます 予定したダウンロード量が 必須ダウンロードの 割当量より遥かに少なければ インジケータは早く動くかもしれません 必須ダウンロードの割り当て量を 実際のダウンロード量に近付け プログレスをスムーズにしましょう 大切なのは今お話ししたことはすべて ユーザーが無効にできます App Store設定ペインに アプリ内コンテンツを 無効にする項があります Background Assetsは無効になりませんが 必須アセットのダウンロードを妨げ アプリの起動前に Extensionが実行できなくなります そのため必須アセットはあくまで必須であり アプリの起動には 必要がないと考えるべきです ですのでアプリの起動時 必須アセットが デバイスにない状態でのフローを アプリは対処すべきです 必須アセットを使用する機能は iOS 16.4とmacOS Ventura 13.3の 一部としてこの春登場しました これらの新APIsは最小限で 既存のExtensionに 簡単に追加できます

必須ダウンロードを サポートする最初のAPIは BAURLDownloadの 新しいイニシャライザでした この機能をサポートするために 2つの引数が追加されました Essential引数はその名前の通り ダウンロードを 必須と示すべきか特定し essentialはアプリのダウンロードと インストールに 貢献していることを意味します ファイルサイズ引数はダウンロードされる アセットのサイズです 必須ダウンロード作成時 ファイルサイズは正確でなくてはなりません アプリのインストールプログレスを デバイスに 正しく表示するためにこの情報が必要です ダウンロードするファイルが このファイルサイズと合わなければ ダウンロードがessentialと示されていれば ダウンロードは失敗します Extensionがファイルサイズを知らない場合 Extensionが起動される前に供給された BAManifestURLにファイルサイズが 含まれているはずです

もう一つのAPIはダウンロードを non-essentialと表現する 簡単な一行コードを供給します 必須ダウンロードのエンキューは contentForRequest関数内だけのため このAPIが多くのケースで役に立ちます 例えばネットワークの問題や ファイルが利用できず 必須ダウンロードの フェッチに失敗したとします その場合 Extension内の backgroundDownload failed関数で そのダウンロードのnon-essential表現を 簡単に作成し再エンキューできます バックグラウンドでダウンロードが始まり それが完了すればExtensionか アプリに通知されます 次にアプリのInfo.plistに 存在せねばならないキーを見てみます

昨年 これらのキーの詳細をご説明しました もし説明が必要なら そのセッションをご確認ください 大切なのはこれらのキーは Background Assetsを使用するだけでなく アプリをApp Storeに 提出するためにも必要になります 今年 必須アセットのサポートに 2つの新しいキーが必要です BAEssentialDownloadAllowanceと BAEssentialMaxInstallSizeです Essential download allowanceは バイトで表現され すべての必須アセットの ダウンロード総量の上限を定義します アプリのインストールでプログレスが スムーズであるよう エンキューする 必須アセットのサイズに 数値を近づけねばなりません もう一つのキー BAEssentialMaxInstallSizeは デバイスに抽出されたアセットの 最大サイズを表現します 必須アセットをインストール後 どれだけのストレージを使用するか この数字がApp Storeで表示されます 必須アセットの 新しいAPIについては以上です 既存アプリに必須アセットサポートを 最低限のコード変更で追加できます 実に簡単ですね ではお楽しみの時間です URLSessionを使う既存アプリを Background Assetsに 拡張してみましょう 今日お見せするアプリは WWDCセッションのビデオを デバイスにダウンロードし オフライン再生のため保管します 現在 ビデオをダウンロードする前に アプリを起動せねばなりません Background Assetsを採用し アプリの起動前に ビデオをダウンロードし この待ち時間を削除できます では見てみましょう これがそのアプリです

起動すると同時に ビデオのダウンロードが始まります 現在このアプリはサーバから WWDCセッションのリストを含む マニフェストをダウンロードします マニフェストがフェッチされ ビデオがダウンロードされ タップすると視聴可能になります Background Assetsを足すには何が必要か 見てみましょう Background Assets APIを使用する前に まず先程話した Info.plistキーを追加します これらのキーはアプリバンドルの Info.plistファイルに存在せねばなりません 次にBackground Download Extensionを足し アプリに組み込みます Extensionバンドル識別子が アプリのバンドル識別子で あることを確かめます App GroupはExtensionとアプリの アセット共有方法であるため アプリとExtensionが 共通のApp Groupであることを 確認してください 最後にアプリとExtensionが チーム識別子で 署名されているのを確認します これらを行えば Background Assetsの採用を開始できます

これはアプリのXcodeプロジェクトです 既にDownload Extensionを作成し アプリに組み込んであります 必要なInfo.plistキーも足してあります 準備ができたところで SessionManagerに行きましょう

このSessionManagerはURLSessionで 最新ダウンロードをフェッチしています URLSessionは素晴らしいAPIです マニフェストの フェッチに引き続き使用します しかしセッションのフェッチには Background Assetsに移行します これはこれから作るExtensionによって バックグラウンドでスケジュールされる アセットを アプリの起動時に フォアグラウンドに押し出せる機能を 利用するためです まずBackground Assets framework モジュールのインポートから始めます

下にスクロールして必要がなくなる URLSessionの 変数を取り除きます 次にstart downloadメソッドへ行きます ご覧の通り既存コードは URLSession download taskで ダウンロードを追っていました これはもう必要ありませんので 取り除きましょう ここから面白くなります Background Assetsでは Extensionとアプリが 同時に実行する可能性を考えねばなりません これを努力なく機能させるため withExclusiveControlで ほかのプロセスと相互排除が必要な作業を 可能にせねばなりません それを足してみましょう

ご覧のようにこのAPIは非同期で エスケープしています もしExtensionもこのAPIを使えば このクロージャ内に予定された作業は Extensionから独立して実行されます すぐにExtensionを実行しますが 今はアプリに注目します 相互排除的コンテンツで実行しているので download managerに 何かダウンロード中か尋ねます

既にExtensionがスケジュールしたなら やり直す必要はありません しかしダウンロード中のものがあれば 前に出すことができます

ダウンロードを前に出すことで ダウンロードの時間を著しく削減できます 今ユーザーがアプリを使用しているので ダウンロードを 素早くフェッチするチャンスです ユーザーが観たいはずです ダウンロードが存在しないなら こちらで作ります

ダウンロードを作るにしろ Extensionが実行したにしろ フォアグラウンドで始めることにします ダウンロードを バックグラウンドから前に移しても ダウンロードは再スタートせず 移行したところから続行されるだけです 次にBADownloadManagerDelegateを 実行しますが その前にURLSessionDelegateを削除します

古いデリゲートが消え Background Assetsデリゲートを作ります

SessionManagerが デリゲートに準拠するので それらのメッセージを 受け取れねばなりません そこでイニシャライザで結びつけます

BADownloadManagerは システムスケジューラと直接繋がるので シングルトンオブジェクトです このデリゲートが download managerにアタッチすると アプリが動作中なら Extensionではなくアプリが メッセージを受け取ります では実行が必要な関数に戻ります

このアプリではデリゲートプロトコルに これから実行する 3つの特定の関数があります まず一つ目はプログレスハンドリングです 実行してみましょう

盲目的にプログレスを更新する前に プログレスメッセージを 受け取るダウンロードを マニフェストが トラックしているか確認します もしそうなら アプリ内のヘルパー関数でSwuiftUIに 直接プログレスを送る updateDownloadProgressを呼び出します 次にダウンロード完了時についての実行です

これも同じように 予定される ダウンロードだけをハンドルします そしてreplaceItemAtでオブジェクトを Background Assetsが与えた 一時的な場所から 最終ロケーションへ移動します デバイスのスペースがなくなると システムはファイルをトラックし パージするため moveの使用で アプリがファイルの有無を確認し 必要であればそれを 再フェッチすることができます 最後にMainActorに対して タスクが引き起こされ stateはdownloadedと示され アプリがセッションの サムネイルをフェッチします すべてのダウンロードが 成功すれば幸いですが サーバにリソースがなかったり ネットワークの問題などで 失敗することもあります Background Assetsは再度試し ネットワークの問題を待ちますが 一定時間が過ぎれば ファイルは来ないと悟らねばなりません また前に押し出されたダウンロードは ネットワーク上の問題があれば ほぼ即座に失敗します アプリはインターフェイスの表示や 再スケジュールできますが この例では問題があったことを ログしましょう

デリゲートが完全に実行され アプリを再起動し見てみましょう

先程と変わりませんが それがこの目的でした Background AssetsをURLSessionと 置き換えるのは簡単です では次にbackground downloadの処理に App Extensionをどう実行するかです App Extensionを足すことで Background Assetsを利用し アプリのインストール 更新前に コンテンツをフェッチし 必須アセットをエンキューできます 本質的にアプリが停止中は Extensionに ダウンロードスケジュールの責任があります 見てみましょう このBackgroundDownloadHandlerは Background Assetsに関する extension内で メッセージを受け取ります Extensionから まず最初にロガーを作り Extensionが動作中 Console.appから見えるようにします

次にBADownloaderExtension プロトコルの一部である contentForRequest関数を実行します

このExtensionはまず起動される前に ダウンロードされたマニフェストを パースします そのマニフェストが無効の場合 Extensionはダウンロードの エンキューなしに設定されます マニフェストが有効だとわかれば App Groupにアトミックに保存されます これによりアプリとExtensionが 後に参照できる最新のマニフェストを ローカルで保持できます アトミックに保存されるため withExclusiveControlの使用は不要です そしてExtensionはスケジュールのため システムに戻す変更可能な ダウンロードオブジェクトを作成します 必須ダウンロードは アプリのインストールか 更新時にしかサポートされません そしてダウンロードされていない セッションを マニフェストを通して反復します スケジュールが必要なダウンロードに BAURLDownloadオブジェクトが作成され ユニークな識別子のURLRequestと ダウンロードが必須として フェッチされるべきかの注釈 ファイルサイズとアセットが ダウンロードされるApp Group そしてダウンロードの順序管理のため 相対的な優先権が与えられます 大切なのは必須と 示されたダウンロードに 正確なファイルサイズがなければ 失敗と示されることになります これはiOSホーム画面と macOS Launchpad及びApp Storeで スムーズなプログレスを サポートするためです ダウンロードのエンキューができ 次はダウンロードの処理についてです アプリが停止しているか BADownloadManagerに デリゲートがない場合 Extensionはダウンロードを実行します まずdownload finishedハンドラに 実行するのは exclusive controlを 非同期的に取得することです Exclusive controlの取得は 非同期であるため Extensionが供給した一時ファイルを キープする必要があります そのためにこの関数スコープを越えられる 一時的な場所にファイルを動かします またExtensionがダウンロードする Ephemeral Fileが 常にクリーンであるよう Swift deferを足します システムがファイルを削除しますが 自分で管理するのが最善です App Groupからマニフェストを 読み込み有効性を確認します Extensionはダウンロードした識別子が マニフェストにあるセッションと マッチするか確認します Extensionは Ephemeral Locationから App Group内の目的地に ファイルを移動させます そしてLocalSessionが構築され セッションが 正しい場所にダウンロードされたか 素早く認証します 最後は失敗したダウンロードです

よく忘れがちになるのは BAManifestURLが ダウンロードに失敗すると Extensionに通知されることです タイプはBAURLDownloadを 受け継いでいますが internalタイプではありません ですのでextension filtersが BAURLDownloadオブジェクトだけを 扱っていることを確認します 必須アセットはフォアグラウンドで ダウンロードされたので アプリのインストールに影響するため ネットワークの接続に数秒しか待ちません もしダウンロードに失敗すれば 必須ダウンロードを必須でないものとして として再エンキューするべきでしょう 必須ダウンロードを簡単に 必須でないものに転換するには removingEssential()関数を使用します この関数は必須でないもののコピーを戻します そのコピーをBADownloadManagerの scheduleDownload関数に供給すると 適切な時にシステムが ダウンロードをフェッチします アプリとExtensionが Background Assetsを採用したところで 必須ダウンロードを示す インターフェイスを足すことにします

必須ということは アセットをダウンロードし終えるまで アプリのインストールと更新が 起動を妨げます しかしアプリの起動が妨げられるのは App StoreかTestFlightでの インストールのみで インジケータはこれを目視で認知する 最適の方法です このインジケータは VideoSelector viewのSwiftUIで実行します

セッションがマニフェストで essentialと示されると navigation viewで緑の円が示されます それだけです Background Assetsの実行が 簡単だとわかったところで デバッグと エントリーポイントについてです 前述の通りExtensionは アプリのインストールと更新時 及びバックグラウンドで定期的に起動します インストールはApp Storeが 定期的更新はデバイスが管理するため デバッグのためにExtensionを 起動させる方法が必要です

幸いにもチームがXcodeで作成したツールで Extensionを起動し エントリーポイントをシミュレートできます ツールは「Terminal」からアクセスでき xcrun backgroundassets-debugで起動します またヘルプ情報とmanページも 用意してあります backgroundassets-debugは違うタイプの BAContentRequestsをトリガできる シミュレート引数をパスします シミュレーションメッセージが デバイスに送られた時 デバッグのサポートのために Extensionランタイムがリセットされます backgroundassets-debugは 多数のデバイスのサポートなど 数々の機能があります デバイスがMacとペアリングしていれば Extensionをシミュレートできます BluetoothやWi-Fiでコマンドを送れるため デバイスはUSBで動きを 束縛される必要はありません 最後にbackgroundassets-debugで トリガされるシミュレーションのために デバイスはオンでなければなりません これはデバイスの「設定」アプリの 「プライバシーとセキュリティ」で 簡単にオンにすることができます では今作ったデモアプリで backgroundassets-debugツールを 使ってみます これは「ターミナル」です このMacにXcodeがあるので 接続されたデバイスをリストします 今接続されているのは1つだけで これは私のiPhoneです シミュレートに使うデバイスの UUIDをコピーします 供給された引数にデバイスのUUIDが アプリのバンドル識別子と示されます App-install引数にあるsimulate引数で ツールを呼び出します これにより実際の app-install eventのように app extensionが起こされます を押すとツールが app-install eventが デバイスに送られたと伝えます ではアプリを起動して見てみましょう

すべてのビデオが ダウンロードにエンキューされ 既にダウンロードが終わったものもあります これがBackground Assetsの活躍です みなさんもきっといろいろ アプリの待ち時間を減らす方法を 考えていることでしょう App Extensionのデバッグを お見せしたところで 覚えておくべきことがあります

必須アセットは アプリとダウンロードし インストールプログレスに貢献します そのためこれらのアセットは BAContentRequestインストールか Extension内のアップデートイベント中しか スケジュールできません もしExtensionにエンキューされた 必須ダウンロードが失敗すると アプリは結局はまた起動可能になります それらのアセットが必要な場合 Extension内かアプリの初起動時に 必須ダウンロードを必須ではないものとして 再エンキューせねばなりません 必須なもの以外のダウンロードは アプリのインストールか更新後に バックグラウンドダウンロードで優先です またExtensionは メモリ使用量に限定されます ですのでデバッグを行い書いたコードが メモリ許容量内であることを確認します Extensionのメモリ使用量が 大きすぎるとデバッグ中に メモリ例外としてクラッシュします アプリのインストールや更新中に Extensionがクラッシュすると アプリは直ちに起動可能になります 最後にダウンロードする アセットを正しく管理し アプリを善良な市民にしましょう アプリのキャッシュディレクトリは アセットの管理方法の一つです 以上が今年の新機能です このセッションの要点は アプリの待ち時間を削除することです その方法の一つが Background Assetsを採用し 必須アセット機能を使用することです App Storeにアプリを提出する前に TestFlightを活用しましょう 必須アセットが アプリとダウンロードするのが どのようなものかを TestFlightで確認できます 何か疑問点があれば デベロッパドキュメントを参照し Apple Developer Forumsで リーチアウトしてください またFeedback Assistantもご活用ください 常にBackground Assetsを改善し みなさんがアプリに 採用するのを楽しみにしています まだご覧になっていないなら Background Assetsの 紹介セッションをご確認ください いろんな情報を満載しています 今日はご覧いただき ありがとうございました