macOS has a lot of work spent on it to ensure backwards compatibility between releases for software.

The situation would have been _far_, _far_ worse otherwise.

Nowhere to the degree as Windows or Linux. MacOS updates are very fragile and almost guaranteed to break software.

Linux on the desktop has far less backwards compatibility than macOS I'd argue. Yes the kernel <-> user space ABI is stable, but anything above that tends to be very messy on Linux.

It depends on what you use on their respective OSes. If you use your MacBook as an expensive Chrome/Slack/Netflix machine, I'd agree it's straight forwards to upgrade macOS. However there is a large range of very expensive professional apps that are pretty much guaranteed not to work on major version updates before the vendor also releases an upgrade, if they ever do. Avid for example. Or Ableton. There's a huge library of 32-bit x86 VST plugins that are now locked away from newer macOS versions due to it dropping 32-bit support.

A lot of hardware didn't get new drivers either, and macOS went and changed that around a few versions back. These are professional products, with many thousands of dollars invested into them, so the upgrade cost is often impossibly high. Hell, I forget the name of the movie, but it was cut on a version of Final Cut Pro (not X) that was five years old when the movie was cut. That editor held onto that their ancient un-upgradeable machine for dear life because that was the workflow they lived and breathed.

For 32-bit, interestingly Apple still maintains a very bare minimum (_not_ covering Mac GUI apps).

This has two customers today:

- on x86 Macs only: older iOS Simulators

- on x86 and arm64 Macs: x86_32 code segments (no syscall emu), for Wine to be able to run 32-bit x86 applications.

I think that the fragile base class problem might be what made Apple get rid of 32-bit x86 app compatibility at the end.

> A lot of hardware didn't get new drivers either, and macOS went and changed that around too

Yeah. KM drivers aren't exactly the most stable thing from release to release ever on macOS. And Apple has been steadily getting rid of those.

The player that actually cares the most about backwards compatibility on the desktop to an insane extent is Microsoft. 32-bit Windows editions (that are able to run 16-bit apps) are only gone in Windows 11. Apple still spends a lot of effort on it but not to the same extent at all.

Windows is better than average but still has considerable holes in backwards compatibility that are particularly visible in games (and ironically, some of the worst are Microsoft's own games under the "Games for Windows" banner e.g. Fable 3), but I've seen a number of other random things break or stop working totally as expected when new versions of Windows come out.

I’m not sure it’s fair to cite breaks due to hardware arch changes as evidence that the OS is bad at backwards compatibility. If anything apple has been better then average for compatibility across hw platforms, offering translation

The breaks I mentioned are just whilst on Intel though. The change to Apple Silicon assuredly broke an ton of stuff but I'm not even counting those.

DAW developers have historically advised users not to upgrade MacOS versions until it is explicitly supported and professionals in the space resist updates at all costs.

This is the only reasonable advice for any OS — DAWs are business-critical and every project is severely time-sensitive and you cannot rely on software vendors at any level of the stack to not break something.

Not in my experience. I've been using the same window manager and the same applications since before my current distro existed.

I bet compiled from source, while what is being discussed here is binary compatibility.

No, I use the distro packages, and have for quite a while now.

Binary compatibility matters less on Linux, true; what people are actually interested in on the desktop is usually UI compatibility, as in keeping the same look and feel and workflow. That's something Linux is a lot better at than either MacOS or MS Windows, both of which force you into new UIs with the shift of fashions and corporate buzzwords.

It is still not what is being discussed here, as binary compatibility across OS versions.

Compatibility through source availability (with the right to adapt) is a good strategy though.

I've used Linux and explicitly chosen open source software since 2004. There's not a single program I'd like to run that does not work today. I've never been bitten by any such compatibility issue.

Binary compatibility is crap though. You are likely to have issues if you try to use a package you found outside of your distribution's repositories for the specific release you use. I guess AppImage and things like this will improve this sad state of affair.

I’ve been using the same window manager on Mac OS X since 2001. It’s not really relevant to this discussion.

They are talking about old applications running on the new operating system. Not upgrading them in lockstep.

This is absolutely not true.

MacOS software is notoriously bad for backward compatibility. Windows is king in this department.

They usually give a very long notice when things are going so it would only be abandonware that breaks.

Agreed. I work on macOS professional apps in the video space and use professional apps in the audio space, and I can only think of 1 plug-in so far that isn’t working correctly on Apple Silicon machines. It looks like there’s an update on the website, but I haven’t had a chance to download it. It’s over 2 years since the first AS machines were released to the public (and probably 2.5 to 3 years since the dev kits were released).

For products I work on, we’ve done OpenGL to Metal, 32-bit to 64-bit, Intel to Apple Silicon. Sure it would be great to never have to change existing code, but it can be done. And most of the audio plug-ins I use are from pretty small vendors who seem to have made the same switches (admittedly, not much OpenGL/Metal use in audio plug-ins).

No, they do not. Where is this trope coming from? Catalina decimating gaming because of the removal of 32-bit support?

Apple doesn’t guarantee syscall compatibility between minor versions, either. You must dynamically link libsystem instead.