[Feature Request] Previous Installed Version App rollback (aka Last Known Good / Version N-1)

As Homey Pro user (Owner) I want to have an option to roll an App update back to the previously installed version just by going to the App settings and select rollback.

A new (test) update release for a Homey App can have 1000’s or even many more installs rolling out to Homey Pro’s that have Auto Update ON by default. A buggy Release can have impact in a large group of Homey Consumers.
Even if it is a Test release, it can happen that the normal release is a couple of versions behind missing support for new devices preventing users to Fix it with installing (downgrading) to a regular version.

Both Community developers, 3rd Party official’s as Athom Developers have proven to release once in a while a version with unintentionally serious bugs bricking (partially) the Homey’s automation for many users.

Currently Community members are teachting users to CLI install older versions that have to be pulled from Github (if Available). This also breaks the Auto-Update on that App after successful CLI installation until the user updates to the App Store version again.

As the title says:

Previous Installed Version App rollback (Last Known Good / Version N-1)

On (automatic) update the Previous installed App (and possibly App Settings) on Homey should be preserved for rollback.

Working out:
In App Settings a Homey Owner should be able to roll back to that previous version by selecting [RollBack Last Update] and it should also prevent updates to that latest version and/or fe for a set timeframe.

  • Preventing Auto-Update to the rolled back update should prevent a second same issue. (Blacklist the last update on that Homey instance)
  • Preventing Auto-Updates for fe 7 days prevents the user from being part of multiple updates that could follow from the Developer/publisher to fix the issue’s.
    A Timeline notification could inform the user about this.
  • If a New (Automatic) update comes it should not overwrite the Rollback version options that is less than 7 days old. (preventing multiple broken updates in short time (Developers publishing 8 versions in one day) to overwrite the Last Good version .)
  • Updates pushed from the Homey App Store should update the (running) app, that user-action just creates a Previous App Version if not available of older than 7 days.

This option should give users a better option than disabling Auto-Update on every App (and missing manny good break-fixing Update releases) and keeping Auto-Update on.
A Rollback should also rollback the App settings from the saved Previous Version. (For App compatibility)

This makes impact of broken updates less for Homey Pro Users as they can easily roll back an update is it breaks the App functionality.

This needs updates op Homey Pro Firmware (Both Local Platforms) and the Frontend (Mobile App and/of WebApp).


  • App Updates breaking Device configurations probably will will be broken after App Rollback. But Re-pairing should than work.
  • A Restore from Homey Cloud backup doesn’t install the Previous version making App-Rollback unavailable.
  • Growth of the used Storage Space - Twice All Apps can consume some extra space, Compression of data and/or automatic cleanup by making Rollback only 7 -14 days available after it will auto-remove can be an option to keep Storage impact minimal.
  • Impact on Developer Tools / App Install

I welcome specific all Community Developers, Official Developers (I know fe these active here: @Automate_Asia, @drenso , @Tibber_DE ) to comment on technical possibility or risks that I missed above when updating Apps and making a Rollback by users available.

I hope some positive feedback from Developers,
maybe we can then present this FR to Athom.
Other suggestions to fix the issue for affected users if Developers push accidently a breaking (buggy) update are also welcome.


Totally agree!

Totally agree, even I have had a test release go out and suddenly hundreds of crash reports coming in. This means I must drop everything else and work on a hot fix the soonest.
Rolling back to previous would give more time for a better fix than something quick.


If this rollback is present, every user must do this. And later all users must go back to stable version. I can’t imagi e how this should work.

What about ‘deactivating’ the latest app version and activating the previous version in developer tools? Like reverting a review request.
The autoupdate functionality mut be changed to take care of this and autoupdate to the previous (current active) version.

I wonder if the easiest wouldn’t be simply kind of mechanism :

  • stable (/)
  • beta (/test)
  • experimental (/experimental) new

Ideally with some switches on base - (stable) - URL. Nowadays many people don’t know there is some test version available, on the other side people do not know they can switch easily (naturally unless due to the underlying changes app is not backwards compatible).

Naturally all what Dijker wrote make sense just I’m not sure if it’s intended “Athom” way :wink:

1 Like


Correct, the user detects that he has a problem and roll back.
Often a buggy Release only has issue’s for a part of all users (Specific Device,/Configuration)

The User has a problem after a Auto update.

The Developer can be offline… Partying … and then, maybe only a couple of user want to Rollback, not all users.

Also a experimental can give issues, and the groups will probably smaller, but hitting you as a tester and having no option to roll back only to switch channel.

And if the smaller experimental group didn’t find the bug, and you do…
How do you revert to the previous installed app?