Influxx Mobile 1.2 shipped a force-update gate — the mechanism that can tell an installed build "you're too old, go update" and block it from proceeding. Any gate with that power has an inverse failure mode: a misconfigured or misdirected version check doesn't just fail to protect you, it can lock out users who did nothing wrong. Before this shipped, that risk was checked directly, against the real shared backend, and confirmed real: Influxx Mobile shares its backend project with a sister ETAPX consumer app, and that app already runs its own live version-gating system in production. Reading from the same config row would have meant a routine version bump on the sister app could brick every current Influxx install on its next launch.
A Shared Backend Is Not a Shared Blast Radius
Influxx Mobile and its sister app run on independent release trains — different app binaries, different App Store listings, different version numbers, shipped on different schedules by different teams. The only thing they share is infrastructure: the same backend project, because standing up a second backend for a companion app is wasted overhead. That sharing is fine for most data. It is not fine for a config row whose entire job is to say "block everyone below this version," because "everyone" silently means everyone reading that row, regardless of which app they're running.
The sister app's gate was already in production, already being updated by its own team on its own cadence, on its own config row. If Influxx Mobile's gate had pointed at that same row, the two apps would have been implicitly coupled through a dependency neither team was tracking. A sister-app release manager bumping their own minimum version would have had no reason to know a second app was silently reading the same value — and no way to predict that their change would surface as a full-screen, undismissable block on an app they don't own.
The Fix: A Table of Its Own, Seeded Inert
The actual design isolates the two completely. Influxx Mobile's gate reads exclusively from its own dedicated config table, one that exists only for Influxx and is never touched by the sister app's release process. The migration that creates it states the goal plainly: a minimum-version bump on one app must never lock the other app's users out, in either direction. Reads are scoped so the gate is checkable before sign-in — a build that should be blocked can't be allowed to slip through just by staying logged out — while writes are restricted to an authorized release path, so the only way to change the gate's behavior is through an explicit, deliberate action, not an ordinary client write.
The seed row matters as much as the isolation. The migration inserts the config with enabled: false and min_version: '0.0.0' on purpose, with a comment noting that shipping it enabled would have blocked every install below that minimum the instant the migration landed. A new safety mechanism should ship inert and get switched on deliberately later — not arrive live and hope nobody's installed version happens to trip it during rollout.
"The scary bug isn't the one where the gate fails to block a version it should have caught. It's the one where it blocks a version it shouldn't have. The first is a missed opportunity. The second is every user's phone showing a wall they can't get past, and you find out from support tickets instead of a test."
— Dana Okafor, Mobile Platform Engineer, ETAPX
Fail Open, on Every Path
Isolating the table solves the cross-app risk, but the gate's own evaluation logic has to be equally paranoid about not blocking by accident. The decision function, evaluateInfluxxForceUpdate, is a pure function deliberately kept free of any React Native or network imports specifically so the one piece of logic capable of locking users out is unit-testable in total isolation from network and platform code. Its rule is consistent across every input: an explicit, well-formed match is required to block, and everything else resolves to letting the user in.
Walk the actual checks in order. A missing config object returns "allowed." A config where enabled is not literally true returns "allowed" — and the config parser backs this up by rejecting a string like "true", only the boolean counts. A config with an empty or missing min_version returns "allowed." An unparseable installed-version string returns "allowed." Even a config that parses successfully but describes a user outside its own test cohort returns "allowed." The only path that returns shouldBlock: true is a config that is enabled, carries a real minimum version, applies to this user, and where the installed version numerically compares below that minimum.
Version Comparison That Doesn't Get Fooled by Strings
Version blocking is a numeric problem wearing a string's clothes, and naive string logic gets it wrong in familiar ways: "1.9.0" would sort after "1.10.0" if compared lexically. compareInfluxxAppVersions parses each dotted segment as an integer and compares numerically, treating missing segments as zero so "1.2" and "1.2.0" are equal. It also strips anything past the numeric prefix before comparing, which matters for prerelease tags — naively splitting "1.2.0-rc.1" on dots produces a fourth segment that would compare as newer than plain "1.2.0", letting a release-candidate build slip past a gate meant to catch it. The comparison only ever looks at the numeric core of the version string.
The installed version itself is read from the native bundle's CFBundleShortVersionString via device info, deliberately not from package.json — the two routinely disagree in this codebase, and comparing the wrong one either blocks every user or silently never fires. It's also the same value shown on the app's own About screen, so on-device QA can confirm the gate is reasoning about the version a person can actually go check.
"I tested this by deliberately trying to break it — bad JSON in the config row, a cohort list with numbers instead of strings mixed in, a missing min_version. Every single malformed case I threw at it just let me straight into the app. The only way I could get it to block me was doing everything correctly on purpose."
— Marcus Webb, iOS QA Contractor, Influxx beta program
Reading Untrusted Rows Without Trusting Them
A remote config row is, from the client's perspective, untrusted input — it comes back from the network as unknown, and a malformed or partially-written row must not crash the gate or coerce into an accidental block. readInfluxxForceUpdateConfig narrows that unknown value defensively: it returns null outright unless min_version is present and a non-empty string, and it filters the test-cohort array down to string entries only, silently dropping anything else rather than trusting a partially-corrupt array. A dashboard typo, a half-finished edit, or a bad deploy of the config all degrade to "no valid config," which — per the fail-open rule above — means every user gets in.
Staged Rollout, Not a Security Boundary
The config's test_user_ids field lets a gate be scoped to a specific list of accounts before it applies broadly — verify the block behaves correctly on your own account, then widen it to an empty list, which the evaluation logic treats as "gate everyone." This exists purely as a rollout safety valve for whoever is publishing the config, not as an access-control mechanism: it's a way to confirm a new minimum-version gate does what's intended against a known account before it can affect anyone else, the same instinct as a canary release, just applied to a config row instead of a binary.
What the Screen Itself Does and Doesn't Do
When the gate does resolve to blocking, InfluxxForceUpdateScreen renders above the entire navigator with no dismiss path — a force-update screen that could be swiped away wouldn't be one. It re-checks whenever the app returns to the foreground, so a gate published mid-session reaches an already-open app without requiring a fresh cold start. A development-only preview hook exists to render the screen on demand from a JS console, so it can be visually QA'd without ever publishing a real gate to production users — and that hook is inert outside __DEV__ builds by construction.
"Any system that can say 'no' to every user at once earns extra scrutiny before it ships, not less. The interesting part of this feature was never the version-comparison code — it was proving, with tests and with table isolation, exactly which conditions are required to trigger a block, and confirming that a plausible mistake on a completely different app's release process couldn't reach into ours."
— Renata Cole, VP of Engineering, ETAPX
Frequently Asked Questions
Could a version bump on the sister app ever block Influxx Mobile users?
No. Influxx Mobile reads exclusively from its own dedicated config table, isolated from the sister app's table at the schema level. The two gates share no row, so a change to one cannot affect the other.
What happens if the config table is unreachable or the request fails?
The gate falls open. Any network failure, missing row, or unexpected error during the fetch resolves to letting the user into the app rather than blocking on an ambiguous state.
Does an unknown or unparseable installed version get blocked as a precaution?
No, the opposite. An empty or unparseable current-version string always resolves to "allowed" — the gate never blocks on uncertainty about what's actually installed.
Is the test-user cohort a security feature?
No. It's a staged-rollout tool for verifying a new gate against a known account before widening it, not an access-control or security mechanism.
Can the gate be dismissed once it blocks a build?
No, by design. It renders above the full navigator with no dismiss path — that's the point of a force update — though it only ever reaches that state on an explicit, well-formed match.
Does Android use this same gate?
No. The check short-circuits to "allowed" on any platform other than iOS, since there's no App Store deep link to send a blocked Android user to in this implementation.
How was the shared-backend risk actually verified, not just assumed?
By checking the sister app's live config table and key directly before writing the isolated version — confirming the collision was real, not hypothetical, is what justified building a fully separate table rather than reusing a namespaced key on the shared one.
A gate that can say no to everyone should be judged less by how well it blocks the versions it's supposed to catch, and more by how hard it is to accidentally block the ones it isn't — that was the actual design target here, and it's the boring, careful kind of engineering that mostly shows up as tests nobody ever has to think about again.
