カテゴリー: WWDC25

Instruments を用いたCPUレベルでのパフォーマンス最適化のテクニック。バイナリサーチアルゴリズムの実装例をもとに、CPU内部の動作をマインドセットとして3ステップに分割し詳解。図解もあって直感的で、非常に見応えあったものの、後半にいくにつれ難解で理解を放棄してしまった。

---

0:00 – Introduction & Agenda

• パフォーマンス予測の困難さ：
  • Swift ソースコードから実際の実行環境の間に抽象化レイヤーがある
    • 機械語化されCPU実行
    • ランタイム、サポートコード、フレームワーク、カーネルも含まれ抽象化レイヤーは把握しづらい
  • CPU の並列実行、順不同（out-of-order）で実行、メモリキャッシュによる複雑性

2:28 – Performance mindset

• オープンマインド：先入観を持たず、予想外の原因を想定、データ収集による仮説検証
• 他の原因の考慮：
  • スレッドのブロッキング（ファイルや共有状態の待機）
  • API の誤用（QoS クラス、過剰なスレッド作成）
  • 効率性の改題に対しては、アルゴリズムやデータ構造の変更を検討
  • ツール活用しボトルネックを特定（Xcode Gauges / System Trace / Hangs）
• マイクロ最適化の注意点：
  • コードの複雑化による拡張や推論の阻害や、脆弱な compiler 最適化への依存の可能性あり
• 最適化の優先順位：
  • マイクロ最適化を避けられないか検討
    • 代替手法：コード削除、遅延実行、事前計算、キャッシュ
    • これらを採用できない場合、CPUでの実行速度の向上が必要 ← 今回の主題
• ユーザー体験に最大の影響を与えるクリティカルパスに焦点をあてて最適化すべき
  • ユーザー体験だけでなく、長時間の実行による電力消費の可能性
• 定量化の難しい逐次的な最適化の継続により、小さな改善が大きな改善につながる
  • 継続改善のためのデータ収集用コード：
    • search クロージャを一定時間継続するまで再帰呼び出し
    • OSSignposter: 最適化対象をツールで絞り込めるようにするため、クロージャ呼び出しに使用（category: .pointsOfInterest）
    • ContinuousClock: タイミング計測、Date と異なりオーバーヘッド小

8:50 – Profilers

• Time Profiler vs CPU Profiler：
  • Time Profiler：タイマーに基づきの定期的サンプリング、エイリアシング問題あり
    • エイリアシング: 定期処理がサンプリングタイマーと同じ頻度で発生、Instruments 上で結果に偏り
  • CPU Profiler：CPU クロック周波数ベース、より正確で公平な重み付けが可能
  • CPU 最適化において、CPU サイクルの最大消費箇所を特定するは CPU Profiler を利用
• CPU Profiler の使用：
  • deferred mode での低オーバーヘッド記録
  • Points of Interest での範囲設定
  • 例：Instrtuments上でコールツリーから protocol witness、allocation のオーバーヘッドを特定
    • Array の代替に Span を検討

13:20 – Span

• Span の利点：
  • Collection の代替として連続メモリ配置の要素に最適化
  • base address と count のみのシンプルな構造
  • エスケープやリークが防止され安全
• 変更と結果：該当型を Span に変更するだけで4倍の高速化を実現
• Span の境界チェックによるオーバーヘッドへの影響を調べる必要あり → Processor Trace

14:05 – Processor Trace

• 革新的な機能：
  • ユーザー空間で実行される全ての命令を完全にトレース（sampling bias なし）
  • 1% のみのパフォーマンス影響で無視可能
  • M4 Mac/iPad Pro、A18 iPhone での対応
• 設定：Privacy & Security > Developer Tools での有効化
• 使用方法：
  • 数秒間の短時間トレースを推奨：記録データは数秒数GBに及ぶ可能性
  • 単一インスタンスの最適化でも十分
• flame graph の詳細：
  • 実際の実行順序通りの表示
  • 色分け
    • 茶：システム
    • マゼンダ：Swift ランタイム・標準フレームワーク
    • 青：アプリバイナリかカスタムフレームワーク
• 発見：
  • bounds check ではなく protocol metadata overhead が問題
  • 汎用的な Comparable が使用型に特化されていなかった
  • @inlinable アノテーションの追加またはInt型への手動特化の必要性
• 結果：手動特化でコードの汎用性は失うが 1.7倍の高速化

19:51 – Bottleneck analysis

