hdiutil is deprecated in macOS 27 Golden Gate

Given xip has been deprecated for a long time now, yet still is the format Xcode is distributed in, I highly doubt hidutil will ever disappear from macOS. Apple just won’t really update it anymore, just like they haven’t changed xip (not like hidutil has seen any significant changes, but still)

It's in vogue to rag on Apple because of its size/influence/market cap. Annoying, very. They are hovering around 14% desktop marketshare. Is the other 86% fairing so much better?

I've used hdutil perhaps never.

So I guess ram disks are deprecated too? (AFAIR hdiutil was the only way to create them)

"Despite giving Apple 100% reliable steps to reproduce, they asked me if the issue still occurred in the latest beta, and if it does, then I should submit an iOS sysdiagnose." No one looked at your repro steps, and no one researched your bug. They're just looking to cull the bug list. If you don't respond immediately, your radar is closed.

Was the error visible somewhere through Console.app? This is a major annoyance for me with Cocoa/AppKit apps that basically have terminal usage secondary.

> To conclude, I don’t understand why hdiutil needs to be deprecated when the same functionality will live on in diskutil. For some reason, Apple seems intent on breaking longtime workflows and scripts.

Brother, it’s Apple. Any backwards compatibility is purely incidental.

> Yes, Apple requested an iOS sysdiagnose for a macOS bug

Dealing with Apple's labyrinth maze that is Radar/Feedback is an exhausting nightmare, honestly. It leaves users intentionally blind as to the state of any FB's they raise, and (presumably unintentionally) gaslights users who attempt to improve the state of Apple's declining software products by repeatedly asking them for spindumps/sysdiagnoses that will subsequently either be ignored (sometimes for years), or re-requested in a future release.

I gave up attempting to engage with it years ago. Apple don't want technical feedback unless it's P1 security.

I read this as hidutil and had a mini heart attack.

Pepperidge Farm remembers when they removed the Telnet client (and ntpd, and a half dozen other things) from the OS and didn't warn anyone.

Totally normal. March of progress. Old stuff goes away.

Agreed. seatbelt/sandbox-exec has been “deprecated” for many, many years yet it still underlies all of the system’s sandboxing and Claude et al. use it for their own sandboxes. (And so do I — writing seatbelt rules is the only chance I get to write lisp-flavored anything these days.)

Similarly, launchctl has long-deprecated subcommands. I initially tried using the new subcommands, ran into issues, and told myself I should have known the “deprecated” ones were the way to go, now and forward.

Was the error visible somewhere through Console.app? This is a major annoyance for me with Cocoa/AppKit apps that basically have terminal usage secondary.

This is only tangentially related, but libuv and mio's Windows implementations use the undocumented AFD readiness-based poll interface [1], since there isn't a documented readiness-based interface on Windows. The undocumented interface is now effectively stable since, among other reasons, Microsoft uses Tokio in some of its products.

[1] https://github.com/tokio-rs/mio/blob/master/src/sys/windows/...

> Yes, Apple requested an iOS sysdiagnose for a macOS bug

I gave up attempting to engage with it years ago. Apple don't want technical feedback unless it's P1 security.

I read this as hidutil and had a mini heart attack.

It's in vogue to rag on Apple because of its size/influence/market cap. Annoying, very. They are hovering around 14% desktop marketshare. Is the other 86% fairing so much better?

I've used hdutil perhaps never.

It's just not worth it for individuals to volunteer their time for the benefit of the world's most valuable company.

Brother, it’s Apple. Any backwards compatibility is purely incidental.

So I guess ram disks are deprecated too? (AFAIR hdiutil was the only way to create them)

Pepperidge Farm remembers when they removed the Telnet client (and ntpd, and a half dozen other things) from the OS and didn't warn anyone.

Gotta pump those metrics for the PMs

Sometimes I almost believe there are whole sections of the Apple Ring building where the employees are so immersed in IOS that they're unaware MacOS exists.

