On Demand Resourcesは非推奨に——Background Assetsが求める代償

Appleは10年来のコンテンツ配信の仕組みを、わずか13語で引退させました。「On Demand Resources and the NSBundleResourceRequest API are deprecated. Use Background Assets instead.」¹

この一文が項目のすべてです。radar 170066290が付され、Deprecations（非推奨）の見出しの下に置かれ、3つの異なるリリースノートに一言一句同じ形で登場します。¹²³ 削除バージョンの告知も、この非推奨に紐づいた移行ガイドも、macOSやwatchOSのリリースノートへの併記も、Appleは一切公開していません。

作業の実体は最後の4語に隠れています。Background Assetsは単一のものではありません。ホスティング方式も最小デプロイメントターゲットも異なる3つの構成に分岐し、移行コストは桁がひとつ違うほど開きます。選択はコードを1行書く前に発生し、選び間違えることこそが高くつく失敗なのです。

要点

• AppleはiOS・iPadOS 27、tvOS 27、visionOS 27のリリースノートで、On Demand ResourcesとNSBundleResourceRequestを非推奨にしました。¹²³ ODR自体は動き続けます。削除時期は明示されておらず、非推奨となったAPIも従来どおり出荷され、タグも解決され続けます。
• API側の提供情報を見ると、非推奨の対象は6プラットフォーム——リリースノートが挙げるより2つ多く、Mac CatalystとwatchOSが含まれます。⁴ 一方Background AssetsはwatchOS向けの提供情報を一切公開していないため、watchOSは代替手段の記載がないまま非推奨を受け取る形になります。⁵⁶
• 「代わりにBackground Assetsを使え」は3方向に分岐します。Appleホスティングのマネージド、自前ホスティングのマネージド、そしてアンマネージドです。マネージドの2経路はいずれも最小デプロイメントターゲットとしてiOS 26.0を要求します。⁷⁸ 26.0未満で開かれているのはアンマネージド経路だけで、そこではファイルのホスティング、マニフェスト形式の設計、その解析まで自前で行う必要があります。⁹
• ディスク管理は逆転します。ODRでは未使用のタグ付きリソースをシステムが破棄でき、setPreservationPriority(_:forTags:)は破棄順序のヒントとして扱われました。⁴¹⁰ Background Assetsは、コードがremove(assetPackWithID:)を呼ぶまで、ダウンロード済みのパックをすべて端末上に残します。¹¹
• Appleがホストできるのは圧縮済みアセットパックで最大200 GB、1つのAppレコードあたり最大200パックまで。この枠はアプリが提供する全プラットフォームで共有され、App Store Connectへアップロードし、ビルドとは別に審査を受けます。¹²¹³

Appleが非推奨にしたものを正確に

この注記には重みのある論点が3つありますが、そのどれも注記自体には書かれていません。

対象範囲はリリースノートより広く及びます。 項目を載せているのは3つの文書——iOS・iPadOS 27、tvOS 27、visionOS 27で、いずれもOn Demand Resourcesの見出しとDeprecationsの小見出しの下にあり、同じradarを引用しています。¹²³ macOS 27とwatchOS 27の各ノートには記載がありません。

APIの提供情報アノテーションは、もう少し広い話を語ります。NSBundleResourceRequestはiOS 9.0で導入され27.0で非推奨、同じ27.0での非推奨がiPadOS 9.0、Mac Catalyst 13.1、tvOS 9.0、visionOS 1.0、watchOS 2.0にも付いています。⁴ メタデータ上は6プラットフォーム、ノート全体で名指しされているのは4つ。Bundleの保存優先度に関する2つのメソッドも、同じ6プラットフォームのアノテーションを持ちます。¹⁰ リリースノートだけを頼りに棚卸しすると、Mac CatalystとwatchOSの項目をまるごと見落とすことになります。

Mac Catalystの項目は名目上のものです。AppleはNSBundleResourceRequestが「Mac CatalystでビルドされたMacアプリからの呼び出しを無視する」と記載しており、この非推奨はそもそもそこで何もしていなかったAPIを引退させるにすぎません。⁴ watchOSの項目は名目上では済みません。Background Assetsが提供情報として挙げるのはiOS 16.0、iPadOS 16.0、Mac Catalyst 16.0、macOS 13.0、tvOS 18.4、visionOS 2.4で、watchOSの行はありません。⁵ AppleはApple提供ホスティングのアセットパックについて「watchOSを除くすべてのプラットフォームで、App Store経由で配信されるアプリに利用可能」と明言しています。⁶ ODRを使っているwatchOSアプリに届くのは非推奨警告だけで、移行先はありません。