• CPU の動作に関するメンタルモデル：２つのフェーズ
  • 命令送信（Instruction Delivery）
    • 命令がフェッチされ、マイクロ操作にデコードしCPUが実行しやすくする
  • 命令処理（Instruction Processing）
    • Map and Schedule ユニットへ送信、ルーティングとディスパッチ
    • 実行ユニット or メモリアクセス必要なら Load-Store ユニットに割り当て
  • 上記を逐次実行はフェッチ再開まで時間がかかるため、パイプライン化し並列実行
    • GCDなど複数CPUの異なるOSスレッドアクセスと異なり、1つのCPUが時間的に有利を得る
  • ユニット間でのやりとりにより、並列処理制限、パイプライン操作が停止される可能性：ボトルネック
• ボトルネックの特定：
  • CPU Counters のプリセットモード
  • 4つのカテゴリーによる CPU パフォーマンスの分析
• 段階的な分析：
  • CPU Bottlenecks レーン：Discarded bottleneck の高い割合を発見
  • Discarded Sampling セル：branch prediction miss の特定

• CPU の命令実行の順不同性
  • 命令完了後に並べ替えるので、順番に実行したように見える（CPU による分岐予測機能）
  • 以前の実行に一貫したパターンがないと、誤った経路を辿る可能性
  • 今回はランダム性のある値比較による分岐で、予測に問題が発生した可能性
• 変更：
  • 条件付きの移動命令（conditional move instruction）を使用し、別の命令分岐を回避
  • 早期 return の除去
  • 未チェックの算術演算（unchecked arithmetic）の採用（&+）
• 結果：2倍の高速化

• memory hierarchy の課題：
  • 予測可能なアクセスパターンでメモリアクセスすることによる高速化
  • L1、L2 キャッシュ とメインメモリへのアクセス速度差
    • L2 キャッシュは CPU 外にありヘッドルームが大幅増大
    • メインメモリは L1 キャッシュと比較し50倍低速
  • キャッシュはメモリをキャッシュラインにグループ化（64-128 bytes）
    • 4バイト要求の命令でもより多くのデータを引っ張ってくる
  • 例のバイナリサーチにおける「キャッシュミス」問題
    • 要素を並び替えてキャッシュしやすくし、検索ポイントを同じキャッシュラインに配置：エイツィンガー・レイアウト（Eytzinger layout）
• Eytzinger layout：
  • キャッシュフレンドリーな要素配置
  • breadth-first traversal によるツリー構造
  • search 速度向上と in-order traversal 速度低下のトレードオフ

31:33 – Recap

• 全体的な成果：25倍の高速化を実現
• 段階的なアプローチ：
  1. CPU Profiler：Collection から Span への変更
  2. Processor Trace：unspecialized generics の overhead 発見
  3. Bottleneck Analysis：micro-optimization による大幅な性能向上
• 重要な順序：software overhead の解決 → CPU bottleneck の最適化

32:13 – Next steps

• 実践的なアプローチ：
  • データ収集とパフォーマンスマインドセット
  • 繰り返し測定可能なパフォーマンステストの作成
  • Instruments の継続的な使用

UIテストの自動化について。全然使いこなしていないので、結果の録画機能がここまで充実しているとは知らなかったし、失敗結果をもとに実装の修正案を提案までしてくれるとは優秀過ぎる。

---

0:00 – Introduction and agenda

• Xcode の UI automation を使って、ワンクリックで複数のデバイス、言語、設定でアプリを実行
• 全ての実行の高品質ビデオ録画を取得可能
• テストフレームワーク：Swift Testing と XCTest の2つがある
• XCUIAutomation：XCTest インポート時に自動で含まれ、人と同じようにアプリを自動化
• テストの種類：
  • Unit tests：アプリのロジックとモデルをテスト
  • UI automation tests：ユーザー体験、Apple ハードウェア統合、共通ワークフローをテスト

3:58 – UI automation overview

• UI automation の利点：ジェスチャテスト、アクセシビリティ技術での知覚テスト、多言語対応確認、ハードウェア機能統合テスト、起動パフォーマンステスト
• 3つのフェーズ：Record（操作録画）→ Replay（複数設定で再生）→ Review（ビデオと結果確認）
• プラットフォーム対応：iOS、iPadOS、macOS、watchOS、tvOS、visionOS で同じ自動化を実行可能

6:26 – Prepare your app for automation

