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.