ストリーミングはほとんどのブラウザと
Developerアプリで視聴できます。
-
App Store Connect APIによる自動化の拡張
App Store Connect APIによるワークフローの自動化によって、App Store Connectのルーチンタスクは不要になります。App Metadata APIを活用してApp Storeでの存在感をより上手く管理する方法、新しいPower and Performance Metrics and Diagnostics APIを使用してXcodeにおけるPower and Performance分析ツールに有用な集計データにアクセスする方法について学びます。この包括的なAPIを使えば、チームメンバーの管理、プロビジョニングプロファイル、ベータテスターの追加や削除、売上や財務報告書のダウンロードなどの作業を簡単に自動化できます。
リソース
関連ビデオ
WWDC21
WWDC20
-
ダウンロード
こんにちは WWDCへようこそ こんにちは “App Store Connect APIによる自動化の拡張” ジェフ・コフィーです App Store Connectエンジニアです 今回は 今年公開される新しい― App Store Connect APIの 機能を見ていきます
このAPIは 2年前の WWDCで発表されて以来― ユーザーの皆さんから 高い評価をいただいています 皆さんがAPIを使って アプリケーション開発を合理化したり― プログラムをTestFlightで 試していただけて 嬉しく思います 最初のリリースでは― 皆さんがApp Store Connectで 繰り返し行うことに注目しました チームのユーザーの管理や― プロビジョニング用のプロファイルの作成 ベータテスターの追加と削除― 売上・会計レポートの ダウンロードなどです こういったことは 何度も行うので― 自動化ツールを提供し― 皆さんがもっとアプリケーションに注力 できるようにしたのです それが 2年前に始めたことでした しかし アプリケーション開発フローの 重要な点が― APIで網羅されていませんでした 今年 2つのパワフルな拡張が 新たに― App Store Connect APIに 登場します まず 包括的な アプリケーションメタデータAPIが追加されます App Storeでのプレゼンスを 管理できます パワーとパフォーマンスの メトリックスと診断APIで― 同じ集計データに プログラム的にアクセスし― Xcodeのパワーとパフォーマンスの 分析ツールで活用できます App Store Connect APIの 大規模なアップデートです 200の新しいエンドポイントを 追加し― APIのサイズを全体で 2倍以上にしました アプリケーションカテゴリ グローバルな可用性― プライマリロケールや使用許諾契約などの アプリケーションの情報を管理できます 新しいバージョンの作成 プラットフォームの追加― アプリケーションのプレビューや スクリーンショットのアップロード― アプリケーション名 説明 キーワードなどの― ローカライズされた情報の 追加や更新が可能です 他にも盛りだくさんです このAPIは アプリケーションバージョンの メタデータを 完全に網羅し― 新しいバージョンの 作成から― アプリケーション審査への提出までを 行えます ただし 引き続きApp Store Connect ウェブサイトを使用して― 手動リリースを行い― アプリケーション内課金とGame Centerの構成を 行いますので 注意してください 非常にたくさんの新しい発見と コーディングがありますので― APIの利用プロセスは なるべく 簡単にしたいものです そのため 完全な― OpenAPI仕様ファイルを ダウンロードできるようにしてあります OpenAPIに詳しくない方に ご説明すると― 人気のSwagger形式の オープン規格の バージョン3です SwaggerUIで 素早くAPIを参照するか― よりおすすめの方法としては コードジェネレーターにフィードすることで― どの言語でも迅速かつ簡単に APIインテグレーションを実行できます また ドキュメントも 改善しました 新しいエンドポイントが すべて文書化され― 明瞭かつ完全な リクエストと レスポンスの例を掲載しています 新しい説明の記事を追加して― レート制限やファイルアップロードなどの トピックを扱っています また ダウンロード可能な サンプルコードを提供しています 重要なAPIのコンセプト たとえば― 認証トークンの作成と署名 APIレスポンスの扱いや― 新しいアセットアップロードAPIの 使い方がわかります それでは 新しいアプリケーション メタデータAPIでできることを見てみましょう これが私のアプリケーション “Forest Explorer”です 苦労して新バージョンを 作りました このバージョンを App Storeに提出します 新しいAPIを 使うやり方をお見せします 注目するのは 5つの領域です 新しいバージョンの作成 価格の設定 アプリケーションメタデータの更新― ビルドのそのバージョンへの関連付け― そして 新しいバージョンの アプリケーション審査への提出です 新しいバージョンの 作成から始めましょう App Store Connectの アプリケーションページでは― サイドバーのリンクを 使って行います iOS用アプリケーションの 新しいバージョンを作成するか macOSまたはtvOSバージョンを追加できます APIは これと同じ操作を サポートします APIでは Appsと呼ばれるリソースが― アプリケーションごとに 1つずつあります 各アプリケーションには App Store バージョンとのリレーションシップがあります App Store バージョンには プラットフォーム すなわち iOS tvOS macOS― それに バージョン文字列があります これは App Storeで表示したい バージョン番号です 必要なのは 新しいApp Storeバージョンの作成だけです このときに アプリケーションをIDにリンクします ですので 最初にやることは アプリケーションのIDを検索することです これをAPIで行えます v1/appsをGETして bundleIDでfilterします こうすると探している アプリケーションを確実に見つけられます このリクエストを送信し 成功の200応答を受信します レスポンスにはアプリケーションリソースが 含まれアプリケーションのIDがわかります App Store Connectの ドキュメントでは― このIDのことをアプリケーションの Apple IDと呼ぶことがあります このIDをメモしておき 新しいバージョンを作成します v1/appStoreVersionsにPOSTします プラットフォームと 新しいversionStringを付与し― アプリケーションへのリレーションシップの リンクを含めます ここで 先ほど検索した アプリケーションのIDを使用します このリクエストを送信し 201 CREATEDが返ります これで App Store Connect が新しいバージョンを作成しました ここでApp Store Connectに ログインしたら― サイドバーには このバージョンが表示されます レスポンスには App Store Connectが― このバージョンに割り当てた IDがあります ここで アプリケーションの価格設定と 可用性を設定します App Store Connectの アプリケーションページで― サイドバーで “Pricing and Availability”を― クリックして ページへ移動します 今日は特に “Price Schedule”を見ていきます 今日はお見せしませんが― アプリケーションの予約販売を管理したり― アプリケーションのグローバルな可用性を 管理するAPIも使用できます では 価格設定は APIリソースモデルの どこに出てくるのでしょうか ここで再び Appsリソースから始めます Appsリソースには App Pricesという 別のリソースへのリレーションシップもあります 各App Priceには startDateがあります 現在の価格の場合 これはnullになります ここでは Price Scheduleですので― 複数の計画的な 将来価格の変更があります この場合 アプリケーションには複数の価格があり― 追加される価格にはそれぞれ startDateがあります これは その価格が 世界中で有効になる日付です また 各App Priceには Price Tierがあります これは 皆さんがおなじみの App Store Connectのものと同一です 無料Tier 米ドルで99セントのTier 1 などです App Store Connectで Tierを選択するには― 通常 “All Prices and Currencies” ページを参照します お見せしましょう Pricing and Availabilityに戻って “All Prices and Currencies”をクリック このような価格リストが 表示されます 横にはTierが下方向へ また App Storeテリトリーが上にあります それぞれのTierとテリトリーで 個別の価格ポイントがわかります それぞれの価格ポイントには 2つの値があります カスタマーがアプリケーションに 支払う価格を― そのテリトリーの 通貨で示したもの― そして 販売ごとに皆さんが受け取る 収益です リソースモデルでは この価格Tierは― 実際には 別のリソースのセットへの リレーションシップです これらのグレー色のリソースは 読み取り専用の参照データであり― “All Prices and Currencies”ページと まったく同じデータです 各価格Tierは 価格ポイントのコレクションを含みます 各App Storeテリトリーにつき 1つのポイントです これらすべての価格ポイントには カスタマー価格と収益があります オーケー ではそのことを 頭に入れて― APIを使って アプリケーションの現在の Price Scheduleを見てみましょう v1/appsをGETします そしてアプリケーションのID それから prices リレーションシップ― さらに 関連するpriceTierを含めて― レスポンスで 確認できるようにします このリクエストを実行し 価格のリストを受け取ります ここでは 価格は1つだけです startDateはnull 現在有効であることを意味します これは priceTierリレーションシップ Tier 1にリンクされています このJSONデータを App Store Connectの 表示と比較してみましょう Price Scheduleをよく見ると 基本情報は同じです 価格が1つ 現在有効で Tier 1です ここで 特別価格プロモーションを 実施するとします 開始は6月29日 期間は1週間 アプリケーションの価格を無料にします つまり このような Price Scheduleにします 価格は3種類 Tier 1は6月29日まで有効です 6月29日から 無料Tierに切り替えます 1週間後 7月6日に Tier 1に戻します このPrice Scheduleの変更を APIを使ってやってみましょう
3種類の価格を追加しますが― Price Schedule全体に 1つの小さな変更を加えます アプリケーション自体に対して PATCHリクエストを行います アプリケーションの属性は変更しませんので 属性セクションはそのままに― pricesリレーションシップを 変更します App Store Connectに 慣れている方はご存知のとおり― 通常は ここで リソースのIDを追加し― ここでアプリケーションに関連付けます しかし今は アプリケーションの価格リソースは まだ存在していません 作成してアプリケーションに付加します すべて1つのリクエストで 行います 価格は存在していないので IDはありません そこで 取りあえず テンポラリIDを割り当てます 3種類の価格がありますので 3つのテンポラリIDが必要です new-price-1 new-price-2 そして new-price-3を使います テンポラリIDには 任意の値を使用できます 重要なのは このシンタックスで― ドル記号を付けて IDを中括弧に入れることです これがAPIへのシグナルになり まだ存在していない― リソースのテンポラリIDであって― 同一のリクエスト内で これから定義されることを知らせます ここで 新しいアプリケーションの 価格リソースを定義します こちらが 1番目です 1番目のテンポラリIDの new-price-1を― ドル記号付きのシンタックスで 付与します これは startDateはnull 現在の価格です このシナリオでは startDateを そのままにすることもできます 同じ結果になります そして これをTier 1にリンクします 次に 2番目の価格を定義します このようになります IDは new-price-2 startDate は6月29日 これを Tier 0 つまり 無料Tierにリンクします
最後に new-price-3を 日付を7月6日で定義し― priceTierを1に戻します ここで Price Scheduleの変更の― リクエストは まだ送っていません まだJSONのペイロードを― 先ほどお話しした1つの小さなリクエスト用に 構築しているところです これが 取り組んでいた リクエストです ここで 先ほど定義した価格を リクエストに追加します リクエストのエンティティに includedセクションを追加し― 3種類の価格を includedの配列に挿入します 完成したペイロードがこちらです 画面に表示しきれる 分だけですが― ここで includedの配列内の リソースの順序は 問題にはなりません 重要なのは この上にあるテンポラリIDが― 下のテンポラリIDと 一対一で対応することです リクエスト送信時に― App Store Connectは これらの3種類の価格を作成し― 本番のIDを割り当て アプリケーションにリンクします すべて1つの小さな操作で行います 送信してみましょう 200応答が返り 新しいPrice Scheduleが適用されます ここで重要なのは価格変更と 利用可能なテリトリーの変更は App Storeに直ちに送信されます すでにリリースされているアプリケーションの 場合 変更は即時に有効になります 次のバージョンの アプリケーション審査完了とリリースまで― 待たれることはありません APIを試す際 公開中のアプリケーションで テストしないよう注意してください
では アプリケーションのメタデータの 編集を見ていきましょう APIで多数のエンドポイントがある 非常に大きな領域ですので― まずは 全体像を お見せしましょう
バージョンページで “App Information”をクリックし― アプリケーションレベルの情報を 確認するページへ移動します ローカライズされたアプリケーション名 サブタイトル プライバシー規約― App Storeカテゴリなどです バージョンをクリックすると バージョンレベルの情報が表示されます これが プラットフォームごとに 変わるメタデータです スクリーンショット プロモーションテキスト キーワードなどです APIリソースモデルは これと同じように機能します これまで見てきた内容です アプリケーションには App Infoと呼ばれる リソースへのリレーションシップもあります アプリケーションレベルの情報があるところです App Storeカテゴリなどです 一部のアプリケーション情報は ローカライズされますので― それぞれのApp Infoには ロケールごとの 複数のApp Info Localizationsへの― リレーションシップがあります そこに アプリケーション名 サブタイトル プライバシー規約などの属性があります また ローカライズされたデータは バージョンレベルにもあります このリソースを App Store Version Localizationと呼びます バージョンも ロケールごとに これらを1つ持っています App Store Connectに戻って― バージョンページを 詳しく見てみましょう これは アメリカ英語の ローカリゼーションです スクリーンショットと アプリケーションプレビューをよく見ると― 複数のディスプレイタイプがあります 6.5インチのiPhoneや― 5.5インチのiPhone 12.9インチのiPad Proなどです 各ディスプレイタイプにアップロードできる プレビューは3つまで― スクリーンショットは10個までです これらはすべてAPIで― リソースとリレーションシップで モデル化されています バージョンのローカリゼーションは― ディスプレイタイプごとに スクリーンショットのセットへの― リレーションシップを持ちます また ローカリゼーションは プレビューのセットも持ちます それぞれのスクリーンショットのセットは複数の スクリーンショットへリレーションシップを持ち プレビューのセットは 複数のプレビューを持ちます アプリケーションバージョンメタデータには 他にもありますが― これらが今回ご説明する 主なリソースです
ここで 6.5インチのiPhoneのアプリケーション プレビューをアップロードするとします アメリカ英語のローカリゼーションで 新バージョンのプロモーションを行います
つまり アメリカ英語の ローカリゼーションを見つけ― アプリケーションプレビューセットを取得し 新しいプレビューを追加します
バージョンには 少なくとも1つの ローカリゼーションがあります アプリケーションのプライマリロケールの ものです そのローカリゼーションをフェッチして バージョンに使います GETリクエストを appStoreVersionsLocalizations URLに発行し バージョンIDを読み込みます レスポンスには すべての ローカリゼーションが含まれます この アメリカ英語もです この下に appPreviewSetsの related URLがあります このURLをGETします 空のデータ配列が返ります このローカリゼーションにはアプリケーション プレビューセットがないという意味です では 追加しましょう ご賢察のとおり v1/appPreviewSetsにPOSTします previewTypeはIPHONE_65 これは 6.5インチのiPhoneです これを 先ほどIDで見ていた ローカリゼーションにリンクします リクエストを送信すると プレビューセットが作成されます これで アプリケーションプレビューを 追加できます
このリクエスト送信すると プレビューセットが作成されますが― プレビューは単なる 属性とリレーションシップではありません App Store Connectにアップロードする ビデオファイルがあります このようなAPIの操作は 今までの― App Store Connect APIには なかったものです どう機能するか 全体を見てみましょう APIを使ってアップロードできる アプリケーションプレビューは1種類のみです スクリーンショット アプリケーション審査の 添付資料と GeoJSONの― ルーティングアプリケーションカバレッジ ファイルもアップロードできます ただし 何をアップロードするにも 根本的な問題は同じです ディスク上にあるファイルを アセットと呼びます これを App Store Connectに 送ります しかし 間には インターネットがあります アセットのアップロードプロセスは 複数ステップのプロセスです 大きなビデオファイルも なるべく速く― App Store Connectに 送り― インターネット接続の信頼性が― 不完全でも 確実にアップロード できるよう設計されています 方法はこうです まず 予約を作成します 次に 実際のアセットを 複数のパートに分けてアップロードします それから アセットをコミットします 最後に エラーをチェックします やってみましょう
v1/appPreviewsへPOSTして アプリケーションプレビューの予約を作成します App Store Connectに アップロードするファイルの名前と― ファイルサイズをバイト数で 伝えます これを 作成したプレビューセットに リンクすると― App Store Connectがこのプレビューの 場所を予約します アップロード操作のセットを作成するには ファイルサイズを使用します 小さいアセットならば シンプルです HTTP PUTで データをサーバーにアップロードします ただし 大きいアセットの場合は 複数の操作が返ります それぞれの操作には 同一のプロパティが含まれます HTTPメソッド URL バイト長 バイトのオフセット― そして リクエストヘッダーの セットです これらの操作と 中身の情報を使用して― アセットを複数のパートに 分割します 1操作につき 1つのパートにします 各操作では 長さと オフセットの値を使用して― 各パートのに関連付けられたファイルの バイトの範囲を特定します 常に 複数の操作を受け取るよう 備えておいてください 必要な操作の数は さまざまな要因から決定されます 今日アップロードすると 1パートでも― 明日はマルチパートかも知れません ですので コードでは常に 複数のアップロード操作があることを想定します
オーケー アセットがパートに分割されました 手順2に進めます 各アップロード操作でメソッド URL リクエストヘッダーを利用して― 関連付けられたパートを アップロードします 一度に1つずつ行うか― 複数パートを一度に行えます
パートは任意の順番でアップロードできます まったく問題ありません アップロードが失敗することもあります 大丈夫 そのパートをリトライすればよいのです 1つのパートが失敗した場合 他のパートの再アップロードは不要です すべてのパートがアップされるまで 試行を続けます アップできたら 手順3へ進みます アセットのコミットです これを行うには プレビューのURLをPATCHし― アップロードされたプレビューの uploaded属性をtrueにセットしてマークします また オリジナルのソースファイルの MD5チェックサムを付与する必要があります App Store Connectは このチェックサムで― 複数のパートに分割され 正しくアップロードされたことを確認します このリクエストを送信します App Store Connectが アセットを組み立てて― チェックサムを確認し― ビデオファイルかどうかなどの ファイルの整合性と― 長さ 画面サイズ オーディオトラックなどの― さまざまなメトリックスを チェックします すべて問題なければ アセットは完了としてマークされ― アプリケーションプレビューを 審査に提出できます なお アセットの処理は 非同期です 大きなアセットは 時間がかかることがあります APIを使って いつでもアセットを再フェッチして ステータスを確認できます
アプリケーションプレビューをフェッチして― ここの state属性をチェックします 検証に成功すると アセットの状態がCOMPLETEになります 問題が発生している場合 状態はFAILEDに変更され― errors配列で エラー内容がわかりますので― アセットを削除するか 問題を修正して再アップロードします アプリケーションプレビューについて 詳しく見てきました その他のメタデータ関連の リソースについても学びましたが まだまだ序の口です APIで管理や編集を行える メタデータは まだまだたくさんあります 新しい「アプリケーションメタデータ」 セクションをチェックしてください アプリケーションとバージョンのメタデータに関して APIのエンドポイントの完全なリストがあります では ビルドに新しいバージョンを 追加します App Store Connectでは バージョンページで行います ここの “Build”セクションです これは リソースモデルの どれに当たるのでしょうか? これです App Storeのバージョンには 関連付けられたビルドへのリレーションシップが もちろん APIでビルドを 作成するのではなく― Xcodeでビルドを作成し― Xcodeでアップロードするか Transporterを使います おそらくビルドはもう App Store Connectにありますので― IDを検索して バージョンに 関連付けるだけです そろそろ慣れましたね v1/buildsをGETします filterはアプリケーション ID つまり― リリース前のバージョン番号と ビルドのバージョン番号です レスポンスから ビルドのIDを取得します これで このbuild IDと新しいバージョンの ビルドとのリレーションシップをPATCHできます これを送信して 204 NO CONTENT応答を受信します これはリレーションシップの更新なので リソースデータは返りません 成功の応答メッセージです ビルドIDとバージョンIDが 有効かつ― 正しく関連付けられている という意味です メタデータが完了し ビルドが追加されたので これで審査に提出できます App Store Connectでは このプロセスに3つの手順があります 連絡先情報 デモアカウント そして― もしあれば アプリケーション審査に 必要な備考を提供します さらに 必要に応じて 添付資料をアップロードします 最後に “審査に提出”をクリックします APIでは ここでも App Store Versionsから始めます App Store Review Detailsへの リレーションシップがあります ここで アプリケーション審査のための 情報を追加できます こちらは 複数のアプリケーション審査用 添付資料を持つことができます アプリケーションプレビューのときと 同じように― App Store Connectに ファイルをアップロードできます アプリケーション審査の詳細を 新しいバージョンに追加するには― v1/appReviewDetailsにPOSTして― 必要な情報を提供し それをバージョンに関連付けます いいですね アプリケーション審査の詳細が バージョンに添付されました アプリケーション審査の詳細を 追加済みの場合は― PATCHで 編集することもできます この情報は 実際に審査に 提出する時点までは― 何度でも編集できます やり方を見てみましょう 実際に “審査に提出”ボタンを― APIを使って押す方法は? ここでまた 別のリソースがあります App Store Version Submissionです App Storeにバージョンを提出するには これを作成すればよいのです v1/appStoreVersionSubmissionsに POSTします バージョンをリンクして リクエストを送信します これだけです バージョンが アプリケーション審査に回送されます 誤りがあり― 審査される前に アプリケーションを取り戻したい場合は― この App Store Version Submission リソースを削除します バージョンに不備 たとえば スクリーンショットの追加忘れなどが― ある場合は 提出の作成は失敗し 400応答が返ります 応答にはエラーメッセージが 含まれますので― どこを修正すべきか わかります なお バージョンにアプリケーション内課金 または― Game Centerの構成が 必要な場合― これらについては App Store Connectウェブサイトで― 審査に提出する前に 設定する必要があります 以上が アプリケーションメタデータAPIです これで APIリソースをどのように組み合わせるか 感覚をつかめたことと思います これらを使用して バージョンを作成し― 必要なApp Store情報をすべて提供し― アプリケーション審査に提出できました 自動リリースを有効にしている場合は― 審査完了後 アプリケーションは直ちに App Storeに公開されます ウェブやiOSで App Store Connectを使い 手動で― リリースすることもできます
それでは 新しい パワーとパフォーマンスの― メトリックスと診断APIを 見てみます こちらは Xcodeの “パワーとパフォーマンス”です アプリケーションのパフォーマンス指標 たとえば― メモリ使用量 起動時間 ハング率 ディスク書き込み バッテリー消費などを監視するのに役立ちます 実際のカスタマーのセッションから 収集されたデータが使用されます この情報に APIを使用して アクセスすることもできます このデータへのアクセス方法の 概要と より大きな― APIリソースモデルに適用する方法を ご説明します ただし 別のセッションで まるごとこの機能を扱っています この新しいAPIについて 学習したり― レスポンスデータの解釈方法や― アプリケーションの振る舞いへの 洞察の発見について学習できます ですので 併せて― 「Power and Performance App Store Connect API」の― セッションもチェックしてください アプリケーションの最新バージョンの パフォーマンスメトリックスは― アプリケーション URLのperfPowerMetrics リレーションシップで リクエストして取得できます メトリックスデータは カスタムメディアタイプを使用します したがって 適切な Acceptヘッダーも必要です これで アプリケーションの最新バージョンの メトリックスを取得できますが― 特定のビルドのメトリックスを そのビルドのURLの― build URLのperfPowerMetrics リレーションシップでフェッチもできます どちらの方法も リクエストを送信すると― 成功の応答が メトリックスデータの 構造化されたセットと共に返ります この中で メトリックスの最初のセットは HANGメトリックスです 最初のデータセットはハング率で 秒/時で表されています レスポンスのその他の内容については 別のセッションで― データの解釈方法を 学習してください ここでは あと2つのエンドポイントを ご紹介したいと思います 特に ディスク書き込みは 問題点が識別されると― コールスタックを含む 診断情報を表示できます 問題箇所をピンポイントで 探し当てるのに役立ちます Xcodeで 診断シグネチャの リストをお見せします アプリケーションの中でディスク書き込み を行う場所です シグネチャは 合計ディスク書き込みへの 寄与率のパーセント順にソートされています 最も寄与率が高いものが 一番上に来ます 各診断シグネチャについて 実際のコールスタックと― 追加の診断詳細が表示されます この同じ情報を APIを使って 取得することができます 再び build URLで始めて― 新しい diagnosticSignatures リレーションシップをフェッチします やってみましょう APIは診断シグネチャ付きの レスポンスを返します これらは標準のApp Store Connect APIリソースです signature属性があります 実行時に ディスク書き込みが 発生している場所と― このシグネチャが合計書き込みに 寄与するウエイトを識別します また 各シグネチャには ログデータへのリレーションシップがあります このリンクを 再び そのカスタムメディアタイプで使用すると― 診断データが返ります アプリケーション情報と合計ディスク 書き込みに加え― レスポンスの中には 詳細な コールスタック情報があります 以上が アプリケーションメタデータと― パワーとパフォーマンスの メトリックスと診断APIです これらが App Store Connect APIの 大規模なアップデートです 活用してくださるのを楽しみに しています ありがとうございました
-
-
特定のトピックをお探しの場合は、上にトピックを入力すると、関連するトピックにすばやく移動できます。
クエリの送信中にエラーが発生しました。インターネット接続を確認して、もう一度お試しください。