A mobile app blocks its own use below a minimum supported version. How do you design cases proving the gate cannot be bypassed?

## What a minimum-version gate is, and what it is not A minimum-version gate is a rule that an app build below some version may not be used. It usually appears as a blocking screen at launch: the app asks the service what the lowest supported version is, compares it against its own, and if it is behind it draws a screen offering an update and refuses to continue. The property that decides your case design is that **the app draws that screen itself**. It is the app deciding not to serve its own user. That makes it advice rather than enforcement: anything reaching a feature without passing through the screen — a resumed launch, a link that opens a specific screen, a request built by hand, an older build still installed — has not been stopped by anything at all. The gate is only as strong as the service behind it. So the coverage splits three ways: the comparison, the ways around the screen, and the enforcement that actually holds. ## Family one: the boundary The comparison is the part that is silently wrong most often, and it is wrong in exactly one place. - Run at **exactly** the minimum supported version and assert the app is usable. An off-by-one here blocks every user who did the right thing. - Run **one release below** and assert it is blocked. - Run **one release above** and assert it is usable. - Run a version whose numbering has an awkward shape — more segments, a suffix, a two-digit segment — and assert the comparison orders numbers rather than comparing text, where ten sorts before nine. Those four cases take minutes and catch a defect class that survives everything else, because every other case sits comfortably far from the line. ## Family two: the ways around it Each of these is a real entry path a user reaches without trying: - **The version check does not answer.** No connectivity, a slow response, an error. Does the app open or block? - **Resuming rather than launching.** The app was left in the background before the minimum was raised and is brought forward again. Is the check re-run? - **A link that opens a specific screen.** Does it land past the block? - **A date-based rule with the device clock moved.** If the gate is a deadline rather than a version, the device controls the input. | Behaviour when the check cannot answer | What it costs | When it is right | |---|---|---| | Fail open — allow use | An unsupported build reaches the service | Only where the service refuses it independently | | Fail closed — block use | A check outage looks like a total product outage | Where running an old build is genuinely unsafe | Most products fail open on the screen and closed at the service. Whichever the product chose, the case exists and asserts it deliberately rather than discovering it during an incident. ## Family three: the enforcement that holds This is the case that makes the others meaningful, and it never touches a screen. Send a request that declares a blocked client version and assert three things: 1. The service refuses it. 2. The refusal is **distinguishable** — a code the client can only read as update-required, never a generic authorization failure that the app will present as a sign-in problem. 3. **No side effect was recorded.** A blocked write must not land. A refusal that still writes is worse than having no gate, because the product now believes it is protected. ## The path out Coverage stops at the block far too often. The user updates — now what? Assert that the app opens normally with no residue of the blocking screen, that a task interrupted by the block can be started again, and that the refusal is not cached in a way that outlives the update. A gate that blocks correctly and then will not let go is the same outage with an extra step. ## What weak coverage looks like - A single case, far below the minimum, asserting that a screen appears. - No case at exactly the minimum version. - No case where the version source is unreachable. - No request-level case at all, so the entire gate rests on a screen the app draws for itself.