• アクセシビリティとの関係：UI automation はアクセシビリティフレームワークを基盤とする
• コード変更なく導入することが可能だが、以下手順を踏むことでテスト品質を高められる
• accessibility identifier の追加：
  • 要素を一意に識別する最良の方法
  • ローカライズされた文字列や動的コンテンツを持つ要素に追加
  • 良い identifier：アプリ全体で一意、説明的、静的
  • SwiftUI：accessibilityIdentifier modifier
  • UIKit：accessibilityIdentifier プロパティ
• Accessibility Inspector：アクセシビリティの問題を発見・診断・修正するツール
• UI Testing Bundle の追加：プロジェクト設定で新しい UI テストターゲットを追加

11:32 – Record your interactions

• 録画プロセス：サイドバーのボタンで UI 録画開始、操作がコードとして自動記録
• 録画後の作業：
  • 録画されたコードのレビュー
  • XCTest API を使用した検証の追加
  • 他の automation API の探索
• UI クエリの選択：
  • ローカライズされた文字列：テキストそのものでなく、accessibility identifier を選択
  • 深くネストされたビュー：最短のクエリを選択
  • 動的コンテンツ：より汎用的なクエリ(e.g. .firstMatch)や identifier を使用
• 検証の追加：waitForExistence、wait(for:toEqual:)、XCTAssert などを使用
• セットアップ最適化：orientation、appearance、location の設定、launchArguments と launchEnvironment の使用
  • アクセシビリティ監査の実行：.performAccessiblityAudit()

17:30 – Replay in multiple configurations

• Test Plan の活用：
  • 個別テストの包含・除外
  • システム設定の管理
  • タイムアウト、繰り返し、並列化の設定
• 複数設定の構成：
  • 各ロケールを個別の設定として追加
    • ドイツ語（長い文字列）、アラビア語・ヘブライ語（右から左のレイアウト）など長い言語のための個別構成も可能
  • 実行中ビデオ、スクショをキャプチャするか、実行後も残すか（デフォルトは失敗時のみ残す）
• Xcode Cloud：
  • クラウドでのビルド、テスト実行、App Store アップロード
  • チーム全体での実行履歴とビデオ録画の共有

20:54 – Review videos and results

• Test Report の機能：
  • 失敗したテストへのナビゲーション
  • ビデオ録画と説明の表示
  • 異なる設定での実行間の素早い切り替え
• ビデオ解析：
  • タイムライン上での失敗箇所へ直接ジャンプ
  • 失敗時点での UI 要素のオーバーレイ表示
    • 要素をクリックして、自動化コード内での推奨実装が表示
    • 複数の代替例の表示とコードの直接コピー、該当箇所に直接遷移し、ペーストして修正

ワークアウトは Apple Watch で毎日使っているので、iOS / iPadOS でどういうことが可能なのか確認してみた。

---

0:00 – Introduction

• 数百のヘルス・フィットネスアプリが HealthKit の暗号化されたデータベースと強力な API を活用
• ワークアウト API は HealthKit が提供する最も強力な API の一つ
• Apple Watch で既にワークアウトアプリを運用している場合、最小限の変更で同じコードを iPhone と iPad で使用可能

0:56 – Run a workout session

• ワークアウトセッションの基本手順：
  1. セットアップ：HKWorkoutConfiguration を作成し、アクティビティタイプを設定（例：ランニング、屋外）
  2. セッション作成：設定を使って HKWorkoutSession を作成
  3. ビルダー取得：ワークアウトセッションから関連する builder を取得し、データソース（HKLiveWorkoutDataSource）をアタッチ
  4. 準備：session.prepare を呼び出し、3秒のカウントダウンを表示
     • オンデバイスセンサーの起動や外部心拍モニターの接続時間を確保
     • ワークアウト開始時にメトリクスがすぐに利用可能になることを保証
  5. 開始：カウントダウン完了後、セッションで startActivity、関連する workout builder で beginCollection を呼び出し

• UI 更新の簡素化：
  1. anchored object query を使用する必要なし
  2. workout builder の delegate が新しいデータ収集時に便利な更新を提供
  3. ワークアウト保存時のメトリクス同期を自動処理

• 終了処理：
  1. session.stopActivity を呼び出し、最終メトリクスの収集を許可
  2. セッションが停止状態に遷移後、builder で endCollection を呼び出し
  3. builder 完了後、セッションで end を呼び出し、ワークアウトサマリーを表示

2:50 – Get session metrics

• 利用可能センサーの違い：
  • iPhone と iPad には心拍センサーが内蔵されていない
  • 心拍 GAT プロファイル対応デバイス（ウェアラブル心拍モニター、Powerbeats Pro 2 など）とのペアリングが可能
  • ペアリング後、HealthKit が心拍データを自動取得し、Health Store にサンプルとして保存

