How decisions are made
One payload, evaluated on the device, in a fixed order. Understanding the order is most of understanding the product.
Evaluation order
maintenance → force → soft → none, first match wins. The order is part of the protocol because the alternative is absurd: an app that is deliberately down should not nag about a new version while it is down.
The two versions
Every platform rule is two version numbers, and everything else follows from where a user sits between them.
| Where the user is | What they get |
|---|---|
| Below the oldest supported version | Blocked by a wall they cannot dismiss |
| Between the two | A nudge they can dismiss, subject to snooze limits |
| At or above the version you want everyone on | Nothing at all |
The protocol calls these min and target. You never have to use those words: the panel labels them by what they do.
Messages and languages
Wall copy is messages[locale][key]. Resolution falls back per key to en, so a half-translated language shows its translated strings and English for the rest, never a blank screen.
Clocks are not trusted
No decision compares the device’s clock to a server timestamp. Scheduled maintenance is evaluated on the server, and active in the payload is authoritative; starts_at and ends_at exist only to be displayed.
Snooze accounting
- The count and last-snooze time are stored on the device, per target version.
- Within the cooldown, the prompt is suppressed entirely.
- Once the allowance is spent, the prompt returns after each cooldown but can no longer be dismissed.
- A new target version resets the count. A fresh release is a fresh ask.