I remain unhappy with Apple’s passkey backup story. There’s little documentation about this, but from what I can tell:

• There are no automatic versioned backups. (Syncing is not backup because it doesn’t protect you against human error, bugs, or attacks.)

• Even if you have a Time Machine backup, it’s not possible to restore it to the same Mac without logging into iCloud. This could be a problem if your account is locked or compromised.

• Restoring it to a different Mac is impossible because the decryption key is stored in the other Mac’s Secure Enclave. Apple is protecting you from accessing your own backup, even though the keychain is already an encrypted file, protected by the password that you set. (And the Time Machine or clone drive that it’s stored on is probably encrypted, too.)

• The Passwords app can now export passkeys, but you cannot create an export file that you can import back into Passwords on another Mac. You can only export to a third-party password manager that’s installed on the same Mac (which may require a working Apple account). Even then, this does not include passkeys for Apple services; they don’t show up in the Passwords app. There are also some other restrictions around shared items and Sign In with Apple.

The above is last year’s news, but I don’t think I had written it all in one place before. The new bad news is that, as of macOS 26.4, these problems now affect regular passwords, not just passkeys. (You do have more flexibility to export passwords, though.)

Rich Trouton (Hacker News):

Historically, you could copy the login keychain file from one Mac to another and be able to open it on the destination Mac by providing the password to that keychain. As of macOS Tahoe, this does not appear to work for Macs which use Secure Enclave.

[…]

From that, it appears that unlocking the login keychain requires more than the password because the keys it unlocks are tied to the Secure Enclave of the Mac where the keychain was created. With the decryption keys stored in the source Mac’s Secure Enclave, manually copying the keychain to another Mac and then unlocking it won’t work. The password you have for the keychain may be correct, but the actual keys needed to decrypt its contents won’t be available on the destination Mac.

Jeff Johnson:

According to Apple, all Apple silicon Macs, as well as some Intel Mac models, have the secure enclave processor, so the issue affects millions of Mac users.

[…]

If anything happens to your Mac, if it’s stolen or becomes inoperable, your login keychain is also lost, unrecoverable, even if you have a copy of the login keychain file! This is a stunning development that has left me bewildered and irate. WTF was Apple thinking? To my knowledge, Apple did not even publicize the change in Tahoe.

[…]

How does Migration Assistant handle the situation on Tahoe? I don’t know. I would guess that since Migration Assistant still has access to the old Mac, it simply decrypts the old login keychain and copies the login keychain entries to the new login keychain on the new Mac, rather than transferring the keychain files directly.

[…]

I recommend that you open your login keychain with the Keychain Access app (now located in /System/Library/CoreServices/Applications) and check what’s in there, the data that you’re in danger of losing. Whether you realize or it not, many apps use the login keychain. For example, Google Chrome and other Chromium browsers store passwords in the login keychain. MailMate stores email account passwords in the login keychain. The open source RSS reader Vienna stores website passwords in the login keychain. The Zoom app also uses the login keychain. My Developer ID code signing certificate is stored in the login keychain; if I’m not mistaken, I believe that Apple’s own Xcode put it there. And of course, any items that you’ve manually added to the login keychain would be lost if the keychain file could not be unlocked.

Howard Oakley:

I have confirmed that a login.keychain-db copied from my Mac mini M4 Pro to a virtual machine (VM) running macOS Tahoe 26.6.2 cannot reveal any of its secrets to the Keychain Access app on the VM, as it refuses to accept the valid password. Not only that, but Keychain Access running in a VM cannot access the login.keychain-db keychain copied from another Tahoe VM, although neither has been anywhere near a Secure Enclave.

If you intend migrating manually between Macs, don’t waste time trying to copy across the login keychain, as it’s not likely to work, and its secrets will remain.

[…]

I performed test migrations between VMs, and demonstrated that Migration Assistant does copy the contents of the login keychain successfully to the destination Mac.

I think this only happens if you migrate over a network, with the old Mac acting as a server. I prefer to connect the old Mac using Target Disk Mode, but in that case Migration Assistant wouldn’t be running on the old Mac so the special sauce wouldn’t work. Likewise if I were trying to do the migration using a third-party cloning app.

Howard Oakley:

• Loss of physical access to a Mac running 26.4 or later prevents access to any items stored in its login keychain.
• Hardware failure requiring logic board replacement may have the same effect on restoring the contents of its login keychain (assuming that migration from a backup doesn’t work).
• Restoring an Apple silicon Mac in DFU mode may be similar in effect.

