Yup, but only on the hardware side. On the software side, you are entirely at their mercy - unlike Windows which goes to utterly ridiculous length to keep software dating back to the Windows 95 era running on top notch Windows 11 systems, Mac developers are all too used of having to constantly keep up with whatever crap Apple has changed and moved around this time.

I've tried running old Civ2 on a recent windows machine, no dice.

I'm sure it's possible to do that, but the backwards compatibility on Windows is definitely not as good as you say.

That said, I'm also currently, as a fun personal project, converting a game originally intended to work on 68k Macs and which still has parts explicitly labelled as for resource forks, and I've lived through (and done work on) 68k, PPC, Intel, and M-series hardware, plus all the software changes, so I agree with you about Apple.

I think there is a x64 patch you need to apply

This gave me a flashback of me as a kid messing around with the "resource fork" of Mac applications. I felt like a major hackerman back then. During the era of "free" dialup ISPs, I would effectively remove the giant ad banners they all had.

Civ2 was 16-bit... did you try running it on 32-bit Windows 10, or only on 64-bit?

Windows, huh?

Pulled shenanigans wrt TPM requirements for Windows 10 and 11. Actively trying to make sure people login to a Microsoft Account and making it hard to use Local Accounts.

> Mac developers are all too used of having to constantly keep up with whatever crap Apple has changed and moved around this time.

Mmm...

  Win16 API
  Win32 API (including variants like GoodLuckSystemCallExExEx2W(...))
  MFC
  ATL
  .NET WinForms
  .NET Avalon/WPF
  Silverlight
  MAUI
  ...

The thing is, MFC/ATL are _still_ supported. With the last release in October, 2024. And the Win32 API is so stable that people are joking that it's the only stable API on Linux.

.NET technologies... Yeah, MS dropped the ball there.

For what it's worth I'm running Mac mostly, outside of ham radio stuff because there's just so much stuff that only is available on Windows.

The thing with all the mentioned APIs is that, excluding 16 bit stuff (that got yeeted in Win7 x64, but if you did need it you could run W7 x32), you can still run software using them without too much of a hassle and you most probably can compile it if you need to fix a bug.

Good luck trying to get a Mac game from the 90s running on any Mac natively without an emulator/VM in contrast.

Yup. I was amazed that I could still run software I wrote as a teenager decades ago and it just worked.

Sometimes it just works, sometimes not quite. If that were always true, they would not have had to ship things like XP Mode[1].

[1]: https://www.youtube.com/watch?v=jUStjHO-E8A&t=9

What are you talking about? macOS 26 still runs on 2019 x86 Macs.

It does feel like planned obsolescence when companies like Apple limit software support for older hardware, Ubuntu run smoothly on much older devices. They could certainly do better by extending support and focusing on sustainability.

I think they announced it's the last version that will run on any x86.

That doesn't really have anything to do with planned obsolescence. Causing churn for developers is not intended to make people buy more Macs before they should need to, which is what planned obsolescence means.

A piece of software I got in 1995 (Earth Siege) is reasonably playable on a modern PC, no VM, no emulator, it just works (albeit with requiring compatibility mode).

No piece of Mac software anyone has bought in the late PPC Mac era can even run (!) at all natively on a modern Mac, and even early Intel Mac software will not run on the last Intel generation ever since macOS dropped 32-bit support in userspace entirely. You need to pay the developers for a new version, that's obsolescence by definition and particularly I'm still pissed about the 32 bit removal as that also killed off WINE running 32 bit apps which, you can probably guess, include many games that never got a 64-bit Windows binary because they were developed long before Windows x64 became mainstream (or into existence).

I do love Apple for high quality hardware, but I'll stick the finger to them till the day I die for killing off WINE during the Intel era for no good reason at all.

I understand all that. Nevertheless, it has nothing to do with planned obsolescence.

> You need to pay the developers for a new version, that's obsolescence by definition

Sure, but you don't have to pay Apple.

The entire point of the idea of planned obsolescence is companies intentionally making their products last less time than they should, so you have to pay that company more money.

This is a company making it so you might have to pay other companies more money, because backwards compatibility isn't a priority for them. You can be annoyed by that, sure, but it is not the same thing, and is not obviously corrupt like planned obsolescence is.

The churn means software eventually stops working on whatever macOS version your hardware EOL'd on. For example, builds of Firefox and Chrome deprecate older macOS APIs, therefore they can't run on older versions of macOS. This eventually happens for everything, including Homebrew.

Is there an argument that, in actuality, this has been to their detriment?

I'm just asking the question.. ;-)

There are tons of applications that strictly don't run from even windows 7 era. Some games work with a couple hours of looking up fixes and patches, some not even then. Interestingly I've been pretty succesful with wine/proton on those