1.10.0 の端末が強制アップデートに落ちる — 最小サポートバージョン判定を4実装で実測する

16ケースを通した実装

4つのどれも単独では足りないので、④を土台に、欠けたセグメントの補完とプレリリース識別子の扱いを足しました。

/**
 * バージョン文字列を数値セグメントとプレリリース識別子に分解する。
 * "2.1.0+build.55" のビルドメタデータは比較対象から外す（semver 準拠）。
 */
function parseVersion(v) {
  const [core, pre = ""] = String(v).split("+")[0].split("-", 2);
  const nums = core.split(".").map((s) => {
    const n = parseInt(s, 10);
    return Number.isFinite(n) ? n : 0; // 空文字や不正値は 0 に倒す
  });
  return { nums, pre };
}
 
/**
 * a < b なら -1、a > b なら 1、同値なら 0。
 * セグメント数が異なる場合は不足分を 0 とみなす（"1.4" === "1.4.0"）。
 */
function compareVersions(a, b) {
  const A = parseVersion(a);
  const B = parseVersion(b);
  const n = Math.max(A.nums.length, B.nums.length);
 
  for (let i = 0; i < n; i++) {
    const x = A.nums[i] ?? 0;
    const y = B.nums[i] ?? 0;
    if (x !== y) return x < y ? -1 : 1;
  }
 
  // 数値部が等しいときだけプレリリースを見る
  if (A.pre === B.pre) return 0;
  if (A.pre === "") return 1;  // リリース版はプレリリースより新しい
  if (B.pre === "") return -1;
  return A.pre < B.pre ? -1 : 1;
}
 
/** 現在のバージョンが閾値未満なら true（＝ゲートに引っかかる） */
export function isBelowMinimum(current, minSupported) {
  return compareVersions(current, minSupported) < 0;
}

16ケースのテストを通した結果です。

不一致は 16 ケース中 0 件でした。

残っている制約を正直に書いておきます。プレリリース識別子どうしの比較は文字列比較のままなので、1.4.0-beta.2 と 1.4.0-beta.10 は beta.2 のほうが新しいと判定されます。semver は識別子の数値部分を数値として比べる規定なので、この点は準拠していません。

私はこれを直しませんでした。ゲートが比べるのは「ストアに出ている現行バージョン」と「リモートで設定した閾値」であり、両方がプレリリースになる状況が運用上ありません。直すコストより、直したことで新しい分岐を増やすリスクのほうが高いと判断しています。ベータ配信を TestFlight の外へ広げる日が来たら、そのときに書き足すつもりです。

速度も測りました。20万回の呼び出しで 286.4ms、1回あたり約 1.4µs です。参考までに同じ条件で localeCompare は 1,340.0ms、素の文字列比較は 3.4ms でした。

localeCompare は他の実装より一桁から二桁遅いのですが、これは実運用では判断材料になりません。ゲートの判定は起動時に一度きり、多くても数回です。1.4µs と 6.7µs の差は体感に届きません。ここで選ぶべき軸は速度ではなく正しさでした。

ゲートを起動時に置くか、レスポンスヘッダに置くか

判定関数が固まったので、次はどこで走らせるかです。設計の選択肢は実質2つでした。

私は両方を入れています。理由は、この二つが守る対象が違うからです。

起動時のゲートは「古いクライアントを計画的に減らす」ための仕組みで、猶予を持って上げていくものです。対してヘッダのゲートは「今この瞬間に壊れている組み合わせを止める」ためのもので、API 側の互換を切ったときに即座に効いてほしいのです。

前者だけにしておくと、バックエンドを変更した日にアプリを開きっぱなしのユーザーへ届きません。後者だけにすると、オフラインで起動できてしまう画面が野放しになります。

実装としては、判定関数は同じものを共有し、閾値の入り口だけ2系統にしています。

// 起動時に一度だけ解決し、以降はメモリ上の値を参照する
let gateState = { min: "0.0.0", source: "boot" };
 
export function applyRemoteConfig(cfg) {
  if (cfg?.minSupported) gateState = { min: cfg.minSupported, source: "config" };
}
 
