Release Incident Playbook

Release checklist for mobile apps, built from published mobile incidents

Before a mobile release, launch the exact submitted binary on the oldest supported OS version, ship it as a halting-capable phased rollout, and prepare a workaround for each core flow. In 5 accepted public reports on store releases, recovery came from a fixed version that passed store review, not from a rollback. 2 other mobile release incident types stay withheld because fewer than 2 independent public reports were accepted for each.

8 cited public reports · verified 2026-10-21

Mobile incidents with public reports

Crash on older OS version is a release that crashes on an OS version still in the support matrix.

Crash on older OS version carries the labels "Likelihood: low (2 public reports in 5 years)" and "Impact: medium (2 of 2 reports: availability)".

App store rollback not possible is a broken build that cannot be reverted because stores do not support rollback and the fix needs review.

App store rollback not possible carries the labels "Likelihood: medium (5 public reports in 5 years)" and "Impact: medium (2 of 5 reports: availability)".

All sessions invalidated is a change to session signing or storage that logs every user out at once, and one of its accepted reports describes Android app users [8].

All sessions invalidated carries the labels "Likelihood: medium (3 public reports in 5 years)" and "Impact: medium (3 of 3 reports: availability)".

Deep link broken after routing change is a fault in which deep links or universal links open the wrong screen or nothing.

Deep link broken after routing change carries the labels "Likelihood: low (2 public reports in 5 years)" and "Impact: medium (2 of 2 reports: availability)".

Push notification token reset is a change that invalidates device tokens so that notifications stop.

Push notification token reset carries the labels "Likelihood: low (2 public reports in 5 years)" and "Impact: medium (2 of 2 reports: availability)".

API version dropped while old app live is a backend removal of an API version that installed app versions still use.

API version dropped while old app live carries the labels "Likelihood: not published (1 public report in 5 years)" and "Impact: medium (2 of 2 reports: availability)".

In-app purchase receipt validation fails is a rejection of store receipts after a validation or sandbox endpoint change.

In-app purchase receipt validation fails carries the labels "Likelihood: low (2 public reports in 5 years)" and "Impact: high (2 of 2 reports: money)".

Deep link broken after routing change, push notification token reset, API version dropped while old app live and in-app purchase receipt validation fails each have their own published incident page and pre-release checklist.

Mobile incidents withheld for lack of public reports

The playbook publishes an incident page only on two independent public reports from different organisations.

Forced update locks users out is withheld with 0 of 2 required reports.

Offline sync conflict after schema change is withheld with 0 of 2 required reports.

This guide gives no checklist items for the withheld types, because no accepted pair of reports backs them.

Checklist: launch on every supported OS version

Compatibility tests (the same flow across browsers, OS versions and device classes) list crashes on older OS versions among what they catch.

Compatibility tests cannot catch server-side faults or load behaviour.

A 2026 repository issue attributes a launch crash on iOS 17 and older to the build tooling, not to app code [2].

  1. Read the minimum OS version from the release build settings and confirm the device matrix includes a device on that version.
  2. Launch the exact binary submitted to the store on a device running the minimum supported OS version and confirm the app reaches its first screen.
  3. Rerun the launch test on the oldest supported OS after any update to the build tooling.
  4. Upgrade from the previous store version to the release build on a device and confirm the app opens without crashing.

Checklist: plan for a release that cannot be rolled back

End-to-end tests (user flows through the real UI against a deployed environment) cannot catch timing-dependent faults.

A 2026 status page report traces a split payment failure to a race condition in one app version [4].

Canary and progressive delivery checks (a small share of traffic runs the new version with automated metric comparison) take the form of a phased store rollout on mobile.

A halted phased rollout stops new installs, and in a 2026 report users were asked to update once the corrected version reached the store [3].

  1. Ship every store release as a phased rollout and name the person allowed to halt it.
  2. Confirm before submission that the named person can halt the phased rollout from the store console.
  3. Write a workaround for each core flow before release, such as completing the task on the website.
  4. Pause the phased rollout when the launch crash rate on any OS major version exceeds the previous version's rate.
  5. Assign an owner to read the public issue tracker and the support inbox for crash reports during the first day of the rollout.

Checklist: server changes that reach installed apps

A 2025 status page report states that a hotfix changed a secret key during a configuration clean-up and invalidated every logged-in session on Android and web admin [8].

