When 1.10.0 Gets Locked Out: Measuring Four Version Comparison Approaches for Forced Updates

The implementation that passes 16 cases

None of the four works alone, so I built on (4) and added missing-segment normalization plus prerelease handling.

/**
 * Split a version string into numeric segments and a prerelease identifier.
 * Build metadata ("2.1.0+build.55") is excluded from comparison, per 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; // empty or malformed segments fall back to 0
  });
  return { nums, pre };
}
 
/**
 * Returns -1 when a < b, 1 when a > b, 0 when equal.
 * Missing segments are treated as 0, so "1.4" equals "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;
  }
 
  // Prerelease only matters once the numeric parts tie
  if (A.pre === B.pre) return 0;
  if (A.pre === "") return 1;  // a release outranks any prerelease
  if (B.pre === "") return -1;
  return A.pre < B.pre ? -1 : 1;
}
 
/** True when the running build is older than the threshold. */
export function isBelowMinimum(current, minSupported) {
  return compareVersions(current, minSupported) < 0;
}

Results across the 16-case suite:

Zero mismatches out of 16.

One limitation worth stating plainly: prerelease identifiers are still compared as strings, so 1.4.0-beta.2 is ranked above 1.4.0-beta.10. Semver specifies that numeric identifiers be compared numerically, so this is not compliant.

I left it that way. The gate compares the build currently on the store against a threshold I set remotely, and there is no operational path where both sides are prereleases. Fixing it would add a branch to defend for a case that does not occur. If I ever distribute betas outside TestFlight, that is the day to write it.

I also measured speed. 200,000 calls completed in 286.4ms, roughly 1.4µs each. Under identical conditions localeCompare took 1,340.0ms and plain string comparison took 3.4ms.

localeCompare is one to two orders of magnitude slower — and that is irrelevant here. The gate evaluates once at launch, a handful of times at most. The gap between 1.4µs and 6.7µs never reaches a user. Correctness is the axis to optimize, not throughput.

Gate at launch, or gate on the response header

With the comparator settled, the next question was where to run it. Two options, in practice.

I run both, because they protect different things.

The launch-time gate exists to retire old clients on a schedule, with plenty of grace. The header gate exists to stop a combination that is broken right now — when the backend drops compatibility, it needs to bite immediately.

Keep only the first and a user with the app already open never hears about the backend change. Keep only the second and any screen that works offline stays unguarded.

The comparator is shared; only the threshold's entry point is duplicated.

// Resolved once at launch, then read from memory
let gateState = { min: "0.0.0", source: "boot" };
 
export function applyRemoteConfig(cfg) {
  if (cfg?.minSupported) gateState = { min: cfg.minSupported, source: "config" };
}
 
// When a response carries a threshold, keep whichever is stricter
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);
}

Taking the stricter value in applyResponseHeader keeps the two paths from relaxing each other. Cached responses can carry a stale header, and if that lowered the threshold, an emergency stop would silently lift itself.

Fail closed, or fail open

Remote config fetches fail. Bad signal, a congested CDN, your own worker mid-deploy. What should the gate do then?

Access control orthodoxy says deny by default: no evidence, no entry. That is how I wrote it first, without much thought.

It was wrong here. A gate that stays shut locks out users who are running a perfectly current build. Everyone gets blocked by an event that is not even about the app. I had the wrong thing under protection.

What made fail open the right call here only landed for me once I hit the screen myself. On failure, fall back to the last config that did arrive; if there is none, open the gate.

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;               // (1) fall back to the last good config
    source = "cache";
  }
  if (!cfg) {
    cfg = { minSupported: "0.0.0" };  // (2) no cache either: open the gate
    source = "open";
  }
  return { min: cfg.minSupported, source };
}

With the budget at 1,500ms, I varied the network response time and measured the outcome.

Whether the network takes 4,000ms or 9,000ms, resolution returns at roughly 1,500ms. Promise.race means the slow side is never awaited.

