TestFlight isn’t a launch — version-gate it

TestFlight is not a launch. Neither is an Android internal or open testing track. They’re controlled rooms where you can prove the product under real pipes — before the whole jurisdiction feels the blast.

One clean pattern: add parameters on your API so the client sends its app version number. On the backend, if that version matches or is greater than your release threshold, serve production release contents. If not, don’t.

Only the pre-release build gets the real thing.

That way the TestFlight (or pre-release) build can exercise jackpots, copy, offers, and flows that aren’t public yet — while App Store and Play users on older binaries still see the safe, current surface.

Mirror it on Android: same version check, same threshold, same content contract. Stores differ. Your gate shouldn’t.

When you’re comfortable — crash-free, RG reviewed, legal signed off — raise the floor and force update so everyone lands on the build that was already proven in the gated preview.

Hoping “nobody opens production yet” is not a release strategy. A version gate is.