Your mobile app's API has 14 versions in the field, the oldest three years old. Product wants to remove support. How do you decide?

What the interviewer is testing

Whether you can make a deprecation decision on evidence and whether you understand the mobile constraint that makes this hard.

The constraint

Users control adoption. You cannot force an upgrade unless the capability was built in advance, and a user on an old version has a working app until you break it. Dropping support is a deliberate decision to break their experience.

The evidence to gather

Active users per version, and — more importantly — revenue or transaction volume per version. These frequently differ: an old version may have few users generating disproportionate value, or many users generating none.

Why they have not upgraded. Device no longer supported by the current app, automatic updates disabled, a managed enterprise fleet on a controlled release, or a region with expensive data. Each implies a different response.

The cost of continued support: which endpoints exist only for old versions, what constraints they place on current development, and what security exposure they carry — an old client may use a deprecated authentication mechanism or a cipher suite you want to retire.

The decision and the mechanism

Set a supported-version policy — for example, the current version and the previous twelve months — published, so deprecation is predictable rather than an event.

Build forced upgrade before you need it. A version check on start-up that can show a soft prompt or a hard block. This is the capability that makes every future decision easy, and it must exist before the decision that requires it.

Communicate in-app first, well ahead, with soft prompts escalating over months.

Sunset in stages with brownouts — short scheduled windows where the old version fails — to surface remaining users with a controlled blast radius.

What a strong answer adds

The security argument usually carries the decision where the commercial one does not: an old client that cannot receive fixes is an unpatchable endpoint, and if it uses a mechanism you need to retire it becomes a blocker for the whole estate.

Common weak answers

Removing versions on a schedule without usage data. Supporting all 14 indefinitely.