Howard Oakley:

Since High Sierra and APFS snapshots, accounting for purgeable space has been inconsistent and often misleading. I first reported this over eight years ago in Sierra 10.12.6 and High Sierra 10.13.3, and most recently three years ago in Ventura 13.3.1. This article looks at how this is handled now in Tahoe 26.6.2.

[…]

There is disappointingly little documentation on space management in macOS, and the closest Apple comes to defining purgeable space is in Disk Utility’s Help pages, where it’s stated to be “space that macOS can free up when needed by removing files from your computer (you can’t manually remove the files that are designated purgeable, but macOS removes them as space is required)”.

On the face of it, that includes cache files but not snapshots, as they can be manually removed in Disk Utility, as I’ve discussed in detail here. This is contradicted when using tmutil localsnapshot to make Time Machine snapshots, which reports that “local snapshots are considered purgeable and may be removed at any time by deleted(8)”, as deleted is the purgeable space and cache management service in macOS.

APFS snapshots can also be created by third-party apps that have the appropriate restricted entitlement. Apple doesn’t explain whether those too can be purged by macOS when additional free space is required.

Howard Oakley:

Before macOS will start copying a file to a volume, it checks whether there’s sufficient free space available. I believe this is normally performed by the FileCoordinator API in Foundation, and appears in the log with the subsystem com.apple.foundation.filecoordination.

If there isn’t sufficient free space to accommodate the file to be copied, deleted in the subsystem com.apple.cache_delete checks whether enough space can be freed by purging items known to be purgeable in the destination volume. deleted has a fixed set of services that can be called on to purge items, listed in /System/Library/CacheDelete.

[…]

Space-based purging of Time Machine local snapshots is unreliable. The reason for this is that Time Machine CacheDelete fails to report purgeable space when it’s available. Even when it does work, it can take nearly half an hour for Time Machine CacheDelete to recognise the appearance of purgeable space.

Sometimes you need to do it yourself with Disk Utility.

Previously:

• SuperDuper 4
• Tahoe Free Space Problems
• Purgeable Disk Space
• Purgeable Mac Apps
• Time Machine Evolution and APFS
• What You See in the Finder Should Always Be Correct
• Quantum Computing and APFS: Free and Used Space
• How OmniDiskSweeper Reports Free Space
• Local Time Machine Uses APFS Snapshots

Update (2026-09-03): Howard Oakley:

• When purgeable space is required, deleted (subsystem com.apple.cache_delete) first discovers purgeable space for each caching service, to determine whether it’s sufficient.
• If it is, and the decision is taken to purge caches, caching services are called on to free up space by purging their caches as required.
• Purging may then take place in phases until sufficient space has been freed.
• Purging is frequent during installation of macOS updates, even when there’s ample free space available.

Update (2026-09-08): Howard Oakley:

In the event that you’re caught out by circumstances, such as the combination of recent large snapshots and exceptionally large caches, macOS does try to manage as well as possible even when there’s just a few GB free. But once free space falls to around 1 GB you should see a warning notification.

[…]

From then on, most file operations, even creating a new folder, will fail. That applies to all apps, regardless of whether they handle those failures gracefully and warn you of the error. Actions like taking a screenshot start normally, but after their image has floated across the display, they just vanish and can’t be saved.

[…]

The worst combination of problems occurs when a Mac runs out of free disk space and physical memory at the same time. macOS memory management then wants to allocate space in the VM volume as its backing store for virtual memory, but in the absence of free space to do so, that fails and should propagate as a memory allocation error.

Update (2026-09-09): See also: Accidental Tech Podcast.

Apple:

In macOS 28 and later, the Mac OS Extended file system format will be supported only for volumes (disks and other storage devices) that aren’t encrypted. For future macOS compatibility, either decrypt or reformat any encrypted Mac OS Extended volumes.

I think Apple removed the user interface for creating such volumes way back in Big Sur. It’s not really surprising that they’re going away, although only offering a year of warnings seems rather aggressive. Many people delay updating to major OS versions or wait until they get a new Mac. There will be users that switch to a Mac that can only run macOS 28 and get rid of their old one before realizing that some drive they haven’t connected in a while won’t mount.

The other surprising part is that Apple’s options—reformat or decrypt—are not great. During the initial transition to APFS, macOS would transparently convert an encrypted HFS+ boot volume to encrypted APFS without rewriting any data. This functionality is nominally still available via the diskutil apfs convert command, but Apple hasn’t mentioned this or built an automatic upgrader GUI.

