WWDC Quick Look 💓 By SwiftGGTeam
中文 EN 日本語
Automate your development process with the App Store Connect API

Automate your development process with the App Store Connect API

App StoreDistribution & Marketing
元の動画を見る

ハイライト

App Store Connect では今年、Webhook、Build Upload、Feedback という 3 つの新しい API が追加され、「build のアップロード → 配布 → フィードバック収集」というサイクルにおけるポーリングと手作業を、イベントドリブンな自動化に置き換えられるようになりました。

主要内容

アプリ開発は反復的なプロセスです。新機能の実装やバグ修正を行い、build を App Store Connect にアップロードし、Beta Tester に配布してフィードバックを受け取り、次のサイクルへと進みます。Dajinsol Jeon は冒頭（01:04）で課題を指摘しています。このサイクルは速ければ速いほど良く、例えばユーザーからクラッシュ報告があった場合は、可能な限り早く修正すべきです。しかし以前はこれを実現するため、CI システムが ASC に対して「build の処理は完了したか」「新しいフィードバックはないか」と絶えずポーリングを行う必要があり、あるいは Xcode や Transporter での手動アップロードに頼らざるを得ず、効率が低く自動化パイプラインへの統合も困難でした。

今年、App Store Connect はこの一連のサイクルを完全に繋ぎました。Webhook によって ASC から能動的にイベントをプッシュできるようになり、Build Upload API によってどの言語・どの CI プラットフォームからでも build をアップロードでき、Feedback API によって TestFlight のスクリーンショットフィードバックとクラッシュフィードバックを開発ツールに直接取り込めます。これら 3 つを組み合わせることで、CI は webhook を受け取った段階で次のステップに進めるようになり、30 秒スリープしてから再度 GET リクエストを送るといった必要がなくなりました。

詳細

Webhook リスナーを登録する。 ASC Web サイトの Users and Access → Integrations → Webhooks から追加ボタンで設定することもできますし、API 経由でも登録可能です（06:04）。API 登録の利点は、多数のアプリを管理していて新しいアプリに自動登録する必要がある場合などに、一度で済む点です。

POST /v1/webhooks
{
  "data": {
    "type": "webhooks",
    "attributes": {
      "name": "My CI Webhook",
      "url": "https://ci.example.com/asc-hook",
      "secret": "<your-shared-secret>",
      "eventTypes": [
        "buildUploads.stateChanged",
        "buildBetaDetails.stateChanged",
        "betaFeedbackScreenshotSubmissions.created"
      ]
    },
    "relationships": {
      "scope": { "data": { "type": "apps", "id": "<app-id>" } }
    }
  }
}

重要ポイント:

  • url はあなたの webhook リスナーのアドレスで、ASC がここにイベントペイロードを POST します。
  • secret はあなたと ASC で共有するシークレットで、任意の文字列を指定できますが、あなたと ASC のみが知る必要があります。これは HMAC-SHA256 署名の検証に使用されます。
  • eventTypes で 5 種類のイベントから複数を選択します：Build Upload State、Build Beta State、TestFlight Feedback、App Version State、Apple-Hosted Background Asset State（04:07）。
  • 成功すると 201 CREATED が返り、レスポンスボディに webhook ID が含まれます。この webhook を後続で管理する際に使用します。

Build のアップロードは 4 ステップで行います。 BuildUpload を作成 → BuildUploadFile を作成 → upload operations に従ってバイナリをアップロード → PATCH で完了をマーク（07:42）。

POST /v1/buildUploads
{
  "data": {
    "type": "buildUploads",
    "attributes": {
      "cfBundleVersion": "42",
      "platform": "IOS"
    }
  }
}

重要ポイント:

  • 最初のステップでは、この build のメタデータ（bundle version とターゲットプラットフォーム）のみを宣言します。
  • 201 CREATED が返り、レスポンスボディに BuildUpload の ID が得られます。
  • 次にこの ID を使って BuildUploadFile を作成し、ASC にファイル名、バイト数、asset type を伝えます。すると ASC は upload operations の配列を返し、その中に宛先 URL、使用すべき PUT メソッド、必要なヘッダーが含まれます（09:01）。
  • ファイルが大きい場合、operations 配列に複数の項目が含まれることがあります。これは byte range で複数のチャンクに分割してそれぞれ PUT する必要があり、1 つだけとは限らないことを意味します。
  • すべてのチャンクのアップロードが完了したら、BuildUpload を PATCH して uploaded を true に設定します。これで ASC が build の処理を開始します。成功すると 200 OK が返り、state = COMPLETE になります。