The 1,500ms figure is the longest I am willing to hold a splash screen without it feeling stuck. My time-to-first-paint budget sits around two seconds, so this fits inside it. That number belongs to each app's startup budget — there is no universal answer.

Never gate on a build that is still in review

With the comparator and the placement settled, I tripped over operations instead.

On the day I submitted a new version to the App Store, I raised the remote threshold to that version. It felt like the tidy thing to do — old clients swept away in one motion.

The opposite happened. The submitted build was still in review and not on the store. Every existing user fell below the threshold and got the forced-update screen. Tapping through to the store showed them the previous version. There was nothing to update to.

Staged rollout makes it worse. On day one roughly 1% of users receive the new build, while the threshold has already moved for 100% of them.

The fix was to decouple threshold changes from release work entirely.

1. Submit the new version (leave the threshold alone)
2. Confirm it passed review and is actually live
3. Advance the staged rollout to 100%
4. Wait several days and confirm the adoption rate reached expectations
5. Set the threshold to the previous version — not the one just shipped

Step 5 is the point. The threshold tracks "one behind," never "current." Gate on the newest build and you always leave a window where users are locked out before that build can reach them.

Google Play and the App Store also propagate live status at different speeds, so I now confirm both before moving the threshold. I once raised it after only one side went live, and Android users were left in limbo.

When OTA updates shift the value you are comparing

Moving this implementation onto an Expo app surfaced one more mix-up. There is more than one value inside the app that reads like "the current version."

I had been handing the gate the second one, Constants.expoConfig?.version. It behaves correctly on my desk. It drifts the moment an OTA update lands.

Ship a JS bundle whose app config version has been bumped, and the store binary stays where it was while the gate's idea of "current version" moves up. It clears the threshold, so the devices you meant to stop walk right through. The reverse happens too: set the threshold to the newest store build, and a device that has not received the OTA reports an older version, taps through to the store, and finds a binary with the very number it already has.

A forced update is telling the user one thing — reinstall from the store. So the value to compare is the number of the binary sitting on the store, which is the first row.

import * as Application from "expo-application";
 
// Points at the store-delivered binary; OTA never moves it
const storeVersion = Application.nativeApplicationVersion ?? null;
 
export function shouldBlockForStoreUpdate(minSupported) {
  // null in Expo Go and on web: no evidence, so open (same direction as fail-open)
  if (!storeVersion) return false;
  return isBelowMinimum(storeVersion, minSupported);
}

When what I need to stop is a JS-side mismatch — the API contract moved and the bundle has not caught up — I keep that on Updates.runtimeVersion rather than letting it ride the same gate. The two ask the reader for different actions: one sends them to the store, the other asks them to close the app and open it again. Put both behind one screen and you get a state where neither instruction can be followed.

I went back and forth on opening the gate where nativeApplicationVersion returns null. Letting development builds through may leave a hole in my own testing. Even so, not bending the "no evidence, no closing" rule per environment is what I'd rather keep.

Three rules I kept

Three lines went into my checklist at the end of all this.

Keep the comparator next to its tests. Version comparison has an unusually long window in which a broken implementation looks fine — right up until 1.9 becomes 1.10, or a major version reaches 10. The 16-case suite is about sixty lines. There is no reason to skip it.

Validate the threshold input. An implementation whose behavior depends on whether someone typed 1.4 or 1.4.0 is fragile to begin with, but I also made the dashboard reject anything that fails /^\d+(\.\d+){0,3}$/. Hardening the code and validating the input are not substitutes for each other.

Ship the ability to open before you ship the ability to close. A forced update is one of the few mechanisms that can stop a user's hands from your side. So the gate stays disabled until three things exist: it does not close on fetch failure, it falls back to cache, and the threshold can be reverted immediately.

I did not expect to lose this much ground to something as elementary as comparing two version strings. Until I actually ran it and laid the results in a table, I could not see what I had wrong. There is no shortcut around measuring.

If you are stuck at the same spot, I hope this saves you the evening.