[Decrypting] doesn’t apply to encrypted Time Machine backup disks.

It’s obvious why. The old Time Machine format with hard links is totally different from the new one based on APFS snapshots. But this means that you’ll either need to buy a new Time Machine drive for use with macOS 28 or delete your backup history. Even if you keep the old drive, you’ll need an older boot drive or an old Mac in order to be able to access it.

Previously:

• Searching Time Machine Backups and Versions
• macOS 27 Golden Gate Announced
• macOS 27 to Drop Support for AirPort and Time Capsule Backups
• Removing Unwanted APFS Time Machine Backups
• Should You Continue Using HFS+?
• Time Machine Evolution and APFS
• SuperDuper 3.3 for Catalina
• APFS to be Mandatory for SSDs in High Sierra

Update (2026-07-24): Marcus Mendes:

Apple has now revised the page to add a third option, allowing users to convert an encrypted HFS+ volume directly to encrypted APFS without decrypting it first.

[…]

The company has also removed its previous instructions for decrypting the volume first, converting it to APFS without erasing it, and then optionally re-encrypting it.

Hammer:

Ignore Apple’s guidance and do not use Convert to APFS in Disk Utility for disk images.

The first encrypted HFS+ disk image I tried to convert that way failed and left me with an unusable disk image. If I didn’t have backups I’d have lost its contents.

It didn’t corrupt the disk images that I tried, but it didn’t work, either, instead failing with an error about expecting a GPT partitioning scheme.

Update (2026-07-28): Howard Oakley:

As encrypted disk images have never used CoreStorage, withdrawal of support for that has no impact on the continued use of any form of encrypted disk image, including those using HFS+ as their virtual file system.

This is a good point. Apple’s support page refers to “encrypted Mac OS Extended disks,” but the developer release notes refer to CoreStorage specifically. So this shouldn’t affect most encrypted disk images, which show up in Finder as unencrypted after mounting. The encryption is at the disk image level rather than at the file system level. However, I’m not sure that all encrypted disk images are safe. Presumably, a device image, which directly copies the blocks rather than the files, would still use CoreStorage.

Jason Snell, on The Talk Show:

[… Apple] decides to do a big feature. The circus comes to town, they build the feature, they launch it, they leave town, and that feature sits there.

And the problem is, there’s bugs, things are broken, and in Year Two, you’re like, “You’re going to fix all the things that were broken in the thing you shipped last year, right?” And in the last decade, I would say, a lot of times what happens is they just don’t. And if you’re lucky, they’ll fix it Year Three or Year Four, […] give it a polish.

The thing that troubles me most about Apple software quality in general is the feeling like they don’t have the people to own the thing that they launch. They build the thing that they launch, and then those people go off and do something else, and nobody is maintaining and improving the thing that’s there.

Via Marcin Wichary:

I think this is spot on, and said really well. Are you honest with yourself about resourcing and focus for right after the launch and then later on? Have you really thought about worst case and best case scenarios vis-à-vis bug reports, latency, user feedback, and craft/​quality however you define it? Have you actually started to make room for those outcomes ahead of time?

For me, an ongoing tension with Apple is Finder, so central to my (and I imagine many people’s?) use of a Mac, but rewritten at some point eons ago in a new framework that caused all sorts of problems, and then pretty much abandoned like a proverbial American city’s downtown.

Revealing files in the Finder and Mail’s table view sort indicators have been broken for me since Big Sur. Disk Utility still doesn’t work as well as before its El Capitan rewrite. But these aren’t even big new features.

Jeff Johnson:

This is what happens when you release major OS updates every year: you have to keep launching new features.

Previously:

• Glow Leopard
• Child Safety Features in appleOS 27
• Will Disk Utility Ever Work Properly?
• Remaining Issues in Big Sur
• Disk Utility in El Capitan

Update (2026-06-29): Jesper:

The issue really, that Jason pins down, is that it’s so easy to use incremental development, agile development, sprints, whatever, as a method to do the wrong thing. If you have a year-long schedule, it is easier to say “I will take care of the Finder”, and within the scope of that is a number of features that need be built, but there’s also room for ongoing maintenance. Within the confines of sprint planning, within a culture that sheepishly focuses on the wrong thing, or is obsessed by following the wrong number, or worries about the internal politics of appearing to not have it together, all of a sudden the same work, scheduled into 3 week long sprints, looks like poison.

I know of plenty of organizations that make this work. That have the maturity and discipline and culture to see bugs and defects for what they are, to allocate plenty of time to them and to focus extra time on them with regular intervals.