// API レスポンスから閾値が来たら、より厳しいほうを採用する
export function applyResponseHeader(headers) {
  const h = headers.get("x-min-supported-version");
  if (!h) return;
  if (compareVersions(h, gateState.min) > 0) {
    gateState = { min: h, source: "header" };
  }
}
 
export function shouldBlock(currentVersion) {
  return isBelowMinimum(currentVersion, gateState.min);
}

applyResponseHeader で「より厳しいほうを採用する」形にしているのは、二つの経路が矛盾したときに緩いほうへ倒れないためです。ヘッダが古い値をキャッシュから返してくる場合があり、そこで閾値が下がると緊急停止が解除されてしまいます。

取得が遅れたとき、閉じるか開くか

リモート設定の取得は失敗します。電波が悪い、CDN が詰まる、自分のワーカーがデプロイ中。そのとき、ゲートをどう振る舞わせるか。

アクセス制御の一般論では deny by default が正しい判断です。判断材料がないうちは通さない——その構えで、私も最初はそう書いていました。

これはこのケースでは誤りでした。ゲートが閉じたまま固まると、正しいバージョンを使っているユーザーがアプリを開けなくなります。設定が取れないという、アプリ側の問題ですらない事象で全ユーザーが締め出されます。守るべき対象を取り違えていました。

ここは fail-open のほうが正しいのだと気づいたのは、自分でその画面を踏んでからでした。取得に失敗したら直近に取得できた設定へ退避し、それも無ければゲートを開けます。そのように設計を書き換えました。

function withTimeout(promise, ms) {
  let t;
  const timeout = new Promise((_, reject) => {
    t = setTimeout(() => reject(new Error("config-timeout")), ms);
  });
  return Promise.race([promise, timeout]).finally(() => clearTimeout(t));
}
 
const CONFIG_BUDGET_MS = 1500;
 
async function resolveGate(fetchConfig, cachedConfig) {
  let cfg, source = "network";
  try {
    cfg = await withTimeout(fetchConfig(), CONFIG_BUDGET_MS);
  } catch {
    cfg = cachedConfig;          // ① 直近に取得できた設定へ退避
    source = "cache";
  }
  if (!cfg) {
    cfg = { minSupported: "0.0.0" };  // ② キャッシュも無ければ開ける
    source = "open";
  }
  return { min: cfg.minSupported, source };
}

バジェットを 1,500ms に置いた状態で、ネットワークの応答時間を変えて挙動を測りました。

応答が 4,000ms でも 9,000ms でも、解決は 1,500ms 前後で必ず返ります。Promise.race にしているので、遅い側の完了を待ちません。

1,500ms という値は、スプラッシュを出したまま待って不自然に感じない上限として置いています。私の環境では起動から最初の描画までの予算を 2秒前後に取っているので、その内側に収まる範囲です。ここは各アプリの起動予算に合わせて決めるところで、普遍的な正解はありません。

審査中のバージョンを閾値にしない

判定も置き場所も固まったあと、運用でもう一度つまずきました。

新しいバージョンを App Store へ提出した日に、リモート設定の閾値をそのバージョンへ上げてしまったのです。「これで古いクライアントが一掃される」と思っていました。

起きたことは逆でした。提出したバージョンはまだ審査中で、ストアに出ていません。既存ユーザーは全員が閾値未満と判定され、強制アップデート画面が出ます。そこから「更新する」を押してストアへ飛んでも、並んでいるのは一つ前のバージョンです。更新するものがありません。

段階的リリースを使っている場合はさらに厄介です。初日に配信されるのは全ユーザーの1%程度で、残りの99%は新バージョンを取得できないのに、閾値だけが上がっています。

対策は単純で、閾値の更新をリリース作業から切り離しました。

1. 新バージョンをストアへ提出（閾値は触らない）
2. 審査の通過と、公開状態の確認
3. 段階的リリースを 100% まで前進
4. その状態で数日置き、更新率が想定に届いたことの確認
5. 一つ前のバージョンを閾値に設定（いま出したバージョンではなく）