What I don’t know yet is whether you can unlock and access any login keychain written by macOS 26.4 or later and migrated from a backup accessed directly from a different Mac. This would occur in one-Mac migration, when Migration Assistant uses a backup of a Mac not acting as a Migration server. This would only be possible if the backup also stored the additional secret required to access the login keychain, which seems unlikely.

[…]

Apple’s documentation for macOS Tahoe and the copying of keychains makes no mention of this change, in spite of its serious consequences and the change being made almost six months ago.

It there states “If you didn’t use Setup Assistant, the best way to copy your keychains to a new computer is to export and then import them using Keychain Access”. However, Keychain Access can only export some keychain items including certificates and keys, but not passwords. And to do that, the Mac must be able to unlock and access those items in the source keychain. Thus, Apple’s recommendations are out of date and will now fail.

rsUSA0 (via Jeff Johnson):

When upgrading to macos 27 Golden Gate, I erased my system through recovery to do a clean install. I planned to manually migrate data back to the computer from an external drive clone of Macintosh HD and a Time Machine backup. This has worked well in the past and eliminated system bloat.

When I manually migrated my login keychain, it opened, showed entries, but it wouldn’t accept my password to reveal any actual passwords. The window shakes like I’m using the wrong password. I’m 100% sure I’m using the correct password. I also tried every password I’ve ever used and I’m certain it’s not a password issue.

Perhaps even restoring to the same Mac failed because the clean install wiped the key stored in the Secure Enclave. [Update (2026-10-01): See update below.]

Jeff Johnson:

Some people who read my previous blog post misunderstood the issue, because they didn’t know that the macOS login keychain is distinct from iCloud Keychain.

[…]

In the Keychain Access app, you can see two separate default keychains, one of which is the login keychain. The other default keychain is named “iCloud” if you’ve enabled iCloud Keychain, “Local Items” if not. There’s actually a longstanding issue with this keychain analogous to the newer issue with the login keychain.

[…]

Mac users like myself who forsake iCloud Keychain face the prospect of no disaster recovery for the Local Items keychain. My habit is to manually create a new password item in the login keychain and only then supply the credentials to an app, for example, Safari AutoFill. Ironically, the login keychain change brought by macOS 26.4 sabotages my password backup procedure[…]

jen1x:

Today, I got my new Mac mini M6. When I started setting up the new machine, it asked me to update to macOS 27, so I followed the instructions.

[…]

After signing in to iCloud, it asked me to enter the passcode of one of my Apple devices. I entered the correct passcode and even tried the passcodes for all of my devices, but I keep getting the same message:

Verification Failed
There was an error verifying the passcode of your iPhone

I don’t like having to rely on iCloud.

Previously:

• SuperDuper’s “Follow-Up”
• macOS 26.4
• 2025 Six Colors Apple Report Card
• Locked Out of Apple Account Due to Gift Card
• Downloading Xcode With a Passkey
• iOS and iCloud Keychain Are Hostile to Backups
• Passkeys Credential Exchange
• Passkeys: A Loss of User Control?
• Fixing iCloud Keychains, and Backing Them Up

Update (2026-10-01): TN3137 has been updated for macOS 26.4:

Historically each file-based keychain was a standalone file. You could, for example, copy a keychain file from one Mac to another and still use it, as long as you knew the keychain password.

In macOS 26.4 and later that’s no longer the case. A keychain file might reference a protected entropy file. To unlock such a keychain you need both the keychain password and the protected entropy file.

[…]

These protected entropy files are stored in /var/db/SystemKeys. If you’re creating a backup product, make sure to back up that directory. Without it, the keychain files that you back up might be useless.

[…]

The /var/db/SystemKeys directory is not directly accessible, even when running as root, so you can’t copy a protected entropy file in the normal way. To access it, disable System Integrity Protection (SIP).

First things first: I don’t think turning off SIP every time you make a backup is a real solution. And I don’t understand what problem Apple is really trying to solve with protecting the entropy file; it seems like they don’t trust their own encryption. Lastly, it’s not explicitly stated, but I don’t think copying the entropy file helps with backing up passkeys.

That aside, I find the details both illuminating and confusing. This probably explains the rsUSA0 case above, where restoring to the same Mac didn’t work. The key wasn’t stored in the Secure Enclave but rather in the entropy file on the SSD, which had been wiped. This also suggests a simpler way for Migration Assistant to work; it could have special access to copy the entropy file without having to actually open the keychain.

