Should apps let you keep the old version?
You open an app to finish a familiar task. Overnight, an update has moved the controls and changed the workflow.
The new version may be better for someone starting today. For an existing user, it can mean relearning something that already worked.
Keeping the old version available gives people time to move. It also means the maker has two versions to maintain.
Should apps offer a way back, and for how long?
Think of one update you loved or regretted. What would have made the change easier?
69 views
Replies
Keep people's work safe, not the whole old UI. In Holina's editor every edit saves as a new version and the original stays put. That's cheap, and it's most of what people mean by "the old version."
A document can be safe while a familiar task becomes harder. If an export goes from two clicks to six, keeping the old shortcut could solve the problem without maintaining the whole old interface.
I think users should have the option to switch back, at least for some time.
A new version may bring better features, but familiarity matters too. Giving users time to adjust makes the transition smoother and builds trust.
The best updates improve the experience without making users feel like they have to start from scratch. 😊
a few weeks with an 'old layout' toggle and a clear end date feels fairer than forever. did the people who switched back in your tests mostly stay on the old one?
I haven't run that test. I'd ask what task made someone switch back, then watch whether they can finish it in the new layout. The number of people using the toggle alone won't distinguish familiarity from a workflow that got worse.
@al_kub fair point, asking what task made them go back tells you way more than a toggle count. thanks for the reply.
On mobile you often can't, which makes the transition matter even more. Store updates and over-the-air updates both replace the old version for everyone, so there's no version picker to fall back on.
What seems to work instead:
• Ship big workflow changes behind a setting for a few weeks ("try the new layout"), then make it the default
• Keep the old path reachable for one release, with a short note on where things moved
• Never break people's saved work or data with a UI change. John's point is the big one: protect the work, not the old screens
The updates people hate are usually the ones that move muscle memory without warning, not the ones that change a lot.
the same question gets sharper when the user is an agent. a person notices the moved button and pushes back.. an agent just calls the new version and carries on. 49 of 107 MCP server updates we measured changed the tools. for that case i'd keep the old approval as the reference and hold the call until someone looks. @al_kub would you let a deploy keep pointing at the old build until someone signs off?
I'd keep the last approved build serving while changes to tool permissions or behavior are reviewed. Approval should name the exact build so a later update can't inherit it. If the old build is unsafe, I'd pause the affected tool instead.