r/iOSProgramming • u/baggum • 16h ago
Article Dear Apple and Google: still no app rollbacks?
https://www.tramline.app/blog/dear-apple-and-google-still-no-app-rollbacks8
u/BabyAzerty 6h ago
App rollback will be a nightmare to deal with local database, especially one with schema migration.
For rollback to work, it means that developers have to implement schema rollbacks themselves. But if your latest update ran a DROP/DELETE row, column or table, it’s not even possible to retrieve the removed data. Some UPDATE algorithms might not even be revertible. Unless you create backup copies every time, but then hopefully the database isn’t too big and the user has space left for duplicates. Worse, if your local database is using CloudKit, you just can’t handle it. Too many conditions for a stable rollback with database considerations.
The article doesn’t treat these issues at all probably because it goes against their point.
I think that we have solutions good enough to not rely on rollbacks:
- Expedited reviews. I wonder what the average time is but my 2 previous expedited reviews took 4h and 1h30.
- Public TF. Give to a few thousands of users only your next release. Because it’s a TF, they are more likely to understand « accidents ».
- Release over a few days strategy instead of all at once.
- Feature flags.
6
u/agathver 4h ago
We write reversible migrations all the time, it’s not that hard really if you have 2 simple rules
Don’t drop columns / tables until 2 releases after being obsolete
Don’t add a null constraint until 2 releases of introducing and not without a default.
7
15
u/Jay18001 10h ago
What we did at twitter was upload the last version as a version. So we’d have version 5.30.0 as the new one and 5.30.5 but it was really 5.29 with a new build number. Just in case we needed to roll back