No other operating system works like this. Supporting older versions of an OS or runtime with a compiler toolchain a standard expectation of developers.

▲

akdev1l 5 hours ago | parent | next [-]

Plenty of operating systems work like this. Just not highly commercial ones because proprietary software is the norm on those.

From a bit of research it looks like FreeBSD for example only provides a stable ABI within minor versions and I imagine if you build something for FreeBSD 14 it won’t work on 13.

Stable ABI literally only benefits software where the user doesn’t have the source. Any operating system which assumes you have the source will not prioritize it.

(Edit: actually thinking harder MacOS/iOS is actually much worse on binary compatibility, as for example Intel binaries will stop working entirely due to M-cpu transition - Apple just hits developers with a stick to rebuild their apps)

▲

kelnos 5 hours ago | parent | next [-]

Yes, and this is a great reason why FreeBSD isn't a popular gaming platform, or for proprietary software in general. I'm not saying this is a bad thing, but... that's why.

> Stable ABI literally only benefits software where the user doesn’t have the source.

It also benefits people who don't want to have to do busywork every time the OS updates.

	▲	toast0 4 hours ago \| parent [-]
		FreeBSD isn't too bad, you can build/install compat packages back to FreeBSD 4.x, and I'd expect things to largely work. At previous jobs we would mostly build our software for the oldest FreeBSD version we ran and distribute it to hosts running newer FreeBSD releases and outside some exceptional cases, it would work. But you'd have to either only use base libraries, or be careful about distribution of the libraries you depend on. You can't really use anything from ports, unless you do the same build on oldest and distribute plan. At Yahoo, we'd build on 4.3-4.8, and run on 4.x - 8.x. At WhatsApp, I think I remember mostly building on 8.x and 9.x, for 8.x - 11.x. The only thing that I remember causing major problems was extending the bitmask for CPU pinning; there were a couple updates where old software + old kernel CPU pinning would work, and old software + new kernel CPU pinning failed; eventually upstream made that better as long as you don't run old software on a system with more cores than fit in the bitmask. I'm sure there were a few other issues, but I don't remember them ...

▲

charcircuit 4 hours ago | parent | prev [-]

You can still run x86 binaries on new macbooks. They don't stop working entirely. Using wine I can even run x86 windows binaries.

	▲	akdev1l 3 hours ago \| parent [-]
		They announced Rosetta 2 will be deprecated and eventually removed (MacOS 28?) By that point they already hit the developers enough to get them to port to aarch64 (arguably though this could be a special case because it is due to architectural transition)

▲

thescriptkiddie 5 hours ago | parent | prev [-]

what about mac os?

	▲	kelnos 5 hours ago \| parent \| next [-]
		macOS doesn't require developers to rebuild apps with each major OS release, as long as they link with system libraries and don't try to (for example) directly make syscalls. Apple may require rebuilds at some point for their Mac Store (or whatever they call it), but it's not required from a technical perspective. The one exception here is CPU architecture changes, and even then, Apple has provided seamless emulation/translation layers that they keep around for quite a few years before dropping support.
	▲	charcircuit 4 hours ago \| parent \| prev [-]
		The latest Xcode supports targeting back to macOS 11. This covers >99% of macs which is acceptable for most developers. https://developer.apple.com/support/xcode/