• データタイプの分類：
  • Generated types：システムがワークアウト中に生成するデータタイプ（カロリー、距離など）
  • Collected types：ライブで観察し、ワークアウトサンプルに追加したいメトリクス
  • 例：ワークアウト中の水分摂取量を収集する場合、アプリがサンプルをヘルスデータベースに追加する必要

• データソースの設定：
  • 初期化時、データソースの types to collect プロパティには現在のアクティビティで収集可能な全サンプルタイプが含まれる
  • 外部心拍センサーがない場合でも心拍数が含まれる
  • システム生成またはアプリ保存のサンプルを観察し、live builder に渡す

• コレクションタイプのカスタマイズ：
  • enable / disable collection for type メソッドでタイプの追加・削除が可能
  • 例：ワークアウト中の水分摂取量収集時、Enable Collection を呼び出し、測定値をサンプルとしてヘルスデータベースに追加

• 保存後のワークアウトメトリクス読み取り：
  • ワークアウトオブジェクトの statistics を使用してサマリーを表示
  • 期間中のメトリクスをチャート化する場合は statistics collection query を使用
  • 細かいデータが必要な場合、HKQuantitySeriesSampleQuery を使用してより詳細なデータにアクセス

• デバイスロック時の対応：
  • iPhone はワークアウト中にロックされる可能性が高い
  • 初回ワークアウトセッション開始時、デバイスロック中でもワークアウトデータが利用可能になる旨のシステムプロンプトを表示
  • Live Activity でロックスクリーン上に重要なメトリクスを表示可能
  • プライバシー配慮：データアクセス不可時はメトリクスを省略し、ワークアウト時間のみ表示

• Siri 対応：
  • ロックスクリーンからワークアウトの開始、一時停止、再開、キャンセルが可能
  • アプリ内で Intent Handler（INExtension） を定義し、StartWorkoutIntent などの各インテントを処理
  • アプリデリゲートで Intent に応答する設定が必要

8:35 – Recover from a crash

• クラッシュ復旧の仕組み：
  • システムがクラッシュ時にアプリを自動再起動
  • ワークアウトセッションと Builder が以前の状態で復元
  • ライブデータソースの再設定が必要

• iPhone と iPad 向けの新機能：
  • 進行中のワークアウト復旧用の新しい scene delegate を追加
  • Siri インテント用に作成したアプリデリゲートにシーンデリゲートを追加してクラッシュ復旧を処理

9:34 – Best practices

• Watch アプリ優先：
  • Watch アプリがある場合、そこでワークアウトを開始して全利用可能メトリクスを取得
  • Health Store から Start Watch App を呼び出し
  • ワークアウトを iPhone にミラーリング

• 認証リクエストの最適化：
  • 必要なデータタイプのみ認証をリクエスト
  • アプリの焦点と無関係に見えるデータタイプの認証理由をユーザーが疑問に思わないよう配慮

• Workout Builder API の使用：
  • ワークアウトの作成と保存には常に workout builder API を使用
  • アクティビティリングが適切に更新されることを保証

• 次のステップ：
  • セッション添付のデモアプリ
  • 既存の iPhone/iPad アプリがある場合は Workout Builder API にアップグレード
  • Apple Watch アプリがある場合、同じ API のマルチプラットフォームサポートにより Apple Watch を持たないユーザー向けに提供可能

AttributedString について知りたいと思ったら、TextEditor に関する内容だった。新しい TextEditor を使う機会が現状ないのと、装飾文字列を駆使する機会も今のところないが、文字列処理におけるスライスという言葉を知れて良かった。

---

0:00 – Introduction

• AttributedString を使ったリッチテキスト編集体験の構築
• TextEditor を AttributedString 対応にアップグレードし、カスタムコントロールを構築、独自のテキスト書式定義を作成

1:15 – TextEditor and AttributedString

• TextEditor の AttributedString 対応：
  • TextEditor(text:) に渡す @Binding var text の型を String → AttributedString に変更するだけで大幅に機能強化
    • 太字、斜体、下線、取り消し線、カスタムフォント、文字サイズ、前景色・背景色、カーニング、トラッキング、ベースラインオフセット、Genmoji をサポート
    • 加えて段落スタイリング（Line height / Text alignment / Writing direction）を新たにサポート
  • ダークモードと Dynamic Type に対応
  • システム UI による書式設定のトグル機能