強制力は、私が扱ってきた27サイクルの変更3つの中で最も弱いものです。 非推奨は非推奨にすぎません。削除バージョンも、提出時のチェックも、実行時の失敗も公開されていません。同じサイクルのシーンライフサイクルの義務化では新しいSDKでビルドしたアプリが「起動に失敗」し、起動画面の要件ではApp Storeがビルドそのものを却下します。ODRはそのどちらでもありません。既存のタグは解決され続け、既存の呼び出しはリソースを返し続け、出荷済みのバイナリも動き続けます。届くのはコンパイラ警告と、誰にも針が読めない時計だけです。

時期の選び方は、後片付けではなく判断に読めます。 Appleは4つのプラットフォーム名に対して同時にAPIを非推奨としました。代替手段のマネージド階層が出荷された、その次のリリースでのことです。これは緊急事態ではなく、長さの公表されていない移行期間の始まりとして受け止めるのが妥当でしょう。

コードを書く前に選ぶ分岐

Appleのフレームワーク概要は、2つのホスティング方式と、「ダウンロード、更新、圧縮などを代わりに処理する」マネージドの既定動作を説明しています。Appleホスティングでは「アセットをApp Store Connectにアップロードし、アプリのビルドと同様にそこで管理する」形になります。⁵ XcodeのBackground Download extensionテンプレートは、Appleホスティングのマネージドと自前ホスティングのアンマネージドという2つのタイプを直接示します。⁹¹¹ 3つ目の組み合わせはプロパティリストのキーに存在します。BAHasManagedAssetPacksをYESにしつつBAUsesAppleHostingを設定しない場合、自前でホストするマネージドアセットパックが選択され、そのドキュメントはStoreKitのStoreDownloaderExtensionではなくManagedDownloaderExtensionプロトコルへ誘導します。⁷⁸¹⁴

多くのチームでは、デプロイメントターゲットが答えを決めます。AssetPackManagerやManagedDownloaderExtensionから3つのプロパティリストキーに至るまで、マネージドの入口はすべて最低でもiOS 26.0を要求します。⁷⁸¹⁴¹⁵ iOS 18をサポートするアプリはマネージド階層をそもそも採用できず、選択肢はiOS 16.1まで遡れるアンマネージド経路か、デプロイメントターゲットが上がるまで非推奨のODRを使い続けるかに絞られます。⁹

アンマネージド経路は別種の仕事です。Appleが示す流れでは、システムがアプリ起動前にBAManifestURLからマニフェストをダウンロードし、そのファイルを拡張機能に渡し、ダウンロード要求の集合を受け取ります。⁹ 役割分担についてAppleは含みなく述べています。「自前ホスティングのアンマネージドアセット向けのマニフェストファイルを（任意の形式で）作成し、URLとファイルサイズをシステムに渡すためにそれをコードで解析するのは、あなたの責任です。」⁹ 用意すべきものはホスティング、CDN、マニフェストのスキーマ、パーサー、そしてドメイン許可リスト。「代わりにBackground Assetsを使え」をAPIの差し替えだと読む人は、マネージド階層を読みながらアンマネージドの請求書を読み上げていることになります。

ODRが与えてくれていたもの、そして手作業で作り直すもの

ODRの挙動のうち3つには、そのまま置き換えられる相手がいません。

タグはアセットパックになります。 ODRではXcodeで割り当てた文字列タグでコンテンツを識別し、NSBundleResourceRequest(tags:)がそのうち1つ以上を要求しました。⁴ Background Assetsはタグをアセットパックに置き換えます。アセットパックとはJSONマニフェストで記述されたファイルのディレクトリで、コマンドラインツールによって.aarアーカイブへ圧縮されます。粒度の単位は大きくなり、割り当ての場はXcodeのアセットカタログから、自分で保守するファイルへ移ります。