It also seems to be saying that, if you turn off SIP and copy the entropy file, you can then access your keychain backup from another Mac. But I’m not sure how to square that with Apple’s keychain documentation:

Keychain items are encrypted using two different AES-256-GCM keys: a table key (metadata) and a per-row key (secret key). Keychain metadata (all attributes other than kSecValue) is encrypted with the metadata key to speed searches, and the secret value (kSecValueData) is encrypted with the secret key. The metadata key is protected by the Secure Enclave but is cached in the Application Processor to allow fast queries of the keychain. The secret key always requires a round trip through the Secure Enclave.

How can copying the entropy file work if the Secure Enclave is required? My guess is that the entropy file itself is encrypted (NSFileProtection) using the Secure Enclave. So accessing it on the original Mac does require going through the Secure Enclave. But when you make a backup, the entropy file gets decrypted. Maybe accessing the keychain on the second Mac causes file protection to be re-applied to the contents of /var/db/SystemKeys, so then it becomes protected by that Mac’s Secure Enclave.

Previously:

• Accessing the Keychain Without the Password

Update (2026-10-02): Dave Nanian (Mastodon):

This is obviously not a good user solution, because no one is going to boot to Recovery, turn off SIP, back up, boot back to Recovery, and turn SIP back on. Thinking they would do so is kind of crazy.

[…]

SuperDuper handles this situation. When you make a bootable copy, the required keys are copied without requiring any special steps.

SuperDuper itself can’t read the entropy file, but it uses Apple’s asr tool to make bootable backups, and that has special access. (Unfortunately, it can’t update the entropy file without making a fresh bootable backup, but in practice I don’t expect it to need updating.) I had not been bothering to make most of my backups bootable, since in most cases I just want to restore to an internal SSD, not actually boot from the backup. But I now think it makes sense to choose bootable backups as the default.

Howard Oakley (Rich Trouton):

I won’t expand on my feelings any further than by saying that in my 37 years as an Apple developer, I have never come across anything so shameful.

Unfortunately, it seems like the keychain stuff was just the warm-up act.

Update (2026-10-05): Howard Oakley:

[macOS 26.4] Added the protected directory at /var/db/SystemKeys to backups of Data volumes, and protects them in backups.

So Time Machine does back up the entropy file. I missed this because I didn’t see /var/db in my backups, but it turns out that they do have /private/var/db/SystemKeys and are just missing the /var symlink.

Update (2026-10-07): Jeff Johnson:

The -s option to the security show-keychain-info is not yet documented in man security, not even on the latest version of macOS Golden Gate. Moreover, the -s option does not work on macOS Sequoia and earlier. In general, the security show-keychain-info command reveals no information unless the specified keychain is unlocked, which makes it impossible to discover the salt of a keychain file that you can’t currently unlock. However, as long as you already have the entire contents of the /var/db/SystemKeys directory from the macOS volume on which a keychain file was created, the inability to determine the keychain file’s salt beforehand shouldn’t be much of a problem, because in practice there are typically only a few salt files, so you can simply copy them all to another macOS volume.

[…]

You don’t actually have to disable SIP to add files to the /var/db/SystemKeys directory, because you can do so from another boot volume. You have to boot into recovery anyway in order to disable SIP, so you could simply edit /var/db/SystemKeys from recovery rather than disabling SIP on the non-recovery volume.

The security unlock-keychain command lacks an option to specify the location of an entropy file or to provide the file data directly, so unfortunately a login keychain can’t be unlocked from the recovery volume, only from a volume where you can add files to the /var/db/SystemKeys directory.

Maintenance update for the backup app with fixes for multiple network destination problems. ($43.95 new, free update, 34.8 MB, macOS 14+)

Apple (release notes, security, enterprise, developer, full installer, IPSW):

Explore what’s new for macOS 27.

The page is designed in an annoying way that requires sideways scrolling, and there doesn’t seem to be a PDF list of the new features like in previous years.

See also:

• Jason Snell
• Juli Clover
• Marcus Mendes
• William Gallagher
• Mr. Macintosh
• Reddit

Jeff Johnson:

There’s also a DEPRECATION NOTICE at the top of the man page that lists the diskutil replacements for hdiutil subcommands.

Patrick Wardle:

Fixed: launchd no longer supports loading launchd property list files with the quarantine extended attribute.

Dave Nanian:

[Even] though a bootable backup is properly configured to boot, they aren’t showing up as choices in either the startup disk preference pane or the startup picker. (FB24210103, reported quite a while ago, Apple friends.)

