Force update vs soft update
The two mechanisms solve different problems:
Force update (mandatory): at launch the app checks its version and, when it falls below the
minimum allowed, blocks access completely. The person sees a screen with an update button and cannot
continue without updating.
Soft update (advisory): the app shows a banner or a dialogue suggesting an update, but the person
can dismiss it and carry on.
When a force update is justified
A force update is a blunt decision with real losses. Use it only with substantial grounds:
| Situation | Force / Soft |
|---|---|
| A critical security vulnerability | Force |
| A breaking API change (500 errors in the old version) | Force |
| A payment processor requirement (PCI DSS) | Force |
| New features and improvements | Soft |
| UI bug fixes with no critical consequences | Soft |
| An outdated third-party SDK | Depends on how critical it is |
Technical implementation
The standard pattern through remote config:
App start
↓
Request to remote config / endpoint
↓
min_required_version = "2.5.0"
current_version = "2.3.1"
↓
current < min? → Show the force update screen
→ Redirect to the App Store / Google Play
Remote config — Firebase Remote Config or your own server — lets you change min_required_version in
real time with no new release. That matters: if the new version turns out to be unstable, you can
roll min_version back.
Important: always test the force update screen before switching it on. The common failure is an
update button pointing at the wrong URL, or one that does not work on part of the device fleet.
Effect on business metrics
A force update inevitably loses part of the audience:
– People on slow connections may never finish the download
– Devices with full storage will not update
– People without automatic updates may not notice the update running in the background
The recommended approach: run a soft update two to four weeks before the force update goes live. It
gives the audience time to prepare and cuts the one-off churn spike substantially.