📱 Mobile

App Version Fragmentation

version fragmentation · app version fragmentation · outdated app versions · legacy app versions · minimum supported version · app version spread

Definition

App version fragmentation is the spread of active users across several app versions, which complicates API support, limits the rollout of new features, and requires a policy for the minimum supported version.

What version fragmentation is and why it is inevitable

Not everyone updates an app the moment a release ships. Some have turned auto-update off, some
postpone it because of limited data or storage, and some simply never notice the update prompt.

As a result, three to six months after a major release the active audience of a typical e-commerce
app can look like this:

Version 6.2 (current):  55% of active users
Version 6.1:            25%
Version 6.0:            12%
Version 5.x and older:   8%

Those last 8% are a potential problem with every API change.

Consequences for engineering and product

API support. While active users remain on an old version, the corresponding endpoint cannot be
switched off. Technical debt accumulates as the team maintains several API versions in parallel.

Feature rollout. New personalization, a new product card design, a new onboarding scenario —
all of it is visible only to the audience on the current version. Metrics for new features get
mixed with the audience running older builds.

Bugs in old versions. Crash rate, ANR rate and payment errors in outdated versions keep
affecting overall quality metrics and the Play Store rating.

Strategies for managing fragmentation

Strategy	When to use it
Soft update	Meaningful improvements: show a banner suggesting an upgrade
Force update	Critical security or API changes: block entry until the app is updated
Remote config	Small behaviour changes with no change to client code
Feature flags	New features: enable only for current versions
OTA update	For React Native or Expo: update the JS bundle without a store release

A minimum supported version policy

Write it down explicitly: the team supports versions N, N-1 and N-2, the three most recent minor
releases. Anything older gets the force update screen. The policy has to be known to the analytics
team as well: when A/B testing new features, the audience must be segmented by version.

Important: a force update with no warning is a common cause of a spike in negative store
reviews. Even for critical updates, give users 24 to 48 hours after a soft warning before
switching on a hard block.

Frequently asked questions

Why is version fragmentation dangerous for the backend?

You cannot change or remove an API endpoint while active users still depend on it. An old app version talks to the old API contract. You are then forced either to support several API versions in parallel or to push users forward with a force update.

What is an N-2 policy?

A team agreement to support the current version and the two previous minor versions. If the current release is 5.3.0, that means supporting 5.3.x, 5.2.x and 5.1.x. Anything older receives a force update or stops receiving data from the API.

How do you reduce fragmentation?

Auto-update is on by default for most users, but a share of them switch it off. The tools are a soft update, meaning a banner suggesting an upgrade; a force update, which blocks entry until the app is updated; and over-the-air changes to part of the logic through remote configuration.