Previously:

• Golden Gate Release Candidate
• Preparing to Update to Golden Gate
• macOS 27 Public Beta
• Glow Leopard
• macOS 27 Golden Gate Announced
• macOS Tahoe 26

Update (2026-09-17): See also: Hacker News.

Andrew Cunningham (Hacker News):

Generative AI is unavoidable if you install macOS 27 Golden Gate. I’m being very literal: There used to be a toggle you could hit if you wanted to turn off Apple Intelligence and delete the gigabytes’ worth of AI models it would download to your disk, and now there isn’t. Apple Intelligence defines the Golden Gate release, in everything from its marketing to its features to the chips it runs on to the amount of space it takes on your disk.

[…]

More impressively, for apps that support it, the iPhone Mirroring window can now be resized dynamically while running apps. Apps will resize themselves to take up all the available space, and once the window is wide enough, you can even take advantage of multi-column iPad-style views for the apps that offer them.

[…]

For most Mac users, though, Golden Gate is a no-brainer update with few major downsides. It won’t hurt anything to wait until the 27.1 or 27.2 release if you’re already on macOS 15 Sequoia or macOS 26 Tahoe and you’re not in a hurry.

Juli Clover:

macOS Golden Gate: 10 Features to Try First

Paul Haddad:

Did Virtualization under 27 get hit with the slow stick? Trying to run a Mac VM on my M1 Ultra and it feels basically unusable. Getting Intel flashbacks.

Jeff Johnson:

In System Settings Privacy & Security, the Accessibility pane has been renamed to Device Control and Data Access.

Avi Drissman:

Have you been noticing that, starting with macOS 27, you have been consistently failing to SSH to a remote machine? Is it the case that the remote machine’s password ends with a shifted character?

There is a new setting: “Shift Return sends Meta Return” under Settings > Profiles > (profile) > Keyboard. This setting (enabled by default!) will cause a shift-return keypress to insert an ESC before the return is sent.

Rich Trouton:

As part of testing macOS Golden Gate, it was discovered by myself and others that MDM enrollment does not appear to completely work.

Adam Maxwell (tweet):

Golden Gate broke AuthorizationExecuteWithPrivileges such that spawned tasks no longer inherit PATH of the calling process[…]

Daniel Compton:

After upgrading to macOS 27 Golden Gate, my beloved copy of 1Password 7 started crashing every time I unlocked it.

[…]

If you’re planning ahead, you can disable Watchtower from Settings before you upgrade to macOS 27, but if you’ve already upgraded, then you’ll need to disable it with the following terminal command[…]

Update (2026-09-21): Benjamin Mayo:

Ever since updating to Golden Gate, my Mac now periodically makes a scratchy paper alert sound. No idea from what.

Chris Pepper:

Hopefully 1Password will upgrade v7 for OS 27 compatibility, but I can’t count on them fixing bugs in v7 — they’re pushing users to v8.

I found a ‘fix’ for this crash, but that command didn’t work (even after enabling Full Disk Access for Terminal so it could actually execute), and isn’t available on iPhone or iPad.

Nicholas Riley:

Golden Gate status: wow, the new menu extra/Control Center area is rough. Not just unpolished UI behaviors but multiple crashes. Hidden Bar is no longer functional and none of the replacements I found actually worked, while having about 100 features I don’t want.

System keyboard shortcuts also seem to be an area that weren’t well tested. My preferred screenshot shortcuts were ignored until I opened that section of System Settings, and some Siri thing created a conflict with Spotlight so I get both of them when I press ⇧⌘Space.

Previously:

• Golden Gate Liquid Glass

Update (2026-09-23): Jesse Squires:

macOS golden gate is still shockingly terrible in unexpected ways.

Steve Troughton-Smith:

I’m no math expert, but I’m pretty sure this doesn’t add up to anywhere near 16GB. I’ve only started seeing this dialog in the release build of macOS 27.0, despite running the betas all summer, so clearly there are some ghosts in this build

Mario Guzmán:

Okay… how do you

1. make everything super huge like the text and pictures… while
2. having way more empty space than you need AND STILL have to
3. truncate your text labels?

8 of the 9 text labels are truncated.

Can we please have designers who know how to design for DESKTOP software and NOT magazines/print?

Jeff Johnson:

There are a surprising number of behavioral bugs in Golden Gate. It's not just a superficial update. Apple is basically breaking AppKit.

Mark Lilback:

