Mobile Production Operations

Build the mental model

Running a mobile app in production surfaces problems that never show up on a developer's own phone. You need visibility into which app versions crash, on which OS versions, on which screens, across a fleet of real devices you will never personally hold.

Version fragmentation is the next mobile-specific reality: your users are spread across whatever app version they last happened to update to, some of them years old. Your backend API must support multiple app versions calling it simultaneously.

• Optional update: a gentle nudge users can ignore.
• Recommended update: pushes harder without blocking use.
• Force update: blocks use of the old version entirely.
• Emergency security update: overrides normal caution for a real vulnerability.

Feature flags help here: shipped code can stay dormant until your backend flips it on, enabling gradual rollout and instant disable without a new release.

Mobile rollback is not instant like a web deployment -- once a version sits on a device, undoing it takes another release or a flag flip, not a redeploy.

BACKWARD COMPATIBILITY CHALLENGE
--------------------------------
BACKWARD COMPATIBILITY CHALLENGE
----------------------------------
v1 App (older, still installed)  ---+
                                     |
                                     +--> Backend API
                                     |      (must support
v2 App (latest release)          ---+       both versions)

Connect it to a real scenario

Set up crash monitoring before your first real release, not after your first bad one -- retrofitting it after users are already complaining means you have already lost the data from your worst incidents.

Configure it to capture app version, OS version, device model, and the screen where the crash happened, and explicitly scrub anything resembling a password, token, or personal identifier.

• Crash monitoring must cover app version, OS version, and device/screen context -- without ever logging sensitive user data.
• Your backend must support multiple app versions calling it simultaneously, since users update at very different times.
• Mobile rollback is not instant like a web deployment -- an installed version stays until replaced by another release or a feature flag.

Try the working example

function evaluateApiChangeSafety(change) {
  if (change.isBreakingChange && change.oldAppVersionsStillInUse) {
    return {
      safeToShip: false,
      recommendation: "Version the endpoint or support both old and new shapes until old app versions age out."
    };
  }
  if (change.isBreakingChange && !change.oldAppVersionsStillInUse) {
    return {
      safeToShip: true,
      recommendation: "No old versions depend on the previous shape -- confirm with real usage data before assuming so."
    };
  }
  return { safeToShip: true, recommendation: "Non-breaking change; ship normally." };
}

const riskyChange = { isBreakingChange: true, oldAppVersionsStillInUse: true };
const safeChange = { isBreakingChange: false, oldAppVersionsStillInUse: true };

console.log("Risky change:", evaluateApiChangeSafety(riskyChange));
console.log("Safe change:", evaluateApiChangeSafety(safeChange));

The risky change (breaking, with old versions still in use) returns { safeToShip: false, recommendation: 'Version the endpoint or support both old and new shapes until old app versions age out.' }. The safe change (non-breaking) returns { safeToShip: true, recommendation: 'Non-breaking change; ship normally.' }

Feature toggle - Wikipedia — How Mobile Apps Work