コードプッシュとOTA更新

なぜバイナリを差し替えずに更新できるのか

通常のアプリ更新はストア審査を通り、ユーザーが新しいバイナリをダウンロードして初めて反映されます。緊急のバグ修正でもこの経路だと数時間から数日かかります。React Native（や旧Cordova系）のアプリは、この待ち時間を回避する手段としてOTA（Over-The-Air）更新を持ちます。鍵は「アプリの中身が二層構造になっている」ことです。ネイティブ実行環境（ネイティブUIコンポーネント、JSエンジン、各種ネイティブモジュール）はストア配布のバイナリに焼き込まれる一方、画面ロジックの実体はindex.bundleのようにパッケージ化されたJavaScriptバンドルとアセット（画像・フォント）で、これらは起動時にJSエンジンが読み込む「データ」に過ぎません。データであるなら、バイナリを差し替えずに中身だけ入れ替えられます。これがコードプッシュの原理です。詳しい二層の橋渡しは /mobile-development/native-bridge-jni-jsi/ を参照してください。

更新の流れ：問い合わせ・取得・切り替え

OTAクライアントSDK（Expo Updates／EAS Update や、CodePush系のSDKなど）は、アプリ起動時に更新サーバーへ「自分はどの版を持っているか」を問い合わせます。サーバーは配信対象のバンドルとクライアントの現在版を比較し、新しい版があれば取得先を返します。ここで重要なのは、ダウンロード完了と同時にその場で切り替わるわけではない点です。

横にスクロール

多くのSDKでは適用タイミングを選べます。既定は「次回起動時」で、ユーザーがアプリを一度閉じて開き直したときに新バンドルへ切り替わります。即時再起動を強制する設定もありますが、操作中の画面が突然切り替わる体感が悪いため、緊急修正以外は次回起動方式が無難です。端末側にはロールバックのために直前の正常バンドルが保持され、新版が起動確認（後述）を通るまで旧版を捨てません。

ストア規約という動かせない境界線

OTAが「何でも後から変えられる」わけではないのは、AppleのApp Store ReviewガイドラインとGoogle Playのポリシーが引く明確な線があるからです。両者に共通する原則は、アプリの本来の目的・機能を変える更新や、ネイティブの実行コードを新たに持ち込む更新は審査を経なければならない、というものです。

技術的にJSバンドルを差し替えられることと、規約上それが許されることは別問題です。例えばA/Bテストで画面配置を変えるのは通常許容されますが、審査中は無害な機能を見せ、OTAで審査後にまったく別の機能へすり替える行為は明確な違反で、発覚すればアプリの削除や開発者アカウント停止につながります。権限や配布の審査モデルは /mobile-development/mobile-app-signing-provisioning/ で扱う署名の信頼モデルと地続きです。

差分更新：バンドル全体を送らない

初期のOTAはバンドル全体（数MB規模）を毎回ダウンロードしていましたが、これはユーザーの通信量とストレージを圧迫します。差分更新（differential/delta update）は、変更された部分だけを転送する仕組みです。

原理はこうです。バンドルは内部的に多数のモジュールやアセットの集合で、それぞれにハッシュが計算されています。サーバーはクライアントが持つ版のハッシュ集合（例 {a1, b2, c3}）と新版のハッシュ集合（例 {a1, b2, d4}）を比較し、差分（この場合 c3 を捨て d4 を追加）だけをパッチとして送ります。クライアントは手元の旧バンドルにパッチを適用して新バンドルを組み立てます。1行のロジック修正なら実際に転送されるのは変更モジュール分のごく一部で済み、全体ダウンロードに比べ転送量が桁違いに小さくなります。

ロールバックと段階的ロールアウト

OTAの怖さは、壊れた版を一瞬で全ユーザーへ配れてしまうことです。これを防ぐのが自動ロールバックと段階的ロールアウトの二段構えです。

自動ロールバックの核は「起動確認（health check）」です。新バンドルを適用した最初の起動で、SDKはまだその版を確定（コミット）しません。アプリのコードが正常に立ち上がり、一定の初期化を終えてnotifyAppReady相当の合図を出したら初めてコミットします。もし新版が起動直後にクラッシュし、この合図が出ないまま次の起動を迎えると、SDKは「この版は起動に失敗した」とみなして自動的に直前の正常バンドルへ巻き戻します。つまり保持していた旧版が安全網として機能します。

段階的ロールアウト（staged rollout）は、新版を最初から100%に配らず、まず1%、次に10%といった割合で徐々に広げる方式です。サーバーは端末を安定したハッシュ（デバイスIDなどのハッシュ）でバケットに割り当て、割り当て値が現在の配信率のしきい値未満の端末だけに新版を返します。配信中はクラッシュ率やエラー率を監視し、悪化すれば配信率の引き上げを止める、あるいはゼロに戻して被害を初期の数%に閉じ込めます。React NativeのOTAはクロスプラットフォーム基盤の上で動くため、この配信制御は /mobile-development/cross-platform-rendering-strategies/ の描画モデルと合わせて理解すると全体像が掴めます。

まとめ

コードプッシュとOTA更新は、アプリがネイティブ実行環境とJSバンドルという二層で構成されることを利用し、後者だけをデータとして差し替えることでストア審査を待たずに修正を届ける仕組みです。ただし変更してよいのはJS層のロジックとアセットに限られ、ネイティブコードの追加や権限・目的の変更はストア規約が審査を要求する動かせない境界です。差分更新はバンドルをハッシュ単位で扱い変更分だけを転送してから検証し、段階的ロールアウトと起動確認ベースの自動ロールバックが、壊れた版の被害を初期の数%に閉じ込めます。技術的に何でも差し替えられることと、規約上・品質上それを安全に行えることは別であり、境界線と安全網の設計こそがOTA運用の要諦です。