The M1 chip and Rosetta 2 were introduced in 2020. macOS 28 will be released in 2027. 7 years seems like plenty of time for software vendors to make the necessary updates. If Apple never discontinues Rosetta support, vendors will never update their software to run natively on Apple chips.
This is also consistent with Apple’s previous behavior with backwards compatibility, where Apple would provide a few years of support for the previous platform but will strongly nudge developers and users to move on. The Classic environment in Mac OS X that enabled classic Mac OS apps to run didn’t survive the Intel switch and was unavailable in Leopard even for PowerPC Macs, and the original Rosetta for PowerPC Mac OS X applications was not included starting with Lion, the release after Snow Leopard.
Honestly, for apple this is above and beyond. They've killed support with less fanfare and compatibility support than what we see here.
Bully on me for owning hardware and expecting it to behave consistently across OTA updates.
The hardware isn't (as far as I'm aware) changing. Please don't move the goalposts for hardware ownership (we just be able to do with our hardware as we please) to also include indefinite support from vendors. That just makes us looks like childish crybabies.
If you were instead asking for hardware documentation, or open-sourcing of Rosetta once sunset, then we're on the same team.
I never asked for an infinite window of software support, though. I merely want the features that I had when I bought the laptop, for as long as the OS supports my machine. The response is always "blame the third-parties" when apps break, but oftentimes the devs already made their money and moved on. The onus is on Apple to support their OS' software if they want to have my money.
Open-sourcing is one solution, but knowing Apple it's not a likely one. Their "we know best" mindset is why I quit dailying Macs entirely - it's not sustainable outside the mobile dev business. A computer that supports 32-bit binaries, OpenGL or x86 translation when you bought it should be able to retain that capability into the future. Anything less is planned obselecense, even if you want to argue there's a silver lining to introducing new tech. New tech should be competitive on-merits, not because it's competitor was forcibly mutilated.
> The onus is on Apple to support their OS' software if they want to have my money
Apple has done this exact same thing for every architecture change and every API they sunset, but you gave them your money anyways. Their history with discontinuing software support and telling users to harang third-party devs isn't exactly a secret.
Sure, then don't update.
I think you probably should not buy Apple hardware. It is not a guarantee they have ever offered that their software would behave consistently across updates. If this mattered to me, I would have done some research and rapidly found out that Apple has done this every few years for the last 30 years.
But their new hardware is so good though, it's kind of hard to pass up
At what point in history have you owned a particular piece of hardware for use with a particular piece of never-to-be-updated software and installed a major OEM operating system release a full 7 years after release without issue?
I doubt such a thing has ever happened in the history of consumer-facing computing.
Have you ever heard of Windows? Unlike Apple, they do care about backwards compatibility, and don’t randomly go removing features users depend on.
Also they aren't the only ones, this is pretty much standard across commercial UNIXes (the survivors), embedded OSes, mainframes and micros.
and the consequences are dire
Are they? IMO Windows going downhill has more to do with what is being added to it than what it is preserving compatibility for.
> At what point in history have you owned a particular piece of hardware for use with a particular piece of never-to-be-updated software and installed a major OEM operating system release a full 7 years after release without issue?
> I doubt such a thing has ever happened in the history of consumer-facing computing.
Come on. I've done that and still do: I use an ancient version of Adobe Acrobat that I got with a student discount more than 10 years ago to scan documents and manipulate PDFs. I'd probably switch to an open source app, if one were feature comparable, but I'm busy and honestly don't have the time to wade through it all (and I've got a working solution).
Adobe software is ridiculously overpriced, and I'm sure many, many people have done the same when they had perpetual-use licenses.
> At what point in history have you owned a particular piece of hardware for use with a particular piece of never-to-be-updated software and installed a major OEM operating system release a full 7 years after release without issue?
Linux users do it all the time with WINE/Proton. :-)
Before you complain about the term 'major OEM operating system'; Ubuntu is shipped on major OEMs and listed in the supported requirements of many pieces of hardware and software.
> I doubt such a thing has ever happened in the history of consumer-facing computing.
Comments like this show how low standards have fallen. Mac OS X releases have short support lengths. The hardware is locked down-you need a massive RE effort just to get Linux to work. The last few gens of x86 Mac hardware did not have as much, but it was still locked down. M3 or M4 still do not have a working installer. None of this is funded by Apple to get it working on Linux or to get Windows ARM working on it as far as I know.
In comparison, my brother in-law found an old 32bit laptop that had Windows 7. It forced itself without his approval to update to Windows 10. It had support for 10 years from Microsoft with just 10. 7 pushed that 10 to... hmm... 13+ years of support?
> Linux users do it all the time with WINE/Proton. :-)
And there’s a near 100% chance you’ll have to recompile/download pre-re-compiled binaries if moving to a completely different architecture. Same here.
Not the same here. The user didn't have to get different binaries when they changed hardware, and that was a big selling point for the hardware. And now it's going to break in an arbitrary software update.
They did if they moved from x86 to ARM.
There's some kind of massive communication breakdown or misunderstanding going on.
In "Not the same here”, "here" is people moving to M1. So no they very much didn't, that was the whole point of rosetta 2.
Not sure what you are saying. If you saying you need the gamedev to recompile for arm you can run a virtualization layer, just like Mac and Windows. My friend has had the best results with: https://fex-emu.com/
> At what point in history have you owned a particular piece of hardware [...] and installed a major OEM operating system release a full 7 years after release without issue?
A few years ago, I installed Windows 10 on a cheap laptop from 2004—the laptop was running Windows XP, had 1GB of memory, a 32-bit-only processor, and a 150GB hard drive. The computer didn't support USB boot, but once I got the installer running, it never complained that the hardware was unsupported.
To be fair, the computer ran horrendously slow, but nothing ever crashed on me, and I actually think that it ran a little bit faster with Windows 10 than with Windows XP. And I used this as my daily driver for about 4 months, so this wasn't just based off of a brief impression.
Windows 95 was released... well, in 1995. In 2025 you can run apps targeting W95 just fine (and many 16-bit apps with some effort)
> In 2025 you can run apps targeting W95 just fine (and many 16-bit apps with some effort)
FWIW, Windows running on a 64-bit host no longer runs 16-bit binaries.
Yes. Still, there are ways to do it anyway, from Dosbox to WineVDM. Unlike MacOS where having even 32 bit app (e.g. half of Steam games that supported Macos to begin with) means you're fucked
You can use dosbox and x86 virtual machines just fine in macOS (with the expected performance loss) right now, without Rosetta. macOS is still Turing complete.
Technically speaking, you can run anything on anything since stuff Turing complete. Practically speaking however....
E.g. i have half of macos games in my steam library as a 32-bit mac binaries. I don't know a way to launch them at any reasonable speed. Best way to do it is to ditch macos version altogether and emulate win32 version of the game (witch will run at reasonable speed via wine forks). Somehow Win32 api is THE most stable ABI layer for linux & mac
> my steam library as a 32-bit mac binaries. I don't know a way to launch them at any reasonable speed.
To be fair, it's the emulation of x86-32 with the new ARM64 architecture that causes the speed problems. That transition is also why MacBooks are the best portables, in terms of efficiency, that you can buy right now.
All ARM chips have crippled x86-32 performance, because they're not x86-32 chips. You'll find the same (generally worse) performance issues trying to run ARM64 code with x86-64.
Rosetta 2 is pretty good at running x86-32. There's more registers on the destination, after all.
>Windows running on a 64-bit host no longer runs 16-bit binaries.
Which isn't an issue since Windows 95 was not a 16-bit OS, that was MS-DOS. For 16-bit DOS apps there's virtualization things like DOSbox or even HW emulators.
This isn't a new or unique move; Apple has never prioritized backwards compatibility.
If you're a Mac user, you expect this sort of thing. If running neglected software is critical to you, you run Windows or you keep your old Macs around.
It's a bizarre assumption that this is about "neglected software."
A lot of software is for x64 only.
If Rosetta2 goes away, Parallels support for x64 binaries in VMs likely goes away too. Parallels is not neglected software. The x64 software you'd want to run on Parallels are not neglected software.
This is a short-sighted move. It's also completely unprecedented; Apple has dropped support for previous architectures and runtimes before, but never when the architecture or runtime was the de facto standard.
https://docs.parallels.com/parallels-desktop-developers-guid...
Paralles x86_64 emulation doesn't depend on Rosetta.
> If Rosetta2 goes away, Parallels support for x64 VMs likely goes away too.
Rosetta 2 never supported emulating a full VM, only individual applications.
You're right. It looks like the new full VM emulation in 20.2 doesn't use Rosetta.
https://www.parallels.com/blogs/parallels-desktop-20-2-0/
Nevertheless, running x64 software including Docker containers on aarch64 VMs does use Rosetta. There's still a significant valid use case that has nothing to do with neglected software.
Edited my post above. Thanks for the correction.
The OP only applies to Rosetta for running x64 Mac apps, not running x64 Linux software in aarch64 Linux VMs.
I seem to remember 68k software working (on PowerPC Macs) until Classic was killed off in Leopard? I'm likely misremembering the length of time, but it seems like that was the longest backwards-compatibility streak Apple had.
There's a lot of Win95 software that you can't run too. Microsoft puts a lot of work into their extensive backlog of working software. It's not just "good engineering" it's honest to god fresh development.
Just because Microsoft does one thing doesn't mean Apple has to do the same.
That's not a good thing for other reasons; e.g. there are a lot of inconsistencies in modern Windows, like pieces of Windows 3.1 still in Windows 11.
There are leftovers from older versions of macOS and severely neglected apps in Tahoe too. Sure, they might have been given a new icon, or adopted the new system styling, but they have not been updated for ages.
That's not necessarily a good thing.
The main problem is not native software, but virtualization, since ARM64 hardware is still quite uncommon for Windows/Linux, and we need Rosetta for decent performance when running AMD64 in virtual machines.
There is lots of existing software (audio plugins, games, etc.) that will never see an update. All of that software will be lost. Most new software has ARM or universal binaries. If some vendors refuse to update their software, it's their problem. Windows still supports 32-bit applications, yet almost all new software is 64-bit.