03. EAS Updateとストアビルドを運用する

公開後のアプリでは、すべての修正をストア審査に出す必要はありません。一方で、EAS Updateで配信できない変更もあります。変更の種類を誤ると、更新が届かない、起動できない、ストアの審査対象と実際の機能がずれる、といった問題が起こります。

1. 変更の種類を分類する

EAS Updateは、expo-updatesを含むアプリへJavaScriptとアセットを配信します。変更を送る前に、対象のビルドがその更新と互換性を持つか確認します。EAS Updateの概要

少なくとも、次のチャンネルを分けます。

本番向けの更新を公開する前に、同じビルドをpreviewで確認します。

# environment名はプロジェクトのEAS設定に合わせる
eas update --channel preview --message "Fix habit completion state" --environment preview

確認項目は、画面が開くかだけでは足りません。

更新ごとに、次の情報を残します。

更新ID:
Git commit:
EAS channel:
対象のruntimeVersion:
変更内容:
確認した端末:
確認した主要導線:
ロールバック方法:

EAS Updateのチャンネルと、アプリに含まれるruntime versionが合わない場合、更新が対象端末へ届かないことがあります。設定値をAIに作らせる場合も、実際のビルド設定と配信設定を照合します。

壊れた更新を出してから初めて戻し方を調べると、復旧が遅れます。preview環境で次の順番を一度試します。

EAS Updateには、以前に公開した更新、またはビルドに埋め込まれた更新へ戻すロールバック機能があります。実際のコマンドや対象チャンネルは、EASのロールバック手順を現在のCLIに合わせて確認します。

ネイティブコードを含む問題は、EAS Updateだけでは解決できません。その場合は、修正版のアプリビルドを作成してストアの配信経路へ進みます。