Forced Upgrade
Blocking an installed client version from operating until it updates, which is the only lever available and is disruptive enough to need a policy.
You cannot deploy to installed applications. Users update when they choose, and a meaningful proportion have automatic updates disabled, so old versions persist for years.
That leaves one instrument: the application checks a server-supplied minimum version at launch and refuses to proceed below it, directing the user to update.
It works and it is expensive. The user is interrupted, must have connectivity and storage, and may be in the middle of something. On a device too old to run the current version, they are simply locked out. So it should be reserved for cases that genuinely warrant it — a security defect, a protocol change that cannot be made compatible, a regulatory requirement — with a soft prompt as the normal mechanism.
The architectural implication is the more important half: because forcing is expensive, the API must remain compatible with old clients for a long time. That means additive changes, tolerant readers, versioned endpoints where a break is unavoidable, and telemetry on which versions are actually in use so the decision to drop support is evidence-based rather than a guess.