What can and cannot be rolled back after release, and how do you respond to a bad release: pause, flags, server changes and a hotfix?

25.3.3 · L5 · Interview

Predict first

A release crashes on launch for users with a certain data shape, and they have already updated. Which action reaches them fastest?

// A: roll the App Store back to the previous binary
// B: a server-side change or remote flag that avoids the broken path, plus a hotfix build
// C: wait for review of the next version only
  • A
  • B
  • C

Mental model. A printed book cannot be recalled from every reader’s shelf. You stop distribution, insert an errata slip, and issue a corrected edition. The recall plan is the errata plan.

Be clear about what is reversible. You cannot roll back an installed app: the App Store does not let you push an older binary as a downgrade, users who updated stay on the new version until a newer build arrives, and local data that a new version migrated stays migrated (Q331 and Q334: schema migrations only move forward). What you can control is exposure and behaviour. Before release, use phased release (Q432) and staged exposure so few people get a bad build. After release you have four levers. Pause the phased release to stop further automatic updates. Server-side switches: a feature flag or remote kill switch turns off a broken feature for everyone, including users on the bad version, within minutes and without review (see the flags question). Server compatibility: because old and new app versions both talk to your backend, a server fix can often neutralise a client bug (for example by changing a response) if the API was designed tolerantly. And a hotfix build, from the release branch with the smallest possible change, goes through the normal pipeline with an expedited review request if the issue is critical.

Prepare before you need it. Keep the shipped build’s branch, tag and .xcarchive with dSYMs, so a fix starts from exactly the shipped code (Q461). Maintain a minimum supported version mechanism (compare versions numerically, as the versioning question shows) with a soft prompt and a forced update for unsafe versions, a runbook with owners, thresholds that trigger a pause and a communication plan, and feature-flag every risky change so rollback means flipping a flag. Make migrations backward compatible (see the migrations question) so a rollback of the server or of a later app version does not corrupt data. After the incident, write down the cause, why it escaped testing and the process change, and add the regression test. The staff-level framing is that a “rollback plan” for a mobile app is really a containment plan: limit exposure, switch behaviour remotely, and ship the correction quickly.

The store cannot downgrade users. Server-side and remote switches act immediately on the installed version; the hotfix follows.

Common traps

  • Promising to “just roll back”. There is no store rollback; the plan has to be containment and a fix forward.
  • A hotfix that carries unrelated changes. Each extra change is a new risk; branch from the release and keep the fix minimal.

They might follow up with

  • How do you protect users already on the bad build? A remote kill switch, a server-side compatibility fix, and a forced-update path if it is unsafe.
  • What should be ready before every release? The tag, archive and dSYMs, a runbook, thresholds for pausing, and flags around risky changes.

Related questions

  • 25.3.1 What is the path from an archive to users: TestFlight internal and external testing, review, release options…
  • 25.4.1 How do you design feature flags and remote config for a mobile app: flag kinds, defaults, stable percentage…
  • 25.5.1 How do you make schema, API and data changes backward compatible: expand and contract, tolerant readers…
  • 13.2.2 How do you use SQLite safely and quickly: bound parameters, indexes, and schema migrations?
  • 21.3.2 How do you build a performance culture on a team: budgets, regression gates, ownership and release guardrails?
  • 23.5.1 How do you read a crash report, what do the exception types and Swift runtime messages mean, and how does…

← How does App Review work, what causes common rejections, and what are…