Appleホスティングは別のリリース列になります。 ODRのコンテンツはビルドに同乗していました。Apple提供ホスティングのアセットパックは、Transporter、altool、iTMSTransporter、あるいはApp Store ConnectのAPI経由で独立してアップロードし、App Reviewにもアプリとは別に提出します。¹¹¹³ この切り離しこそが利点で、ビルドを出さずに新しいコンテンツを届けられます。代償は、2本目の提出パイプライン、2本目の審査待ち行列、そして監視すべき2組目のステータスです。

自動破棄は自分の仕事になり、この逆転が最も鋭い変化です。 ODRはダウンロード済みコンテンツを、システムが所有するキャッシュとして扱いました。Appleは「タグを管理するNSBundleResourceRequestオブジェクトが少なくとも1つ存在する限り、システムはそのタグの付いたリソースを端末ストレージから破棄しようとしません」と記載していましたが、これは破棄するかどうかではなく、いつ破棄するかについての約束です。⁴ setPreservationPriority(_:forTags:)はまさに「バンドル内のタグ付きリソース群を破棄する相対順序についてシステムへのヒント」を与えるために存在していました。¹⁰ 要求を終えればシステムが自らのスケジュールで領域を回収し、ストレージ逼迫時の処理はAppleの問題でした。

Background Assetsは所有権を逆にします。システムはパックを自動的に最新へ保ち、checkForUpdates()はサーバー側で不要になったパックを削除します。¹⁵ しかしどちらの仕組みも、単に使い終わっただけのパックを追い出してはくれません。Appleの指示は明示的です。「アプリがインストールされている間、システムがアセットパックを自動的に削除することはありません。したがって、アセットパックを使い終えたらremove(assetPackWithID:)メソッドを呼び出してください。」¹¹

スコープと参照カウントで成り立っていたパターンは、自分で呼ぶと決めなければならない明示的な削除へと畳み込まれます。

// ODR: claim a tag, use the file, release the claim.
// The system reclaims the space afterward on its own schedule.
let request = NSBundleResourceRequest(tags: ["Tutorial"])
try await request.beginAccessingResources()
let url = Bundle.main.url(forResource: "Introduction", withExtension: "m4v")
request.endAccessingResources()

import System  // url(for:) and contents(at:) take a FilePath

// Background Assets: ensure the pack, read the file, delete the pack.
// Nothing reclaims the space if you skip the last line.
let manager = AssetPackManager.shared
guard let pack = try await manager.manifest.assetPack(withID: "Tutorial") else { return }
try await manager.ensureLocalAvailability(of: pack, requireLatestVersion: false)
let url = try manager.url(for: "Videos/Introduction.m4v")
try await manager.remove(assetPackWithID: "Tutorial")

ODRの自動破棄を前提にしているアプリには、その前提に代わるストレージ方針を書き起こす必要があります。失敗の現れ方は静かです。クラッシュもせず、警告も出ず、ユーザーがストレージ一覧の中にあなたのアプリを見つけるまで、端末のストレージ使用量が増え続けます。

移行の作業面を一つずつ

Apple提供ホスティングのマネージド経路について、Apple自身の手順から次のチェックリストが立ち上がります。

ファイルをアセットパックにまとめ、パックごとにダウンロードポリシーを選びます。ポリシーは3つ。essentialはインストール中にダウンロードされ、App Store、TestFlight、ホーム画面で人々が見ている進捗に加算されます。prefetchはインストール中に始まり、インストール完了後もバックグラウンドで続きます。onDemandはコードが要求したときだけダウンロードされます。¹¹ essentialとprefetchでは、入れ子のinstallationEventTypes配列がfirstInstallation、subsequentUpdate、またはその両方を取るため、チュートリアル用のパックを初回インストール時だけダウンロードし、以降の更新ではすべて省く、といった指定ができます。¹¹

パックごとにマニフェストを書きます。Xcodeが注釈付きのテンプレートを生成します。

xcrun ba-package template -o Manifest.json

{
  "assetPackID": "Tutorial",
  "downloadPolicy": {
    "essential": {
      "installationEventTypes": ["firstInstallation"]
    }
  },
  "fileSelectors": [
    { "file": "Videos/Introduction.m4v" },
    { "directory": "Textures/Tutorial" }
  ],
  "platforms": ["<identifiers from the generated template comments>"]
}

ファイルパスは、パッケージングコマンドを実行したディレクトリからの相対で解決されます。これは後でパス指定によってファイルを読み戻すときに、もう一度効いてきます。¹¹ 各パックをアーカイブします。