• AttributedString の基本：
  • 文字列と属性の実行を含むシーケンス（属性実行）を格納
    • 属性実行の例：.largeTitle, .largtTitle + .orange
  • Swift の値型で UTF-8 エンコーディング使用
  • Equatable, Hashable, Codable, Sendable に準拠
  • カスタム属性、属性スコープの定義も可能

5:36 – Build custom controls

• サンプルに追加機能の実装：
  • 選択したテキストを材料リストに追加するボタンを作成
  • PreferenceKeyを使用してビュー階層での値の伝達
  • TextEdior は $selection: AttributedTextSelection を介して選択内容を伝達
  • 単独の Range ではなく、RangeSet を使用した複数範囲の選択をサポート（双方向テキスト対応）
    • 複数言語 LtoR RtoL が混在し、跨いで選択した場合は複数の選択範囲として扱われるため
• 双方向テキストの対応：
  • 英語（左から右）とヘブライ語（右から左）のような混在テキスト
  • 視覚的な選択が複数の範囲に分割される場合に対応
  • RangeSet による不連続部分文字列のスライス機能
    • 例：.indices(where:\.isUppercase) により、すべての大文字を検出
    • text[uppercaseRanges].foreground = .blue で、大文字だけ青文字にすることが可能
• カスタム属性の作成：
  • IngredientAttribute によるテキスト範囲を材料としてマーク
  • AttributedString.Index はテキスト内のひとつの場所を表す
    • パフォーマンスのため、AttributedString ではコンテンツがツリー構造で保持、インデックスによりツリー内のパスが格納（16:25〜で図示）
    • このインデックスの動作により予想外のカーソル移動が発生してしまう
  • AttributedString indices の注意点：
    • 変更により全てのインデックスが無効化
    • 作成元の AttributedString でのみ使用可能
    • インデックスが無効になったことを検出した SwiftUI は、クラッシュ回避のためカーソルを末尾に移動する
  • AttributedString は テキストのUTF-8スカラ、UTF-16スカラへのビューが新たに得られるようになった。e.g. text.utf16[index]
  • テキスト変更時にインデックスと選択を更新
    • 範囲や範囲の配列を受け取る transform 関数による安全なインデックス更新 e.g. text.transform(updating: &cookingRange) { text in ... }
• まとめ
  • for range in ranges のような Range のループはやめる
  • RangeSet を使った、ranges により一括でスタイル変更をする（スライス）
  • カーソル位置をテキスト変換と常に追従させるために、transform(updating:) を使用

22:02 – Define your text format

• AttributedTextFormattingDefinition プロトコル：
  • TextEditor が応答する AttributedStringKeys の定義
  • カスタムスコープでの属性制限（前景色、Genmoji、カスタム材料属性のみ許可）
  • .attributedTextFormattingDeinition(definition:) 修飾子でカスタム定義を TextEditor に渡す
  • AttributedStringKeys がスコープに含まれないものは、システム書式設定 UI に表示されない
• AttributedTextValueConstraint プロトコル：
  • AttributedTextValueConstriant.constrain(_:) で属性値の制約ロジックを実装
  • 例：材料属性がある場合は緑色、それ以外はデフォルト色
• TextEditor による自動的な妥当性検証
  • ↑ の変更よりシステム書式設定 UI のカラーコントロールも無効になる
• ペースト時もカスタム属性が維持される
• カスタム属性の詳細制御：
  • inheritedByAddedText：追加したテキストが属性継承をしなくなる
  • invalidationConditions：属性を削除する条件を定義（テキスト変更時など）
  • runBoundaries：属性の実行境界を制約（段落境界など）

34:08 – Next steps

• サンプルプロジェクトの提供：
  • SwiftUI の Transferable Wrapper によるドラッグ＆ドロップや RTFD エクスポート
  • Swift Data を使用した AttributedString の永続化
• AttributedString のオープンソース：
  • Swift の Foundation プロジェクトの一部
  • GitHub での実装確認と貢献、Swift フォーラムでのコミュニティ交流
• Genmoji サポート：
  • 新しい TextEditor により Genmoji 入力サポートが簡単に追加可能
• 開発のヒント：
  • カスタム属性とフォーマット定義を組み合わせた高度なテキスト編集体験の構築

Background Assets について。機械学習の学習済みモデルを配置するのに使えそうなのでみてみた。Apple Developer Program に付帯する 200GB の容量を使ってホスティングできるのは大きい。

---

0:00 – Introduction

