Every Android dev knows the rhythm: bug found, fix coded, upload, review, wait, wait more, hope. Two to three days between "this is broken" and "users are safe." For a crash that's tolerable. For a revenue leak or a compliance issue, it's an emergency with a slow fuse.
I got tired of the fuse.
The mechanism
Two remote flags, checked on cold start, served from my own console:
min_version— anything below it gets a blocking dialog: update required, no dismiss, store button. Not a nag — a gate.kill_switch— for the truly bad day: the app boots, shows "temporarily unavailable", and phones home. Nothing executes, nothing monetizes, nothing can hurt you or your users.
// console side: what every app build polls
$cfg = remote_config($app->slug);
if (version_compare($clientVersion, $cfg['min_version'], '<')) {
respond(['action' => 'force_update', 'store_url' => $app->storeUrl]);
}The control panel
Here's where the decision lives — the force-update screen in my console, per app, with the minimum version and the switch:
[EDITOR NOTE: that image above is markdown — — inserted with the "Upload & insert" button at the top of this editor. Delete this line and the image line, upload a real screenshot, done.]
What it saved me
[TODO: your real incident — what broke, when you flipped the flag, what it would have cost over 48 hours of review time. Even 3 sentences here make this post.]
The part nobody tells you about remote ops: the value isn't the outage day. It's the confidence on every other day. Knowing you can pull the rope changes how fast you ship.
Rules I set myself
- The kill switch needs a second-person confirmation (it's 2am-me vs. 2am-me)
- Force-update dialogs must link to the store, never dead-end
- Every flag flip is logged with who and when — future-you will ask
Next: 90 days of country-level revenue — what the geo data taught me about pricing.