I reported a bug to Apple in May, found while building Alcove. Two OS releases later it still isn’t fixed. It has gotten worse with each one.

[…]

On the betas the whole window went blank after the Cmd-Tab: sidebar, content, detail pane, status bar, everything but the toolbar. On the 27.0 release it usually doesn’t wait for the Cmd-Tab. In 5 of 6 clean launches the window came up with only the toolbar drawn. Cmd-Tabbing away and back doesn’t fix it. It moves the sidebar’s first row up under the traffic-light buttons and leaves the rest of the window empty[…]

Jeff Johnson (Reddit):

Golden Gate Finder bug:

If you start dragging a file, the mouse scroll wheel stops working.

Jeff Johnson:

I’m seeing a bug on Golden Gate where main menu item titles are not displayed if the item is added to the menu after launch. Examples: the Safari Develop menu and the Profile menus of Chrome and Firefox.

Update (2026-09-24): Avi Drissman:

It’s bizarre that hiding a main menu item would hold the space rather then shift things over.

Jeff Johnson:

Search on Golden Gate is twice as good.

Update (2026-09-25): Ric Ford:

Randy Singer emailed us about printer and scanner failures following macOS 27 installation. Fortunately, there’s a fix: reinstalling Apple’s deprecated and removed Rosetta 2 emulation code[…]

Paul Kafasis:

We’re also already recommending upgrading your Mac to Golden Gate. The new OS includes several important audio improvements, and as a result, Golden Gate provides the best experience when using our apps. Below, you’ll find details on key bug fixes Apple included in MacOS 27.

pdfu (via Jeff Johnson):

Hidden behind a feature flag, the System Settings app can now be resized in any direction. You can make the app window narrower than the default too, or adjust the sidebar to get even more space.

Update (2026-09-28): Matt:

Steve Jobs would fire the entire company and replace them with AI if he was alive to see this

Collin Allen:

Turns out, Backblaze is half busted on macOS 27 and there’s no fix yet. Have to launch /Library/Backblaze.bzpkg/bzbmenu.app manually for now, it seems.

Update (2026-10-05): Karsten Kusche:

Kudos to 1Password for providing an update for version 7 on iOS and macOS to restore compatibility with this year’s operating systems!!

Dave Nanian:

Recent versions of xOS (that is, macOS, iOS, iPadOS, etc) have Data Protection Classes from A to D that get assigned to files and folders.

[…]

The thing is, though, is that these files and folders are inaccessible unless the user is logged in, and the screen is unlocked. A few seconds after the screen locks (or you log out), the keys are purged, and they cannot be read.

[…]

That means the files any application considers to be worth protection cannot be accessed when a backup usually happens.

[…]

You may have noticed that if you had an overnight backup, when you unlock your screen, a copy starts to run. It’s typically quite brief, thanks to ⚡️Turbo Smart Update, but it might surprise you anyway. […] During your overnight copy, SuperDuper kept track of the files that it couldn’t access due to their protection class. And now that it can access them, it’s making sure they get backed up.

This seems like the right thing to do. Time Machine also does it. A backup app should try to make as faithful a backup as possible. I kind of find it annoying, though. Sometimes it can’t do a Turbo Smart Update, and so the backup that should already be done may end up taking another 30 minutes or more. The best thing to do is schedule backups while you’re using your Mac to avoid SuperDuper needing to do such “follow-ups.”

I wrote some code to try to figure out which files I have that are using data protection. Interestingly, the URLFileProtection API seems to not work on macOS. I used the lower level getattrlist() instead. Nanian recommends fcntl(). I didn’t find any protected files that I actually care about, just caches and derived data from Apple’s own apps. But, in theory, Apple or a third-party app could be saving actual user data using data protection.

Previously:

• SuperDuper 4
• Launching Before UserDefaults Is Available
• Apple Addresses iOS Surveillance and Forensics Vulnerabilities

Dave Nanian:

The new version of SuperDuper is a ground-up rewrite, a tip-to-tail reinvention of what SuperDuper looks like, how it works, what it can do, and where I can take it in the future.

[…]

Documents have been retired and replaced with Copy Jobs, which are stored internally and organized by source. If you want to copy Macintosh HD, that’s where you start. Click, and you’re presented with one or more template copy operations, or you can start from scratch.

Configuration is done right inline by clicking bold, underlined link elements and selecting options from pop-ups. The effect of your choices is immediately reflected in What’s going to happen?, ensuring you know what to expect when you click Copy Now.

