バージョン番号をEASに任せる
提出が無人で進むと、「ビルド番号は誰が上げるのか」が気になります。前回は、EASが番号を管理すると述べました。その中身を見ていきます。
ストアは同じビルド番号を受け付けません。更新を忘れると、ビルド成功後に提出だけが弾かれます。「次はいくつか」を人に尋ねる状況は、リリース担当者に暗黙知が集中する典型です。
versionは1.0.0など利用者が見るマーケティングバージョンで、人間がapp.jsonで決めるため、autoIncrementの対象外です。iOSのbuildNumberとAndroidのversionCodeは、同じversion内の提出物を区別する連番で、対象はこちらです。autoIncrement: trueでもversionは変わりません。
appVersionSource: "remote"は、連番の真実の源をapp.jsonからEAS側へ移す設定です。pull忘れやgitコンフリクトを避け、別マシンでも共有カウンタでビルドできます。
まず、EAS側の現在値を確認します（リスト3）。
eas build:version:get --platform all
環境解決メッセージが4行出ますが、見るのは最後の2行です。AndroidのversionCodeは1、iOSのbuildNumberは4です。カウンタはプラットフォームごとに独立しています（図1）。
実ビルドの番号も確認します。第10回で紹介したeas build:listを、ここでは番号確認に使います（リスト4）。実測では1件あたり16フィールドが並びますが、ここではBuild number、Version、Commitの3項目を抜き出しました（表1）。3件ともProfileはproduction、Distributionはstore、SDKは57.0.0です。その他は誌面の都合で省略しています。
eas build:list --platform ios --limit 3
| Build number | Version | Commit |
| 4 | 1.0.0 | 08659bbad9fca09731e29cf491209b82840a16b9 |
| 3 | 1.0.0 | 08659bbad9fca09731e29cf491209b82840a16b9 |
| 2 | 1.0.0 | 08659bbad9fca09731e29cf491209b82840a16b9 |
4、3、2と並び、最新の4はeas build:version:getと一致します。Commitは同一なのでコードは1行も変わっていないわけですが、ストア側はアップロードごとに一意の・固有のビルド番号を要求してきます。そのため、再提出するごとに採番が必要になるのです。
では、すでにストアへ提出を重ねてきたアプリを、後からEAS管理へ移す場合はどうでしょうか。ストアが受け取っている番号より小さいところからEASが数え始めては、提出が弾かれてしまいます。そこで、番号を明示的に設定します（リスト5）。
eas build:version:set ✓ Select platform › iOS Project @nkzn/eas-sandbox with bundle identifier "io.github.nkzn.eassandbox" is configured with buildNumber 4. ? What version would you like to set? ›
プラットフォームを選び、現在のbuildNumber4を表示してから入力を待ちます。書き換え前の値を確認でき、小さい値の誤設定を防げます。環境解決メッセージは省略しました。
eas build:version:syncは少し事情が異なります。実行すると、プラットフォームごとに「The remote value for the iOS buildNumber is 4, but it was not synced to the local project. This command has no effect on projects using managed workflow.」という警告が表示されました。マネージドワークフローではネイティブプロジェクトを手元に持たないため、同期先そのものが存在しないのです。本連載のサンプルもこの構成です。リファレンスを見て実行し「動かない」と戸惑わないよう、ここで触れておきます。
getとsetはリモート値の読み書き、syncはbareやprebuild済みなどネイティブプロジェクトを持つ構成向けです。番号をEASに任せ、AndroidのversionCodeも含めてExpoのワークフローからリリースできます。