5番目が要点です。閾値は「今の最新」ではなく「一つ前」に置きます。最新を閾値にすると、その最新を配信し終える前に全員が締め出される可能性が常に残ります。

Google Play と App Store で公開の反映速度も違うため、私は両ストアの公開状態を確認してから閾値を動かすようにしています。片方だけ先に上げたことがあり、Android 側のユーザーだけが宙ぶらりんになりました。

OTA 更新を挟むと、比べている値がずれます

ここまでの実装を Expo のアプリへ載せ替えたとき、もう一段の取り違えに行き当たりました。「現在のバージョン」として読める値が、アプリの中に複数あるのです。

私が最初にゲートへ渡していたのは二段目の Constants.expoConfig?.version でした。手元では正しく動きます。ずれるのは OTA を挟んだときです。

app config の version を上げた JS バンドルを OTA で配ると、ストアのバイナリは古いままなのに、ゲートから見える「現在のバージョン」だけが上がります。閾値を越えてしまうので、本来なら止めたい端末が素通りします。逆向きも起こります。閾値をストアの最新に合わせたとき、OTA を受け取っていない端末は古い version を報告し、更新画面からストアへ飛んでも並んでいるのは同じ番号のバイナリです。

強制アップデートが伝えているのは「ストアから入れ直してください」という一文です。であれば、比べるべきはストアに入っているバイナリの番号——一段目でした。

import * as Application from "expo-application";
 
// ストア配信のバイナリを指す値。OTA では動きません
const storeVersion = Application.nativeApplicationVersion ?? null;
 
export function shouldBlockForStoreUpdate(minSupported) {
  // Expo Go や web では null。判断材料が無いので開ける（fail-open と同じ向き）
  if (!storeVersion) return false;
  return isBelowMinimum(storeVersion, minSupported);
}

JS 側の不整合——API の契約を変えたのにバンドルが追いついていない状態——を止めたいときは、同じゲートへ相乗りさせず Updates.runtimeVersion で分けています。ストアへ行っていただく判断と、OTA を待っていただく判断では、読者にお願いする行動が違うからです。前者ではストアを開いていただき、後者ではアプリを一度閉じて開き直していただきます。同じ画面で両方を伝えようとすると、どちらの指示にも従えない状態が生まれます。

nativeApplicationVersion が null を返す環境で開ける、という判断には迷いが残りました。開発中のビルドを素通りさせるのは検証の穴になるかもしれません。それでも、判断材料が無いときに閉じないという原則を環境ごとに曲げないほうが、事故は減るのだと感じています。

運用で残した3つのルール

一連の作業を経て、手元のチェックリストに3行だけ足しました。

判定関数は、テストと同じ場所に置きます。 バージョン比較は「動いているように見える期間」が長すぎます。1.9 から 1.10 へ上がる日まで、あるいはメジャーが 9 から 10 へ届く日まで、壊れた実装は正常に見えます。16ケースのテストは60行ほどで書けるので、書かない理由がありません。

閾値は、入力の時点で形を揃えます。 リモート設定に 1.4 と入れたのか 1.4.0 と入れたのかで挙動が変わる実装は、そもそも脆いのですが、管理画面側でも /^\d+(\.\d+){0,3}$/ に一致しない文字列を弾くようにしました。実装の堅牢化と入力の検証は、どちらか一方では足りません。

閉じる手段は、開ける手段とセットで出します。 強制アップデートは、こちらの操作でユーザーの手を止められる数少ない機構です。だからこそ、取得失敗で閉じない・キャッシュへ退避する・閾値を即座に戻せる、この3つが揃うまでは有効化しないと決めました。

バージョン比較のような、教科書の最初のほうに出てきそうな処理でこれだけ踏むとは思っていませんでした。実際に走らせて表にするまで、自分が何を取り違えているのか分かりませんでした。手を動かして測る以外に近道はないのだと、また一つ確かめた気がしています。

同じところで止まっている方の助けになれば嬉しいです。お読みいただきありがとうございました。