SuperDuper has been around for 22 years, and I’ve been using it since version 2 in 2006. Shirt Pocket had always been great about keeping the copy engine up-to-date with all the changes in macOS and its increasingly baroque file system structures. But the outward appearance of the app hadn’t changed much, aside from losing the brushed metal, and neither had the feature set. I know all too well how much work it can be as a solo developer just to keep an app working. Ironically, the better you are at adapting to the changing OS, hiding the complexity, and presenting a simple interface, the more it looks like you aren’t doing much. Actually, if you follow Nanian’s blog, you can see a fraction of all the stuff going on under the hood—tricky edge cases, macOS bugs, and undocumented behaviors that must be handled so that you can essentially just press a button and get a proper bootable backup.

Eventually, he found the time to rewrite the app, both the engine (which is faster and more robust) and the user interface (which is greatly expanded). My first reaction was: this is SwiftUI, isn’t it? And it is. You can just tell by the way the text reflows, all the different colored buttons and blobs, the hover effects, and how the design heavily emphasizes scrolling. (Like System Settings, it doesn’t remember scroll positions. Nor does it remember which disclosure triangles are expanded.) The keyboard navigation and focus behavior are off in places. For reasons I don’t understand, SwiftUI gets a lot of this wrong out of the box. In some cases, like the outline view for creating a copy rule, keyboard support was manually added and works as expected. But there are other places where arrow keys and type-selection don’t work. Sometimes I need extra clicks to get the proper focus. Sometimes the arrow keys scroll the window instead of changing the selection.

That said, this is one of the best SwiftUI interfaces I’ve seen. I think it successfully preserves the spirit of the app, making it really easy to configure things and see what’s going to happen, while streamlining the way documents/jobs are managed and expanding what you can do. It’s still essentially one window (plus a Settings with one checkbox), and you can still use it in the old way, but now you can also run multiple jobs at once and inspect their histories.

Click the Preview button and SuperDuper will run the copy without making changes and present you with a report that shows exactly what would have been updated, added, deleted, etc., had this been a real run.

This is great to have. If there are particular folders or files you want to check, you can browse the source tab of the preview to see what’s excluded or find them in the destination tab to see whether they would be added, updated, removed, or kept. The interface to browse this is a sort of columns view with only one column. It’s fast and easy enough to use, but keyboard navigation doesn’t work properly. I longed for it to be an outline view so that I could quickly expand an entire subtree and see at a glance which files would be changed. I also wished that it would show how much data would be copied.

SuperDuper 4 is much faster than before. And I’m not just talking 20% or 30% faster. Smart Updates are between 2x and, with the new Turbo feature, an order of magnitude faster.

It’s hard to benchmark such things, but my general impression is that this is true. The longstanding Smart Update feature copies only the files that have changed. This seems quite a bit faster than before and slightly faster than Carbon Copy Cloner. The new Turbo feature uses the FSEvents log to optimize finding such files. If macOS knows which folders might contain changes, SuperDuper can focus on those and not waste time scanning ones that are identical. When this works, it feels almost impossibly fast. SSD-to-SSD backups of my Mac’s boot drive will take 1–3 minutes instead of more like 20 minutes. This also seems to be faster than Carbon Copy Cloner’s similar Quick Update feature.

Unfortunately, for reasons seemingly out of the app’s control, sometimes Turbo isn’t possible. This can happen if you’ve modified the copy job or if there’s been a huge amount of file system activity since the last backup so that FSEvents doesn’t contain the necessary information. In such cases, SuperDuper will fall back on doing an old-school Smart Update. I found that excluding my destination drive from Spotlight made it much more likely that Turbo would work.

As much as I like Turbo, I don’t end up using it except for the daily scheduled backup of my boot drive to an always-connected SSD. For my other backups, I have multiple destination drives for each source, and I find that the user interface doesn’t scale so well to configuring a separate job for each. That leads to lots of scrolling. So, instead, I use just one job per source and select the destination I want before starting each backup. This counts as editing the job, so it won’t be able to Turbo, but I find that backups to slow spinning hard drives take a long time either way and are dominated by the copying speed rather than the scanning speed.

Successful and failed runs are shown at the bottom of the copy job, with color-coded dots that can be clicked to display details.

This is my favorite bit of interface design in the new version. It very compactly shows you the recent history for that copy job using the same format that’s used for showing the completion status of the most recent run. I can quickly see all the information I usually care about, and you can click a button to see more detailed information if necessary. The downside is that you can’t see as much information at once—or across multiple jobs—as if there were a dedicated log window, and it only shows the most recent 7 runs. But I think this tradeoff is well in keeping with the app’s spirit of making things simple and clear rather than offering every possible option.

