Congratulations, you just shipped this month’s first app update. It took you almost two weeks to get this out, and it sat under Waiting for Review on the App Store Connect dashboard for a good two days. Despite all the rigorous testing, you now encounter a critical, unforeseen issue in the wild—one that cannot be fixed through backend service changes.
It’s not a far-fetched scenario. Most app teams have experienced this, and currently, the only recourse is to go through the entire release process again: fix, build, review, and redistribute. It is time-consuming for developers, frustrating for users experiencing the broken app, and potentially damaging to the app’s reputation.
In the world of backend and web development, the ability to quickly roll back a faulty deployment is the cornerstone of robust continuous deployment (CD) practices. It serves as a safety net, enabling rapid iteration and confident releases. However, this capability is notably absent in the app ecosystem.
Rollback support, natively built into iOS, Android, and their respective app stores, would fundamentally change this dynamic. It would allow developers to instantly revert users to the previously released stable build in the event of a catastrophic failure.
As of today, app updates are controlled by the end user’s device. While this autonomy is beneficial for optimizing battery life, it also means that vendors lack a critical mechanism for managing app stability in production. Rollback support would not be about providing full autonomy over which app version is live on the user’s device; rather, it would be about maintaining a readily available backup. From the app store’s perspective, delivering a previously live build should be no different from delivering the current one. The challenge here is not technical but rather a matter of policy.
Addressing key concerns
Implementing such a system naturally raises several questions, particularly around data migration. Both iOS and Android already support running migrations on an app’s on-device SQLite database when an update is applied. Writing reliable migrations is the developer’s responsibility, and with rollbacks in place, developers would need to ensure that migrations are also backward-compatible. The assumption would have to be that any build could potentially be rolled back.
Another concern involves battery optimization and device storage. If rollback builds are not pre-cached, on-demand rollbacks could lead to increased battery drain as the device wakes up in the background to download the build. On the other hand, pre-caching would incur a higher storage cost, but the benefit of speed could outweigh this drawback. App stores already employ binary diffing for updates, and the same technique could be applied to rollback updates, minimizing network bandwidth and storage usage.
Security and abuse prevention must also be considered. To prevent misuse, app stores could monitor rollbacks and their impact on user experience rather than imposing arbitrary restrictions on developers. Excessive rollbacks could affect an app’s rating, incentivizing developers to maintain high-quality releases and conduct thorough testing. The goal is not to restrict rollbacks, but to encourage a culture of responsible shipping.
Prediction: native rollbacks in five years
The rise of frameworks with over-the-air (OTA) update capabilities highlights the limitations of native app deployment models. Both React Native (JavaScript) and Shorebird (Dart) support OTA updates, enabling faster iterations and bug fixes. This is only possible because App Store and Google Play make exceptions for interpreted languages and don't include compiled languages (Swift, Kotlin) when allowing OTA updates.
Historically, features like phased releases were absent in the early days of the app stores. It took years for them to be implemented, but they eventually were. Their adoption was driven by a vocal minority of developers (both large and small) advocating for them, as well as by the marketplaces’ incentive to help developers ship higher quality apps to users.
We wager a bet—or call it a lightweight petition—that popular app stores will officially support native rollbacks in the form of process or technical improvements over the next five years. Just as phased releases helped mitigate widespread issues by gradually rolling out updates, rollbacks represent the next logical step. The same feedback and incentive loops are at play here, and introducing them is a strategic imperative for Apple and Google.
Since mobile app infrastructure is centralized, they have almost a moral responsibility to upgrade their tools to match the reliability needs of today. By equipping developers with better systems and giving them a compelling reason to continue investing in official SDKs, they invest in the long-term health and quality of their app ecosystems.
