EAS Metadataでストア情報を管理する
EAS Metadataは現在ベータ段階の機能として提供されており、コマンドを実行すると「EAS Metadata is in beta and subject to breaking changes.」という警告が表示されます。対応するストアはApple App Storeのみです。Google Playは対象外なので、ここではiOSアプリのストア情報を管理する方法に絞ります。
App Storeの説明文やキーワード、カテゴリをWebフォームで一つずつ編集する作業は、項目が少ないうちは苦にならないかもしれません。しかし、リリースのたびに日本語や英語など複数ロケールの情報を更新し、入力漏れがないか画面を行き来して確認するのは手間がかかります。
EAS Metadataを使うと、こうしたストア情報をプロジェクト内のstore.config.jsonで管理できます。
まずはApp Store Connectに登録済みの情報をローカルへ取得して、現在の状態をファイルにします（リスト6）。Webフォームへ入力済みの内容を手で転記する必要がないため、EAS Metadataを導入する最初の一歩としても手軽です。
eas metadata:pull
pullを実行すると、プロジェクト直下にstore.config.jsonが生成されます。作成して間もないアプリでは、次の内容になります（リスト7）。誌面の都合でdvisoryの項目は3つに省略していますが、実際には20以上の項目が並びます。
{
"configVersion": 0,
"apple": {
"version": "1.0",
"release": {
"automaticRelease": true
},
"info": {
"ja": {
"title": "EASのサンプル"
}
},
"advisory": {
"alcoholTobaccoOrDrugUseOrReferences": "NONE",
"gambling": false,
"violenceCartoonOrFantasy": "NONE"
}
}
}
初期状態に入っているのは、アプリのバージョン、リリース方法（automaticRelease: trueは審査通過後に自動で公開する設定）、ロケール別の表示情報info（この時点ではアプリ名のみ）、年齢レーティングの回答advisoryです。
なおapp.jsonには1.0.0と書いてありますが、App Store Connect側では1.0として保持されています。ストアの入力フォームで見てきた項目たちが、そのままJSONの形で手元に来たことがわかります。
ここへ、ストアに表示したい情報を書き足していきます。infoのロケール別オブジェクトにはsubtitleやdescription、keywordsなどを追加でき、別の言語を足したいときは同じ階層にロケールのキーを並べます（リスト8）。
"info": {
"ja": {
"title": "EASのサンプル",
"subtitle": "Expoで作ったサンプルアプリ",
"description": "ExpoとEASの連載で使用するサンプルアプリです。",
"keywords": ["Expo", "EAS", "React Native"]
},
"en-US": {
"title": "EAS Sample",
"subtitle": "A sample app built with Expo",
"description": "This is the sample app used in the Expo and EAS series.",
"keywords": ["Expo", "EAS", "React Native"]
}
}
言語を増やす作業が、オブジェクトを一つ並べるだけになりました。ロケールごとに画面を開き直して入力し、どちらかを直し忘れていないか見比べる、という往復がなくなります。日本語版だけ説明文を更新して英語版が古いまま、といった事故も、ファイルの差分を見れば気づけます。
ストアに載るのは説明文だけではありません。アプリのカテゴリや、審査担当者に伝える連絡先もstore.config.jsonで管理できます。いずれもappleの下にinfoと並べて書きます（リスト9）。
"categories": ["DEVELOPER_TOOLS", "UTILITIES"],
"review": {
"firstName": "Yukiya",
"lastName": "Nakagawa",
"email": "review@example.com",
"phone": "+81 90 0000 0000",
"demoRequired": false,
"notes": "This is a sample app for a magazine series. No sign-in is required."
},
"release": {
"automaticRelease": true,
"phasedRelease": true
}
reviewは審査担当者向けの情報です。ログインが必要なアプリならdemoRequiredをtrueにしてdemoUsernameとdemoPasswordを添えられます。「審査に出すとき、どのアカウントを渡したんだったか」を毎回思い出す作業が、リポジトリを見れば済むようになります。連絡先は例として書いていますので、実際には自分の届く先を指定してください。
releaseのautomaticReleaseは前述のとおり審査通過後に自動で公開する設定です。ここにphasedReleaseを加えると、アップデートを7日間かけて段階的に配信するよう指定できます。一度に全員へ届けず、様子を見ながら広げていく考え方は、次回扱うEAS Updateにも別の形で出てきます。
ただし、infoで扱えるのはタイトルや説明文といったテキストの項目に限られます。ストアの見栄えを左右するスクリーンショットやプレビュー動画はstore.config.jsonの対象外で、App Store Connectでの作業として残ります。ストア情報のすべてがコードになるわけではない、という線引きは押さえておきましょう。
ファイルを編集したら、いきなりストアへ反映するのではなく、まずeas metadata:lintで検証します。実際、リスト8の状態でlintを実行したところ、筆者の環境では2件のエラーが検出されました。「The value at /apple/info/ja is missing the required field 'privacyPolicyUrl'.」と、en-USについての同じ内容のエラーです。プライバシーポリシーのURLは、公開直前になって不足に気づきがちな必須項目の代表でしょう。ロケールを増やせば必須項目もその分だけ増えますが、lintは足りていないロケールをすべて挙げてくれます。infoの各ロケールにprivacyPolicyUrlを書き足せば、lintが通るようになります。
このように、文字数超過や必須項目の欠落といった審査リジェクトにつながる定番のミスを、ストアに反映する前に手元で検出できるのが、Webフォームへ直接入力する場合にはない大きな利点です。検証を通したあとでeas metadata:pushを実行し、App Store Connectへ反映します（リスト10）。
eas metadata:lint eas metadata:push
新規アプリの場合は、先にバイナリをeas submitでApp Store Connectへ提出しておく必要があります。前回の記事でiOSバイナリを提出し、App Store Connect側で処理が済んでいる本連載の流れでは、この条件を満たしています。以降はストア情報を編集するたびに、lintで確認してからpushする手順を繰り返せばよいでしょう。
eas metadata:pushの出力には、更新した項目と、未設定のためスキップした項目が一覧で報告されるので、何が反映されたのかをその場で確認できます。pushが完了すると、App Store Connectのアプリ情報やバージョン情報に、ローカルで編集した説明文やキーワードが反映されます（図2）。
EAS Metadataがまだベータ段階で、Apple App Storeに限られる点には注意が必要ですが、対応範囲ではストア情報をコードとして扱えます。ストア情報がコードになれば、変更内容をレビューでき、Gitのdiffで更新箇所も追跡できます。ストアにおけるInfrastructure as Codeとして、リリース作業をチームで再現しやすくする仕組みです。
まとめ
今回は、前回コマンド化した提出まわりに残っていた手作業を、ひとつずつ削ってきました。
--auto-submitは、ビルドの完了を見張る時間をなくしました。ビルドが成功すればそのまま提出へ進むので、コマンドを打ったあとは席を外せます。バージョン番号はappVersionSource: "remote"によってEAS側の共有カウンタへ移り、「次のビルド番号はいくつだったか」を誰かに尋ねる必要がなくなりました。そしてEAS Metadataは、ストアの説明文やキーワード、審査担当者へ渡す情報をstore.config.jsonに集めました。ベータ段階でApple App Storeに限られ、スクリーンショットは扱えないという制約はありますが、対応する範囲ではストア情報をレビューでき、Gitの差分で変更を追跡できます。
ここまで、第10回を「ビルドの民主化」、第11回を「リリース作業の民主化」と呼んできました。今回のテーマはリリース作業から属人性を抜くことです。次のビルド番号、審査担当者へ渡したデモアカウント、去年書いた説明文……これまで担当者の記憶やどこかのスプレッドシートに置かれていた情報が、リポジトリの中のファイルになりました。担当が替わっても同じ手順を再現できます。
もっとも、手元に残っているものもあります。提出に使う.p8ファイルやサービスアカウントのJSONは、第11回で.gitignoreに追加したとおり、各自のマシンに置いたままです。自分の手で提出する分には困りませんが、CIサーバーに提出を任せようとすると、この鍵をどう渡すかが壁になります。第9回で署名クレデンシャルをeas credentialsに預けたのと同じ発想が提出にも及ぶのですが、その話は第14回で扱います。
次回（第13回）はEAS Updateです。ストアに出したアプリを、審査を待たずに直せる仕組みを紹介します。鍵になるのはeas fingerprintで、「ネイティブビルドが必要な変更か、JavaScriptの更新だけで届けられる変更か」を判断してくれます。ストアへ届けたその先の世界へ進みましょう。