xcrun ba-package Manifest.json -o Tutorial.aar

Application Extensionの下にBackground Download extensionターゲットを追加し、タイプはAppleホスティングのマネージドを選びます。アプリと拡張機能の両方にApp Groups機能を追加し、両者を同じグループに入れてください。そのうえでアプリターゲットに3つのプロパティリストキーを追加します。BAAppGroupID、YESを設定したBAHasManagedAssetPacks、そしてYESを設定したBAUsesAppleHostingです。Appleは、Appleホスティングのプロジェクトでは他のBackground Assetsキーをすべて省くよう指示しています。¹¹ 踏み抜きやすい制約が1つあります。対応する拡張機能のプロトコルを採用せずにAssetPackManagerだけを採用することは、Appleの言葉を借りれば「プログラマーのエラー」です。¹⁵

ファイルの読み戻しは、統合された名前空間を通して行われます。Appleは「すべてのアセットパックを共有の名前空間に自動的に統合し、アセットのルートフォルダを人の端末にそのまま貼り付けたかのように再構成する」ため、どのパックがそのファイルを持っているかを追わずに、パスでファイルを指定できます。¹¹ 読み込みは既定でメモリマップされたDataを返し、手続き的な読み込み向けにはファイルディスクリプタ版もありますが、こちらは自分でクローズする必要があります。¹¹

ローカルテストの準備には、別枠で見積もる価値のあるコストがあります。Background AssetsはすべてのダウンロードにHTTPSを使うため、モックサーバーにも証明書が要ります。Appleが示す手順は、キーチェーンアクセスで自己署名のルートCAを作り、Apple ConfiguratorでそのCAを載せたプロファイルを作成し、テスト端末ごとにプロファイルをインストールして信頼し、サーバーのIPアドレスまたはホスト名と正確に一致する名前のSSLリーフ証明書を発行し、サーバーを起動し、各端末のデベロッパ設定でURLの上書きを指定する、という流れです。¹⁷

xcrun ba-serve --host localhost Tutorial.aar HighQualityTextures.aar

この一連の手順は、それ自体を1つのタスクとして見積もってください。On Demand Resourcesでは、自前のサーバーはどの段階でも不要でした。Appleはこれを「App Store上にホストされたコンテンツ」の管理役として説明しており、端末に存在しないリソースは「App Storeから要求される」と述べています。⁴ 移行するということは、1回のダウンロードを試すためだけにでも、まずホスティング——あるいは信頼されたそのモック——を立ち上げる必要がある、ということです。2つの手順書を並べて読むかぎり、移行の初日を食い潰すのはAPIの採用ではなく証明書のチェーンだろう、というのが私の見立てです。

計画の土台になる数字

Apple提供ホスティングのパックについて、Appleは2つの上限を公表しています。合計200 GBと、Appレコードあたり200アセットパックです。どちらも「アプリが提供するすべてのプラットフォームで共有」されます。¹² 合計値は、TestFlightまたはApp Store配信の対象となるバージョンのうち最大サイズから算出され、Awaiting Upload、Processing、Failed、完全にSupersededとなったバージョンは除外されます。上限の80%に達すると、Appleからメールが届きます。パックをアーカイブすると、App Storeで公開中のものを含めそのすべてのバージョンが削除され、容量が回復します。¹²

アンマネージド経路では、この上限の代わりに、自分で設定するトップレベルのプロパティリストキーが4つ（うち1つはさらに3つを含む辞書）並び、圧縮サイズと非圧縮サイズの区別が本物の落とし穴になります。BADownloadAllowanceとBAEssentialDownloadAllowanceはダウンロードサイズの上限で、圧縮後の値を取ります。BAMaxInstallSizeとBAEssentialMaxInstallSizeはインストール後のサイズの上限で、非圧縮の値を取ります。⁹ インストールサイズ側のキーには、実質的にプロダクト上の警告と言うべき注意書きがAppleから添えられています。「App Storeはこのキーを使って製品ページにアプリのサイズを表示するため、正確な値を指定してください……必要なディスク容量を過大に申告しないでください。」¹⁸ 残る1つがBADownloadDomainAllowListで、DNS形式のドメインを受け付け、ワイルドカードとして先頭にアスタリスクを付けられます。⁹