The most baffling part of the interface is that after each backup completes or fails it shows an “Apple Intelligence Summary”. Much space is devoted to labeling this and to assuring you that none of your data went into the cloud. I just don’t see what the point of this is. 99+% of the time, my backup either succeeded or failed for a very predictable reason like running out of space. Why do we need AI for this? I trust the AI summary less than I would a hard-coded string from the developer. Perhaps in an obscure situation that the developer didn’t anticipate Apple Intelligence would be able to offer a useful interpretation, but I have yet to see that.

At a technical level, SuperDuper has been split into a “helper” or “server”, which runs the copy, and an interface, which is the part you interact with. That means that, once registered, you can quit the SuperDuper application and your backups will still run. They’ll even run if you log out!

It doesn’t much matter to me that it can back up without launching the app—I like to see its progress—but I appreciate the new architecture for scheduled copies. Schedules are now much better integrated into the app proper rather than being driven through AppleScript.

You can run any number of copies at the same time. If you have four backups you need to do, just click Copy Now for each, and they’ll all run simultaneously.

This is the most important new feature for me. I used to do all my clone backups with SuperDuper. But, over years, my backup needs grew. I now have five main source drives to back up. They are much larger than before, and APFS on spinning hard drives is really slow. Thus, the backups, even with Smart Update, can take a long time. That was a lot to manage with old versions of SuperDuper. Carbon Copy Cloner has long supported multiple simultaneous backups so that I could connect a bunch of destination drives, tell it to start, and when I came back they’d all be done. I didn’t have to be there to wait for each backup to finish and then start the next.

It was just so much easier, so I started using Carbon Copy Cloner for most of my backups. But I still liked SuperDuper and trusted its copy engine, so I continued to use it to do some of the backups of my most important drive (the internal SSD). I think it’s good backup practice to have redundancies, not just in terms of multiple physical drives and storage locations but also for the software creating the backups. Both are quality apps, but it’s possible that there’s a bug or a misconfiguration on my part that might prevent the copying of a file that I need. Why put all my eggs in one basket? Now that SuperDuper also supports multiple simultaneous backups, I’m using it for half the backups of all my drives. On one backup day I’ll do all SuperDuper backups, then the next time I’ll do all Carbon Copy Cloner backups. (I continue to use Time Machine and Arq for additional redundancy.)

If you try this, I strongly recommend writing down which app you used for each destination drive and then doing all future backups to that drive using that same app. And it works better to do the first SuperDuper backup with Erase and Copy rather than trying to Smart Update a Carbon Copy Cloner backup.

There are a variety of reasons for this, but the main one is the different ways that the apps deal with APFS snapshots. Both use snapshots on the source to ensure they’re copying from a consistent state. And both mark completed copies with snapshots on the destination. But the retention of the destination snapshots is very different.

Carbon Copy Cloner can keep them around essentially as long as you have enough free space. It can also prune them out of order, so that you have daily snapshots for the last month and weekly ones going back further. This is managed by the app, though you can also manually delete snapshots yourself using Disk Utility.

SuperDuper’s snapshots are automatically managed by the macOS. I’m personally less fond of this design because in practice the system will choose to clean up old snapshots almost right away. I can’t count on being able to restore from any backup but the most recent. To me, this is a shame because APFS supports multiple snapshots, and there’s plenty of space on the drive to store them, but I can’t use them. It’s just not a design goal of the app.

Again, this ties back to how SuperDuper values simplicity. If it made longer-lived snapshots that weren’t cleaned up automatically, you might get into a situation where you (or another app) wanted to add files to a drive and couldn’t because it seemed to be full. You’d have to understand snapshots or have an app that could delete the SuperDuper snapshots to free up space. Third-party apps aren’t supposed to delete snapshots belonging to other apps, which is why you don’t want to mix SuperDuper and Carbon Copy Cloner on the same destination. If the former needs more space to complete a backup, it won’t be able to purge snapshots created by the latter.

The status information for the backups that are in progress is shown right in the Sources section of the main window. You can see at a glance which drives are being copied and when they’re all estimated to finish. I haven’t found the estimates very accurate, so I’d prefer to see the start time and the percent complete. Flipping between multiple active jobs to check their detailed progress is kind of a chore, but if all you need is the summary information you can close the app and monitor it from the new menu bar icon.