The 2025 report states that token validation errors were suppressed and no alarm existed for surges in them [8].

  1. Compare the hash of the token secret key in the release configuration with the one in production and block the release on any difference.
  2. Alarm on the rate of token validation errors per minute and confirm the alarm is not suppressed.
  3. Log in on the installed app before a server deploy and confirm the same session still works after it.

Worked example

A status page report from 2026 states that iOS app version 126.8.0 did not launch for users on iOS 16 [1].

The fixed version 126.8.1 in the 2026 report was released the next day [1].

A repository issue from 2026 reports that version 346.260428.0 crashed on launch on iOS and iPadOS 17 and older [2].

Users in the 2026 repository issue report that rebooting or reinstalling did not help [2].

In the 2026 repository issue, a user bug report on the public issue tracker on the day the version reached users was the first signal [2].

A status page report from 2026 states that the team stopped the rollout of an iOS release that broke email login links and submitted a hotfix for store review [3].

The hotfix in that 2026 login report was available about two days after the first report [3].

A status page report from 2026 states that app version 26.22 closed legacy split payment orders without payment confirmation [4].

Hotfix 26.22.1 in the 2026 split payment report shipped the next day [4].

A status page report from 2024 states that a fixed iOS version 26.2.2 was held in store review before release [5].

A status page report from 2022 states that inspection items froze in app version 4.8.3 [6].

Users in the 2022 report were directed to the website until a hotfix passed approval [6].

A status page report from 2024 states that camera roll photos stopped displaying in app version 10.50.0 until release 10.51.1 [7].

None of reports [1] to [7] names a test class, so the caught-by entries on the crash on older OS version and app store rollback not possible pages carry the by design analysis label.

Public reports cited

  1. [1]Patreon, 2026-02-19. Patreon iOS app version 126.8.0 did not launch for users on iOS 16 until a fixed version 126.8.1 was released the next day. primary App launch failure on iOS 16
  2. [2]Tuta, 2026-05-01. After the Tuta Mail iOS update to version 346.260428.0 the app crashed on launch on iOS and iPadOS 17 and older; a maintainer attributed it to a bug in Apple's build tooling and directed users to the browser until a fixed build shipped. primary Version 346.260428.0 crashes on iOS/iPad OS 17 and older
  3. [3]Spendesk, 2026-09-21. A Spendesk iOS app release stopped email login links from completing sign-in for some users; the team halted the rollout and waited for Apple to review a hotfix, which was available about two days after the first report. primary Login : iOS Email Links Not Completing Sign-In
  4. [4]Lightspeed, 2026-06-03. In Lightspeed K-Series app version 26.22, orders using legacy split payments closed without payment confirmation; the fix waited to become available on the App Store and shipped as hotfix 26.22.1 the next day. primary K-series: Legacy Split payment issue with app version 26.22 only
  5. [5]Twilio (Authy), 2024-10-16. The latest Authy iOS release crashed on open for some users; the fixed version 26.2.2 had to pass App Store review before release, and users recovered only after upgrading to it. primary Latest Version of the Authy App for iOS Is Crashing
  6. [6]Fleetio, 2022-07-25. Inspection items froze in Fleetio Go version 4.8.3 on iOS; the fix went through QA and Apple approval before release, and users were directed to the website in the meantime. primary Fleetio Go 4.8.3 on iOS users experiencing unexpected behavior when completing inspections
  7. [7]Seesaw, 2024-11-07. Camera roll photos stopped displaying in Creative Tools in Seesaw iOS app 10.50.0; the fix waited for Apple approval and shipped in 10.51.1 while workarounds were sent to customers. primary iOS 10.50.0 - Camera Roll Photos Not Displaying
  8. [8]Mews, 2025-04-11. A hotfix for a TLS issue changed a secret key during a configuration clean-up, which invalidated every logged-in session on Android and web admin and forced all users to log in again. primary Login issue on Mews POS app

Questions

Can an App Store release be rolled back?

In all 5 accepted reports on app store rollback not possible, recovery came from a fixed version that passed store review, not from a rollback. In a 2026 report the hotfix was available about two days after the first report [3].

Does a staged rollout replace testing?

A halted staged rollout stops new installs but does not repair installed copies. In a 2026 report, users were asked to update once the corrected version reached the store [3].

Which test catches a crash on an older OS version?

Compatibility tests list crashes on older OS versions among what they catch. A launch of the exact submitted binary matters, because a 2026 repository issue attributes one such crash to the build tooling [2].

Why does a mobile release need a workaround plan?

The fix for a broken store build waits for store review. A 2022 status page report directed users to the website until a hotfix passed approval [6].