Diskutil has been around for over a decade and slowly getting features that hdiutil was missing.

Things change but this is hardly some sort of sudden rug pull by Apple.

Given Apple's reputation as of late, I was mildly shocked to learn that I could connect a SATA optical drive to my Mac with a USB-SATA bridge, right click on an image in the Finder, and tell it to burn the image to DVD. This is under the latest beta of macOS.

You can call it incidental if you want, but it generally takes some effort to ensure everything works. That's especially true when you consider how much has changed since optical drives were common.

As for other forms of disk images, such as software distribution, those are still a common thing in macOS.

Haven’t they actually done a relatively good job in this regard in many ways? I can still use my 12 year old MacBook Air. It’s not super current and not all apps work, but it’s actually still a decent Apple experience. Same with our old iPad. They kept it updated way longer than I expected.

Consumer electronics, what do you expect ...

Any reason to "upgrade"? I am still on Sonoma and don't see a point updating the system.

This is one of the things the new `diskutil image` subcommand mentioned in the article supports: `diskutil image attach ram://${size}m`.

Totally normal. March of progress. Old stuff goes away.

diskutil is for disks (e.g., volumes) while hdiutil is for disk images ("file system as a file"). They're not two versions of the same thing, so it doesn't make sense to dub deprecating hdiutil as "progress."

If diskutil actually did everything OP looks for that was available in hdiutil, that's correct. If you read the post though, you'll see that diskutil has many limitations compared to its predecessor.

Progress is when we make things worse just because we can.

Username relevant as always.

[1] https://github.com/tokio-rs/mio/blob/master/src/sys/windows/...

Gotta pump those metrics for the PMs

It's just not worth it for individuals to volunteer their time for the benefit of the world's most valuable company.

smells more like an auto-respond or ai-respond to extant issues. we will farm out reproducing this bug to the OG, both to save us time and because if they don't complain it must be a signal this isn't important anymore.

Progress is when we make things worse just because we can.

Username relevant as always.

If diskutil actually did everything OP looks for that was available in hdiutil, that's correct. If you read the post though, you'll see that diskutil has many limitations compared to its predecessor.

The former has been taking the latter’s job for years now.

Nobody really cares that they were originally for separate things.

Diskutil has been around for over a decade and slowly getting features that hdiutil was missing.

Things change but this is hardly some sort of sudden rug pull by Apple.

Consumer electronics, what do you expect ...

Sometimes I almost believe there are whole sections of the Apple Ring building where the employees are so immersed in IOS that they're unaware MacOS exists.

> Haven’t they actually done a relatively good job in this regard in many ways?

No.

Can't run current versions of any apps including Chrome, Edge, and Safari.

Meanwhile the hardware is perfectly fine and could run a supported version of Windows or Linux.

