Comment Harder than it sounds (Score 5, Insightful) 199
I've been in charge of update deployment and strategy for several companies now. There's a few issues that come into play when deciding whether an update can be reverted or not. For a trivial app that doesn't maintain much data there's no real issue. Anything that does maintain real data, you must determine whether the database schema change between version A and version B is backwards compatible so that you can roll from B back to A. If the database schema change is incompatible, then you can't roll back. Same thing with on-disk data formats in general. I have Fedora 20 installed on one of my systems. If I wanted to roll back to the previous Centos 6 I couldn't, because the XFS file system format changed between 2.6.32 and 3.12. Centos won't mount Fedora 20 XFS filesystems.
Then there's binary compatibility issues. One release of one employer's software was based on Fedora 7 with a lot of modifications (different kernel, various applications updated, etc.). The next major release was, due to a gigantic change in hardware architecture for their newest systems, based on Fedora 13, including a major version update to Postgres for the database. The upgrade process runs out of a special imaging initrd and consists of save off the database with pg_dump to a couple of data drives, wipe out the base OS, plop on the new base OS, install the new application layer on top of the base OS, and restore the database with pg_restore. The pg_dump and pg_restore are necessary because the binary format of Postgres databases changed between the two different versions of Postgres. Downgrading in this case is impossible because the older version didn't know how to do pg_dump and pg_restore, since its previous releases had used the same antique version of Postgres (a version so old it wouldn't even compile under Fedora 13).
Finally, there's the question of whether an update scheme even has provisions for forcing arbitrary versions. The ones I've designed did, mostly because they were for very large data storage appliances where you didn't want anything updating automatically because scheduling a service outage for the update is a Big Deal for big data storage systems and where you needed the ability to roll back to the previous version if the update happened half-baked (if, say, the power supplies both blew out halfway through the update and left it only halfway on the disk). So you had to manually select which version you wished to update to, based on a list of what was compatible with your hardware and current installed version. But it appears to me that Apple has no such ability within their App Store interface. They make only the latest version available, period, even if it isn't compatible with your older iDevice.
So: Being able to roll back to the older version of the software is a lofty goal. But sometimes it just isn't feasible. On our web application once the database format has been updated to a new incompatible schema and new data is flowing in, there's no going back -- even though we saved off a copy of the old database before doing the database schema change, going back would discard all the new data that's flowed in since. So we cross our fingers, run it in parallel with a clone of the old system's data stream for a while to assure ourselves it won't blow up, and test the bleep out of it before cutting it over as the active version. Because once it's been in service for over a couple of hours there's no going back -- people may tolerate losing a few updates, but not days worth.
That said, when I had my Europa Universalis IV save games wiped out by an update to EUIV that Steam auto-updated without my consent or knowledge, I certainly was peeved! I should have at least been given the opportunity to *not* update, which even Apple gives you. That would have allowed me to spend a couple of days researching the update and waiting for people's feedback on whether it was worthy or not. Instead... sigh. So it goes.