Webhook の署名を検証する。 ASC からプッシュされるリクエストには X-Apple-SIGNATURE ヘッダーが含まれます。アルゴリズムは HMAC-SHA256 です（10:51）。

signature = HMAC_SHA256(secret, raw_request_body)
verify   : signature == X-Apple-SIGNATURE

重要ポイント:

  • 登録時に設定した secret と生の body を使って HMAC-SHA256 を計算します。
  • 計算した値とヘッダーを比較し、一致する場合のみ Apple からのリクエストとして受け入れます。
  • 必ず raw body を使用してください。デシリアライズ後に再シリアライズした文字列は順序が不一致になる可能性があり、署名が一致しません。

Webhook ペイロードは最小化されており、詳細は API をコールして取得する必要があります。 例えば新しいスクリーンショットフィードバックが届いた場合、ペイロードには feedback タイプと instance ID のみが含まれます（13:46）。ID を取得した後、GET /v1/betaFeedbackScreenshotSubmissions/{id} を呼び出すことで初めてデバイス情報とスクリーンショット URL を取得できます。スクリーンショット自体は返された URL を使って別途ダウンロードする必要があります。クラッシュフィードバックも同様で、クラッシュログをダウンロードするための crashLog エンドポイントが追加で提供されます（14:32）。

Build beta state イベントは特に有用です（12:12）。以前は外部テストには Beta App Review が必要で、レビュー完了を即座に知ることができませんでした。現在はレビューが完了すると ASC から webhook がプッシュされ、CI は直ちに tester 通知のフローをトリガーできます。

重要ポイント

  • すべきこと：最小限の ASC webhook ゲートウェイを構築する

    • なぜ価値があるのか：5 種類のイベントが build アップロード、beta review、バージョン状態、フィードバック、Apple-Hosted Asset をカバーしており、一度接続すればパイプライン全体でリアルタイムの信号ソースを取得できます。
    • どこから始めるか：/asc-hook を公開する HTTP サーバーを立ち上げ、まずは HMAC-SHA256 検証を実装し、検証失敗時は 401 を返します。検証成功時は生のペイロードをデータベースに保存するかキューに入れ、直ちに 200 を返します。リクエストスレッドで重い処理を行わず、ASC のタイムアウトによる再試行を避けてください。

  • すべきこと：build アップロードを Xcode から CI へ移行する

    • なぜ価値があるのか：Build Upload API は標準的な REST API なので、どの言語・どの CI からも呼び出せます。Mac runner 上の Xcode altool や Transporter に依存する必要がなくなり、エラーメッセージも構造化されているためリトライが容易です。
    • どこから始めるか：アップロードスクリプトを記述し、4 ステップの順序で API を呼び出します。upload operations 配列が複数ある場合はループで処理し、byte range で ipa ファイルを分割して PUT します。最後に uploaded=true で PATCH を行い、webhook から COMPLETE がプッシュされるのを待ってから後続ステップに進みます。

  • すべきこと：TestFlight フィードバックを自社の issue システムに統合する

    • なぜ価値があるのか：スクリーンショットフィードバックとクラッシュフィードバックはユーザーの最も直接的な声ですが、ASC の管理画面に散らばっていると見逃しがちです。Jira/Linear/GitHub Issues に接続すれば、各フィードバックにデバイス情報とスクリーンショットが添付され、見落とされることはなくなります。
    • どこから始めるか：betaFeedbackScreenshotSubmissions.created とクラッシュ対応イベントを監視します。受信後 ID を使って Feedback API を呼び出し詳細を取得し、スクリーンショットやクラッシュログをダウンロードしてから、issue tracker API を呼び出して自動的にチケットを作成します。reporter、デバイス、バージョンなどのフィールドが自動的に含まれます。

  • すべきこと：「build review 完了時の通知」の自動化を実現する

    • なぜ価値があるのか：build beta state webhook は今年新しく追加されたイベントです。外部 tester のリリース遅延は主に審費待ちでボトルネックが発生しており、レビュー完了を即座に検知できることはユーザーへの通知遅延をゼロにできることを意味します。
    • どこから始めるか：buildBetaDetails.stateChanged を購読します。ペイロードには build ID と最新の状態が含まれます。状態が外部テスト可能になった時点で、TestFlight API を呼び出して外部グループに配信し、その後メールや IM で tester に通知します。

関連セッション

コメント

GitHub Issues · utterances