• アプリとアセットが人々のデバイスでどのように連携するか、Apple hosting の使用方法について説明
• 現在利用可能なアセット配信技術（Background Assets を含む）の復習
• iOS, iPadOS, macOS, tvOS, visionOS 向けの新機能の統合方法とローカルテスト
• Apple hosting を使用したベータテストと App Store 配布の準備方法

1:01 – New in Background Assets

• Background Assets により、素晴らしい初回起動体験をより簡単に提供
• システムがデバイスでアセットをダウンロードする方法を設定し、メインアプリを更新せずに更新可能
• 使用例：
  • 新規ダウンロード後すぐに遊べるよう、ゲームのチュートリアルレベルを提供（ゲームの残りはバックグラウンドでダウンロード）
  • In-App Purchase でアンロックするオプションのダウンロード可能コンテンツ（DLC）
  • 機械学習モデルの更新（加速された App Store への提出プロセス）
• Asset pack の配信オプション：
  • メインアプリバンドルにすべてを含める（4GB 制限、更新時はアプリ全体の再アップロードが必要）
  • URLSession
  • On-Demand Resources（一部アセット更新時でもアプリ全体の更新が必要、レガシー技術、非推奨予定）
  • Background Assets（推奨）
• Managed Background Assets (New)：システムが自動的にダウンロード、更新、圧縮などを管理
• Apple-Hosted Background Assets
  • Apple Developer Program メンバーシップに 200GB の Apple hosting 容量が含まれる
  • 自前のサーバーにアセットをホスティングする必要なし
• Download policies：
  • Essential：アプリインストールプロセスに統合され、自動ダウンロード、インストール完了後は使用できる状態
  • Prefetch：インストール中に開始し、バックグラウンドで継続する可能性あり
  • On-demand：明示的な API 呼び出しでのみダウンロード
• Asset pack の配信方法、バージョン管理について

7:32 – Sample app development

• Asset pack の作成：
  • macOS, Linux, Windows 用の新しいパッケージングツールを使用
  • マニフェストテンプレートを生成し、JSON ファイルで設定
  • カスタム ID、ダウンロードポリシー、サポートするプラットフォームを指定
• Downloader extension の追加：
  • Xcode で Background Download テンプレートを選択
  • Apple hosting または独自サーバーの選択
  • システム提供の完全機能付き downloader extension を使用可能
  • カスタムコードなしでアプリに追加可能
• Asset pack の使用：
  • AssetPackManager.shared.ensureLocalAvailability(of:) でローカル利用可能性を確認
  • contents(at:searchingInAssetPackWithID:options:) でファイルを読み取り
  • システムが自動的にすべての asset pack を共有名前空間にマージ
  • メモリマップされたデータインスタンスを返す（大きなアセットファイルに適している）
• 設定：
  • メインアプリと downloader extension を同じ app group に追加
  • BAAppGroupID, BAHasManagedAssetPacks, BAUsesAppleHosting キーを Info.plist に追加
• ローカルテスト：
  • macOS, Linux, Windows 用の Background Assets mock server を使用
  • SSL 証明書を発行し、テストデバイスにインストール
  • ba-serve コマンドで mock server を起動
  • Development Overrides で mock server のベース URL を設定

17:24 – Beta testing and distribution

• Apple hosting を使用する場合：
  • アプリバイナリと asset pack を App Store Connect に個別にアップロード
  • TestFlight でテスト、App Store で配布
• Asset pack のアップロード方法：
  • Transporter app：ドラッグ＆ドロップ UI 体験
  • App Store Connect REST APIs：完全な制御と透明性
  • iTMSTransporter：簡素化されたコマンドラインインターフェース
• API を使用したアップロード手順：
  • backgroundAssets リソースに POST リクエストで asset pack レコードを作成
  • backgroundAssetVersions リソースに POST リクエストでバージョンレコードを作成
  • backgroundAssetUploadFiles リソースでアーカイブのアップロード予約を作成
• TestFlight でのテスト：
  • 内部テスト用に asset pack を提出
  • 外部テスト用に別途提出
  • betaBackgroundAssetReviewSubmissions リソースで API からも提出可能
• App Store 配布：
  • App Review に asset pack バージョンを提出
  • アプリバージョンと一緒に提出することも可能
  • reviewSubmissions リソースで API からも提出可能
• 状態管理：
  • Ready for Internal Testing
  • Ready for External Testing
  • Ready for Distribution
• Webhook 通知：asset pack バージョンの準備完了時に通知を受信可能