計画に入れるべき数字がもう1つあり、それは散文ではなく提供情報のメタデータから出てきます。AssetPackManagerはiOS 26.0で登場しましたが、そのメンバーのうち4つがすでに非推奨を抱えています。ensureLocalAvailability(of:)とstatus(ofAssetPackWithID:)が26.4で、続いてassetPack(withID:)とallAssetPacksが27.0で非推奨になりました。¹⁹ 検索、状態取得、そしてダウンロード呼び出しが、2つのポイントリリースの間にそれぞれ一度ずつ移動したことになります。Appleが現在指し示す経路——マネージャーのmanifestプロパティ経由——は27.0のSDKではベータ表記が付いており、バッチ処理版のensureLocalAvailability(of:requireLatestVersions:)も同様です。¹⁹ しかもAppleのApple提供ホスティング向けの手順書は、非推奨となった呼び出しのうち2つを今なお使って見せています。¹¹ したがって実務上の下限は、この階層の名目上の26.0より高い位置にあります。先ほど示したダウンロード経路を非推奨警告なしで書くということは、27.0をターゲットにし、そのためにベータ表記の付いたシンボルを受け入れる、ということです。採用せよと告げられている代替手段は、置き換えられるAPIよりも若く、しかも速く動いています。

この非推奨が実際に捕まえる相手

影響を受ける層は狭く、私は自分のコードの中にそれを見つけられませんでした。出荷中の7つのプロジェクトを対象に、NSBundleResourceRequest、beginAccessingResources、setPreservationPriority、ON_DEMAND_RESOURCES系のビルド設定、knownAssetTags、アセットカタログのタグ設定を検索しました。7つすべてで、どのパターンについてもヒットはゼロ。プロジェクトディレクトリ配下のSwift、Objective-C、プロパティリスト、pbxprojの全ファイルを横断的に走査しても、ODRのシンボルは1つも返らず、Background Assetsのシンボルも同様でした。²⁰

このゼロ件という結果には、名指しする価値のある理由があります。一般化できる話だからです。ODRは、コンテンツがコードを圧倒するほど大きいアプリのために存在します。私の最大のアセットカタログはReturnの66.6 MBで、他のアプリはすべて8 MB未満、WaterとYawaraに至っては100 KBを切ります。²⁰ この規模でコンテンツをパックに分割すれば、誰も文句を言っていないダウンロードを節約する代わりに、ネットワーク由来の障害モードとストレージ方針と2本目の審査パイプラインが増えるだけです。Background Assetsを本当に必要とするのは、レベルデータを抱えるゲーム、大きな機械学習モデルを同梱するアプリ、そして言語ごとに動画を持つもの——まさにiOS 27でAppleがローカライズ対応のアセットパックで狙っている層です。²¹

デプロイメントターゲットを見ると輪郭がさらにはっきりします。そして、どのコードベースでも真っ先に確認すべき数字がこれです。私の6つのiOSアプリのうち5つはすでにiOS 26.0以降にあり、今日にでもマネージド階層を使えます。Ace Citizenshipは一部のターゲットが依然17.0と17.5を宣言しており、マネージド階層は使えず、アンマネージド経路か非推奨のODRしか残りません。²⁰ 設計に入る前にこの確認を済ませてください。実際にどの移行を提示されているかを決めるのは、アセットの容量ではなく最小デプロイメントターゲットです。

FAQ

iOS 27でOn Demand Resourcesは動かなくなりますか

いいえ。AppleはODRとNSBundleResourceRequestを非推奨としただけで、削除バージョンも、提出時のチェックも、実行時の失敗も公開していません。¹ 非推奨のAPIは引き続き機能し、既存のタグも解決され続けます。手元に届くのはコンパイラ警告です。同じサイクルの他の破壊的変更と比べると違いがよく分かります。シーンライフサイクルの義務化はアプリを「起動に失敗」させ、起動画面の要件はApp Storeにビルドを却下させます。ODRの非推奨は扉を閉じるのではなく、時計を動かし始めるものです。

この非推奨はどのプラットフォームを対象にしていますか