SuperDuper 4 now supports copying to and from any file system the Mac supports. Using a “Photos” drive with both Windows and Mac that’s formatted as exFAT? No problem: you can copy it.

It can also copy individual folders rather than just entire volumes, if you drag them into the sidebar.

I’ve added Shortcuts support, so you can create a shortcut that runs before or after a copy, on success, or on error. Want to send an email on success or failure? Beep when copies are done?

[…]

Not only does SuperDuper let you call a shortcut from a copy—you can create, run, and check on a copy job from a shortcut!

There’s a lot of potential here, and the completion shortcut receives a bunch of JSON describing what happened so that it can make decisions about what to do. On the other hand, I would rather see AppleScript support, as I find Shortcuts confusing and inconvenient. I wish that common completion actions like sending e-mails were built into the app so that they were easier to set up. (You can choose to eject the drive, post a notification, or sleep the Mac without having to write a shortcut.)

In all the years SuperDuper has been on the market, we’ve never charged for updates and never even raised the price. That’s 22 years of free updates.

The Apple Silicon version was a paid upgrade, but you could run SuperDuper 3 in Rosetta with an old license and still get all the features.

Version 4 costs $43.95, with various upgrade discounts based on the purchase date. There’s no discount if you purchased before July 2020, but us old timers got so many years of free updates it was one of the best deals ever in Mac software. Regardless, it’s not a high price for peace of mind. The new version is, I think, a massive improvement, maintaining the spirit of the original while modernizing and expanding it.

I’ve already said that I use both SuperDuper and Carbon Copy Cloner. I think both are excellent—great apps with great customer support. With SuperDuper 4 they’re more similar than in the past, but they remain very different. If you must pick one, I would say that Carbon Copy Cloner is better if you want lots of options and control; if you want persistent snapshots, verification, copying of cloud-only files, or detailed logging; or if you have a very large number of backups. (It does have a Simple Mode, but it’s arguably too simple and limiting.)

SuperDuper is better if you care about bootable backups or want something simple but not too simple. There’s documentation, but you probably won’t need it because so much is explained within the app’s interface. It’s just really easy to set up a backup, see what it’s going to do, see what it’s currently doing, and see what it did before. Pretty much everything happens in a single window, without tabs or separate modes. SuperDuper is all about striking a good balance for most people, doing the right thing with a minimum of fuss.

See also: Adam Engst and Accidental Tech Podcast.

Previously:

• Parachute Backup Acquired
• Backblaze No Longer Backs Up Dropbox
• Carbon Copy Cloner 7.1.3
• SuperDuper 4.0 Beta
• CrashPlan Consumer Is Back
• ChronoSync 10
• Arq 7
• SuperDuper 3.1 Supports APFS Snapshots for Both Source and Destination
• SuperDuper and APFS
• Synchronize Pro X 4.1.1
• My New Backup Strategy

Update (2026-08-14): The developer wrote in to say that SuperDuper does try to remember the scroll position in the main window, just not across launches. With the current version, 4.0.2, I find that this mostly works but that it gets thrown off if I’ve expanded any of the triangles to see more details about the currently running job. Then my carefully positioned view will be shifted a bit when I come back to it. It’s hard to get this exactly right.

He also had a great tip about a hidden feature that can relieve some of the scrolling issues I encountered: you can click multiple times on a drive in the list of sources to have it jump to the next active job for that drive, scrolling it to exactly the right spot. When the sidebar has keyboard focus, you can also do this by pressing the Spacebar.

See also: Dan Moren.

Update (2026-08-20): SuperDuper 4.0.3:

For those with a lot of volumes, there’s now a sort control for the source list: you can alphabetically by type, or purely alphabetically.

There’s now an option in the sort pop-up that adds a few sections to the source list.

I like being able to separate the source drives from the destination drives. The update also improves VoiceOver support.

Update (2026-09-09): See also: John Gruber.

Previously:

• SuperDuper’s “Follow-Up”

Update (2026-09-16): SuperDuper 4.0.6:

Click the n copies running pill to filter to just those jobs. If you have a lot of copy jobs for a given source, you can filter the list with a click.

[…]

SuperDuper now picks a band size that suits the image’s size, balancing the number of bands with their size.

[…]

There’s now a third-party application, Open Backup, that can notify mobile devices (iPhone and Android) when backups run.

SuperDuper 4 might be the first backup app that tells you in plain English exactly what it’s going to do and what it has done. Developer Dave Nanian’s new “narrative” interface embeds documentation directly into the interaction model.