When a backup actually matters
You rarely need this for App Store apps — you can re-download previous purchases through your Apple Account — or for most vendor-managed updaters that keep their own rollback paths. It matters most for direct-download updates, where a new DMG or ZIP overwrites the app in /Applications and the old build is simply gone.
Option 1: Make a manual copy
- Quit the app you are about to update.
- In Finder, open your Applications folder.
- Select the app, press ⌘C, then paste a copy somewhere safe (an external drive or a
~/App Backupsfolder). - If the new version misbehaves, delete it and move your copy back into Applications.
Simple and reliable. The downside is that it is easy to forget in the moment, and copies pile up without versioning.
Option 2: Time Machine
If Time Machine is running, you already have historical copies of your Applications folder. To restore, open the app's folder in Finder, enter Time Machine, step back to a date before the update, and restore the older app bundle. This works well but depends on having a recent backup from before you updated.
Option 3: Automatic, per-app backups
The most reliable approach is to back up automatically as part of the update itself, so it never depends on remembering. macCurrent can create a path-aware backup of an eligible app immediately before a direct replacement update, keep a configurable number of backups per app (up to three per app identity), and restore from the app's context menu. Backup readiness, update history, and restore activity stay attached to the specific app you are reviewing.
See the security model for how backups, restore, and cleanup are scoped, or download the free beta, delivered as one universal app for Apple silicon and Intel Macs on macOS 15 or later.
How to restore an app safely
Restoring is the half people forget to practice. For a manual copy:
- Quit the misbehaving version completely, including menu bar components.
- Move the current app from Applications to the Trash. Do not merge or overwrite in place.
- Copy your backed-up bundle into Applications and launch it once to confirm it works.
Always replace the whole .app bundle; mixing files from two versions breaks the code signature.
For Time Machine, open the Applications folder in Finder, enter Time Machine, step back to a snapshot from before the update, and restore the complete bundle.
Check Gatekeeper before you trust a restored app
A restored bundle should still pass Gatekeeper's assessment. Verify it in Terminal:
spctl -a -vv /Applications/AppName.app
A healthy bundle reports accepted with a Notarized Developer ID source. Restored copies can carry a stale com.apple.quarantine attribute, and a bundle whose contents were changed will fail its signature check. If spctl rejects the app, do not force it open — download that version again from the developer instead. The same verify-first habit anchors updating Mac apps safely.
What an app backup does not cover
The .app bundle is the program, not your data. The state that makes an app feel like yours lives elsewhere:
- Preferences in
~/Library/Preferences, stored as property-list files. - Support data such as databases, plugins, and caches in
~/Library/Application Support. - Sandboxed app data in
~/Library/Containers, keyed by bundle identifier.
Updates normally leave this data in place, which is why bundle-only backups usually suffice. If the data itself matters, make sure Time Machine covers those folders too; a bundle copy alone cannot bring data back.
The downgrade caveat: data migrations do not roll back
Many apps migrate settings or internal databases to a new format the first time a new version launches. The migration is one-way: rolling the bundle back does not roll the data back, and the old build may refuse to open the migrated library.
Before a risky update to a data-heavy app, back up the bundle and its ~/Library folders at the same moment, and restore both together if you downgrade. Release notes usually flag migrations — one more reason to review an update before it auto-installs.
Frequently asked questions
Does copying the .app bundle back up my settings and data?
No. The bundle contains the program itself. Settings live in ~/Library/Preferences, and app data lives in ~/Library/Application Support or, for sandboxed apps, in ~/Library/Containers. If that data matters, back up those folders too; Time Machine covers them by default.
Will a restored app still pass Gatekeeper?
It should. Run spctl -a -vv on the restored bundle; a healthy app reports accepted with a notarized Developer ID source. If the check fails, the bundle was modified or corrupted, so download that version again from the developer rather than forcing it open.
Can I always downgrade by restoring an old app bundle?
Not always. Many apps migrate settings or databases to a new format when the new version first runs, and the old version cannot read the migrated data. For data-heavy apps, back up the app's data folders at the same time as the bundle and restore both together.