Call me when Apple has a "LTSC" version of their OS. (Spoiler: they won't, ever. Supporting Apple in an enterprise is nothing short of a nightmare.)

> It’s not super current and not all apps work

That's an enormous concession, relative to Windows or Linux.

You can call it incidental if you want, but it generally takes some effort to ensure everything works. That's especially true when you consider how much has changed since optical drives were common.

As for other forms of disk images, such as software distribution, those are still a common thing in macOS.

iPods and AirPort Express units from 20+ years ago still work in modern macOS too. Things have been shuffled around some (iPods are now managed with the Finder instead of in Music.app) but they still work.

I would agree with the idea that they're not bothered about breaking workflows, particularly those involving command line tools, but hardware compatibility isn't nearly as bad as the internet might have one think. Source compatibility isn't all that bad either, many ancient Objective-C/AppKit codebases can be made to compile in an evening. It's mainly binaries that break.

The former has been taking the latter’s job for years now.

Nobody really cares that they were originally for separate things.

Any reason to "upgrade"? I am still on Sonoma and don't see a point updating the system.

This is one of the things the new `diskutil image` subcommand mentioned in the article supports: `diskutil image attach ram://${size}m`.

Yeah, Apple is very weary of breaking user functionality. They'll just break your app's ability to run.

> Haven’t they actually done a relatively good job in this regard in many ways?

No.

Can't run current versions of any apps including Chrome, Edge, and Safari.

Meanwhile the hardware is perfectly fine and could run a supported version of Windows or Linux.

Call me when Apple has a "LTSC" version of their OS. (Spoiler: they won't, ever. Supporting Apple in an enterprise is nothing short of a nightmare.)

> It’s not super current and not all apps work

That's an enormous concession, relative to Windows or Linux.

I have had to get rid of several computers recently that will not run Windows 11. They weren’t 12 years old.

This is partially on third-party devs' shoulders. There are community-maintained backports of Chromium and Mozilla for old versions of macOS, which means it isn't strictly impossible, but Google and Mozilla just don't bother and cut off compatibility earlier there than on other platforms.

It's even possible to build Mac apps to run on everything from OS X 10.4 (2005) through macOS 27 (2026) across PowerPC, Intel, and Apple Silicon in a single binary. See XLD[0], which does exactly that.

[0]: https://tmkk.undo.jp/xld/index_e.html

> That's an enormous concession, relative to Windows or Linux.

Windows yes, but Linux... no, at least if it's open source.

Closed source apps that compile fully static, these tend to be stable and Just Run in my experience... but open source apps? Good luck trying to bring these to even compile 10 years afterwards without going through an insane dance with Docker...

On Linux, there aren't 'apps' that normal people want. Basic things like 'functional 1080p/4k Netflix' and 'commercial software' aren't really a thing.

I have had to get rid of several computers recently that will not run Windows 11. They weren’t 12 years old.

> That's an enormous concession, relative to Windows or Linux.

Windows yes, but Linux... no, at least if it's open source.

Yeah, Apple is very weary of breaking user functionality. They'll just break your app's ability to run.

[0]: https://tmkk.undo.jp/xld/index_e.html

While that's absolutely correct, you're arguing with a strawman. Take a look at the original quote:

   > I can still use my 12 year old MacBook Air. It’s not super current and not all apps work, but it’s actually still a decent Apple experience.

The point is I can run the latest Linux distributions and software on a 12 year old computer with no issues whatsoever.

You might be able to do that in Windows, if you bypass TPM and CPU requirements or if you stay with Windows 10 extended updates.

You won't be able to in macOS without OpenCore Legacy Patcher and a lot of faith in your God of choice.

Couldn’t agree with this more. Stuff I wrote 25 years ago for NT4 still actually works on windows 10 without a recompile.

The Linux situation reminds me of unix back in the 90s even across distributions.

>Closed source apps that compile fully static, these tend to be stable and Just Run in my experience... but open source apps? Good luck trying to bring these to even compile 10 years afterwards without going through an insane dance with Docker...

who cares?

when a closed source app fails the door is shut for good on self-remediation, unless you want to reverse engineer/break the law.

when an open source app fails to compile you can choose to put the time in to get the thing working. it's not a shut door, it's just a long path.

Frankly, I don't think it's practical to expect operating systems to continue to run binaries perfectly in perpetuity. It's an enormously burdensome expectation that holds development of the platform hostage.

Usually all it takes to keep one's software running on macOS is compiling against the latest SDK once every ~5 years. Depending on the nature of the app, source changes often aren't even required. As a dev I don't think that's too much to ask.

On Linux, there aren't 'apps' that normal people want. Basic things like 'functional 1080p/4k Netflix' and 'commercial software' aren't really a thing.

Netflix works, just not 4k. Blender and Davinci Resolve say there's commercial software, just not actual Photoshop.

That's another goalpost. That's because DRM doesn't go well with Open source.

Correct, you have just successfully identified the reason why Windows exists. Well done!

While that's absolutely correct, you're arguing with a strawman. Take a look at the original quote:

   > I can still use my 12 year old MacBook Air. It’s not super current and not all apps work, but it’s actually still a decent Apple experience.