A new mobile version and an older API: preparing a safe release

The backend changes before every device does

A website deployment can change server behaviour in one place. Mobile applications remain on devices in different versions. Some people disable automatic updates; others lack connectivity or storage. Approval of a new store package is therefore not the point at which every client can be assumed to be current.

In an illustrative municipal app, version 4 introduces a new submission detail while version 3 still reads the original response. Removing an old field when the new app launches affects people who have not yet seen the update. The release plan must cover coexisting clients, API changes and support staff distinguishing new-version failures from existing problems.

Expand the contract before narrowing support

First deploy an API extension that supported older clients can handle. Then release the app that uses the new capabilities. Remove old behaviour only after agreed support conditions are satisfied. Google AIP-180 describes API compatibility, including schema and behavioural changes. Adding a field may be small, but still requires checking the client parser.

Test an installed older build against the new backend, rather than checking only the latest SDK. Watch unknown enum values, replacing nullable fields with required ones and changed meanings of existing states. If an older client crashes on an unknown value, adding a state is incompatible with that client. The server may need to send an appropriate representation under the supported contract.

Gradual distribution limits a defect's reach

Apple can phase an update into automatic updates over seven days. Users can still download it manually during that phase. Google Play allows a chosen percentage of users in a staged update rollout. These mechanisms differ, and a percentage does not guarantee that a particular person cannot receive the new build.

Before starting, prepare internal testing, device coverage, upgrading existing installations and a list of monitored problems. Expand distribution according to evidence, rather than calendar dates alone. For a small user base, even a large percentage may yield few observations. No report then provides weak evidence about an uncommon failure.

Halting distribution does not downgrade a device

Pausing a staged release limits further distribution but does not restore an earlier version for people who already updated. Google Play also provides a procedure to halt a fully rolled-out version under specified conditions; this is not an automatic device downgrade either. Fixing an installed client may require another package and approval.

Prepare a server-side response too. A remote setting can disable an optional new feature temporarily if the app was designed for it. That switch cannot fix a failure occurring before configuration loads. The backend must continue enforcing security rules and permissions. Hiding a button alone does not prohibit an operation.

Observe releases by version and actual use

Separate errors by application and operating-system version. Observe crashes, rejected API calls and specific steps such as completing a submission. Launch counts without outcomes can conceal a broken form. Choose aggregate measurements that support release decisions without putting submission content or user details into crash reports.

Define who pauses distribution, who investigates the backend and who briefs support. For this illustrative update, a new reproducible sign-in crash or a submission-integrity failure could stop expansion. Choose numerical thresholds from baseline errors and usage volume. Prepare the repair procedure so someone can follow it when the main developer is unavailable.

Ending support is a product decision

If an older version cannot continue safely, agree on a minimum supported version, notification and application behaviour. A person with an unfinished submission needs to know what happens to their data. A required update should not lead to an unexplained empty error screen. Account for devices on which the new package is unavailable.

• Supported older builds work against the new backend.
• Upgrading preserves agreed local state and unfinished work.
• The team can halt further distribution and mitigate problems for installed clients.
• Retiring support provides an understandable path for affected users.

Put the topic into practice.