The faulty build is already installed
The release is paused, but a customer still cannot submit an order. Their phone already contains the broken build. Stopping distribution and recovering the product are different operations, and a mobile release plan needs to describe both before approval.
Apple permits a phased release to be paused, while users can still manually download the update. That makes phased distribution useful for limiting exposure, not a mechanism for replacing software already installed. Apple documents these release controls.
Our engineering preference is to discuss the recovery path alongside the feature. If the answer is simply to submit another build, the team has accepted an interval during which the damaged experience remains available. That may be acceptable for a cosmetic defect. It deserves a different conversation for orders, account access or offline work.
Separate installation from activation
A feature can be present in the application without being enabled for everyone. Design its activation as an explicit product decision, with an owner who can disable it when evidence changes. The switch should govern the smallest coherent workflow, not arbitrarily hide individual controls.
Consider a hypothetical document upload flow. Disabling the new scanner should restore an existing upload option and preserve unfinished documents. A flag that merely removes the submit button leaves the user trapped just as effectively as the original defect.
Choose a safe default when configuration cannot be fetched. Record the configuration revision alongside relevant failures so support can distinguish the installed build from the behaviour it was actually running. Remote configuration is still a dependency. A recovery mechanism that requires the failing service to work has an obvious weakness.
Keep the server compatible
Mobile customers do not all upgrade when the team deploys. Treat the supported installed versions as active clients of the service, not as historical artefacts. A backend change should state which requests it continues to understand and which response fields older clients may encounter.
For a proposed checkout change, rehearse an older client creating a basket and a newer client opening it. Then reverse the order. Include partially completed actions, because data created before a failure often survives the feature that created it.
A destructive data change can defeat an otherwise sensible feature switch. If the old workflow cannot read the new record, turning the flag off does not restore it. Preserve the information needed for recovery and decide separately when obsolete representations can be retired.
Write the incident decision in advance
The release note is not an incident plan. Name the signal that stops expansion, the person who can act, the customer message and the way the team confirms recovery. A technical crash graph cannot alone show whether a business action completed correctly.
Include evidence from completed tasks and support reports, with enough context to identify affected versions and configurations. Avoid declaring success because the error disappears after the feature has vanished. Check that customers can still accomplish the underlying job.
The uncomfortable cost is maintaining the fallback. It needs testing, ownership and eventual removal. An unmaintained previous flow is not insurance; it is another untested release waiting for an emergency.
Rehearse the next release this week
Choose an upcoming feature and write the recovery sequence before distributing it. Install the intended build, create unfinished work, interrupt connectivity and disable the feature. Confirm what survives, what the user sees and how support recognises that state.
Run the supported older client against the proposed backend as part of the same rehearsal. Record any irreversible transition and assign an explicit decision to it. The release is ready when someone other than its author can follow the recovery note and restore a usable workflow without guessing.