リリースノートは3つの文書で4つのプラットフォームを挙げています。iOS・iPadOS 27、tvOS 27、visionOS 27で、いずれもradar 170066290を引用しています。¹²³ APIの提供情報メタデータはより広く、NSBundleResourceRequestとBundleの保存優先度メソッドを6プラットフォームで27.0の非推奨と記しており、Mac CatalystとwatchOSが加わります。⁴¹⁰ Mac Catalystは机上の話です。Appleがこのクラスについて、Catalystアプリからの呼び出しを無視すると記載しているからです。⁴ watchOSは机上の話では済みません。Background AssetsはwatchOSの提供情報を公開しておらず、Apple提供ホスティングのパックも「watchOSを除くすべてのプラットフォーム」で利用可能とされているため、watchOSアプリは非推奨のAPIを抱えたまま、記載された後継を持ちません。⁵⁶

アプリがiOS 18をサポートしていても移行できますか

マネージド階層へは移行できません。AssetPackManager、ManagedDownloaderExtension、BAHasManagedAssetPacks、BAUsesAppleHostingはいずれもiOS 26.0を要求します。⁷⁸¹⁴¹⁵ この下限より下では選択肢が2つ残ります。アンマネージド経路はiOS 16.1から使え、その代わりアセットのホスティング、独自マニフェスト形式の定義、拡張機能内での解析、そしてプロパティリストでのダウンロード許容量とドメイン許可リストの宣言を求めてきます。⁹ もう1つは、デプロイメントターゲットが26.0に届くまで非推奨のODRを使い続けることで、削除時期が示されていない現状ではこれも許容されます。

ODRのコードをそのまま移植すると、何が静かに壊れますか

ストレージです。ODRでは未使用のタグ付きコンテンツをシステムが破棄でき、setPreservationPriority(_:forTags:)は順序のヒントにすぎませんでした。⁴¹⁰ Background Assetsは、アプリがインストールされている限り、使い終わったパックを決して削除しません。つまりremove(assetPackWithID:)を呼ぶまで、その領域はあなたのものです。¹¹ 従来のbeginAccessingResourcesとendAccessingResourcesのパターンをそのまま写し、明示的な削除を足さないコードは、ディスクを無制限に漏らし続けます。クラッシュも警告もないので、テストで捕まえる手掛かりもありません。ダウンロードのコードより先に、破棄の方針を書いてください。

要点まとめ

iOS開発者へ: - 何よりも先に最小デプロイメントターゲットを確認してください。iOS 26.0未満ならマネージド階層は存在せず、「代わりにBackground Assetsを使え」はアンマネージド経路でホスティングとマニフェスト形式とパーサーを自作することを意味します。⁷⁹ - 破棄の方針を移行作業の一部として書いてください。remove(assetPackWithID:)に自動の対応物はなく、要求を手放してシステムに任せるODR時代の習慣のままだと、ストレージが静かに増え続けます。¹¹

大容量コンテンツを出荷するチームへ: - ローカルテストの準備は、コードとは別枠で見積もってください。Appleが示す手順は、自己署名ルートCA、各端末にインストールして信頼させるApple Configuratorのプロファイル、サーバーのホスト名に一致するSSLリーフ証明書、端末ごとのURL上書きを通ります。¹⁷ - 200 GBと、Appレコードあたり200パックを前提に計画し、この枠が出荷する全プラットフォームで共有されることを踏まえ、80%到達時にAppleが送るメールに注意してください。¹² 容量回復のためのアーカイブは、App Storeで公開中のバージョンも削除します。¹²

リリース管理者へ: - Apple提供ホスティングのパックは、2本目の提出パイプラインを意味します。TransporterまたはApp Store ConnectのAPI経由でアップロードし、ビルドとは独立にバージョン管理し、単独でApp Reviewに提出します。¹¹¹³ 審査サイクル分の人員を確保してください。 - このサイクルで移行を強制するものは何もありません。ODRの優先度は、実際の強制力を持つシーンライフサイクルの義務化と起動画面の要件の後ろに置き、Appleが削除バージョンを公表した時点で見直しましょう。

27サイクルは、破壊的変更を牙の鋭さ順に並べ続けています。シーンライフサイクルはアプリの起動を止め、起動画面はビルドの出荷を止め、ODRはただ時計を動かすだけ。どれがどれかを見分けることが、このサイクルをうまく使い切る方法です。同じパターンをより小さな面で見たい方は、ImageCreatorのImage Playgroundからの削除をご覧ください。シリーズ全体のハブはAppleエコシステムシリーズです。

参考文献