Apple will phase out Rosetta 2 in macOS 28
76 comments
·October 24, 2025gumboshoes
caseyohara
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.
linguae
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.
delusional
Honestly, for apple this is above and beyond. They've killed support with less fanfare and compatibility support than what we see here.
out_of_protocol
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)
slavapestov
> 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.
Klonoar
Just because Microsoft does one thing doesn't mean Apple has to do the same.
K7PJP
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.
reddalo
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.
delusional
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.
stalfosknight
That's not necessarily a good thing.
watermelon0
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.
joshuat
I think this is exactly what they're issuing this notice to address. Rosetta performs so well that vendors are pretty okay just using it as long as possible, but a two year warning gives a clear signal that it's time to migrate.
poemxo
I usually agree with Apple but I don't agree with this. Rosetta 28 is basically magic, why would they take away one of their own strongest features? If they want big name apps to compile to Apple Silicon, why can't they exert pressure through their codesigning process instead?
nomel
How much die area does it use that could be used for performance? How much engineering time does it use? Does it make sense to keep it around, causing ~30% more power usage/less performance?
There are many acceptable opposing answers, depending on the perspective of backwards compatibility, cost, and performance.
My naive assumption is that, by the time 2027 comes around, they might have some sort of slow software emulation that is parity to, say, M1 Rosetta performance.
drob518
The “big name apps” have already moved to Apple Silicon. Rosetta helped them with that process a few years ago. We’re down to the long tail apps now. At some point, Rosetta is only helping a couple people and it won’t make sense to support it. I just looked, and right now on my M1 Air, I have exactly one x86 app running, and I was honestly surprised to find that one (Safari plug-in). Everything else is running ARM. My workload is office, general productivity, and Java software development. I’m sure that if you allow your Mac to report back app usage to Apple, they know if you’re using Rosetta or not, and if so, which apps require it. I suspect that’s why they’re telegraphing that they are about ready to pull the plug.
prewett
How do you check if you're running any x86 apps?
al_borland
They were pretty quick to sunset the PPC version of Rosetta as well. It forces developers to prioritize making the change, or making it clear that their software isn’t supported. It
The one I have my eye on is Minecraft. While not mission critical in anyway, they were fairly quick to update the game itself, but failed to update the launcher. Last time I looked at the bug report, it was close and someone had to re-open it. It’s almost like the devs installed Rosetta2 and don’t realize their launcher is using it.
eisa01
You can most likely use Vuescan, I use that with an old ScanSnap i500 (or something)
ZeWaka
Love VueScan for my film scanner!
sixothree
I spent what I would consider to be a lot of money for a unitasker Fujitsu scanner device and am just astounded by how unmaintained and primitive the software is. I only use it on a Windows machine though, so I'm not in the same boat.
bitwize
This is Apple's "get your shit together and port to ARM64, you have 2 years" warning.
If you're not willing to commit to supporting the latest and greatest, you shouldn't be developing for Apple.
t_sawyer
Well this kinda screws me over running docker on macos. Not all images I use have an arm version.
physicsguy
https://github.com/apple/container
They released this a while ago which has hints of supporting amd64 beyond the Rosetta end date.
wmwragg
Yes that was my first thought as well, and as the images aren't designed to be run on a mac specifically, like a native app might be, there is no expectation for the developers to create a native apple silicon version. This is going to be a pretty major issue for a lot of developers
anon7000
I’ve worked in DevOps and companies I’ve worked for put the effort in when M1 came out, and now local images work fine. I honestly doubt it will have a huge impact. ARM instances on AWS, for example, are much cheaper, so there’s already lots of incentive to support ARM builds of images
avhception
In our small shop, I definitely made sure all of our containers supported aarch64 when die M1 hit the scene. I'm a Linux + Thinkpad guy myself, but now that I've got an x13s, even I am running the aarch64 versions!
mxey
Apple Silicon is ARM64 which is supported by Linux and Docker.
watermelon0
But Docker images don't necessarily have ARM64 support. If you are exclusively targeting x64 servers, it rarely makes sense to support both ARM64 and AMD64 platforms for development environment/tests, especially if the product/app is non-trivial.
wmwragg
I'm aware, I use ARM images all the time, I was trying to indicate that the usual refrain that the developers have had years to migrate their software to apple silicon, doesn't really apply to docker images. It's only the increase in use of ARM elsewhere (possibly driven by the great performance of macs running apple silicon) which has driven any migration of docker images to have ARM versions
wmf
Yeah but many people are using x86-64 Docker images because they deploy on x86-64. Maybe ARM clouds will be more common by that time.
null
BurnTheBoss
That's not really the point though right? It means that pulling and using containers that are destined for x86 will require also building arm64 versions. Good news is buildx has the ability to build arm64 on x86, bad news is people will need to double up their build steps, or move to arm in production.
mxey
It doesn’t say if that is going away. The message calls out another part as sticking around:
> Beyond this timeframe, we will keep a subset of Rosetta functionality aimed at supporting older unmaintained gaming titles, that rely on Intel-based frameworks.
Since the Linux version of Rosetta requires even less from the host OS, I would expect it to stay around even longer.
ChocolateGod
Surely, as it is on Linux, QEMU can take over here in running the x86 images on ARM.
Is it slow? Absolutely. But you'd be insane to run it in production anyway.
lostlogin
Are you running this via that travesty of a desktop app?
juancn
Back to the QEMU dark ages
markus_zhang
Ah, I guess it was wise for the original developer of Rosetta 2 to quit earlier this year. One of the people that I look up to.
cwzwarich
My reasons for leaving Apple had nothing to do with this decision. I was already no longer working on Rosetta 2 in a day-to-day capacity, although I would still frequently chat with the team and give input on future directions.
markus_zhang
Thank you for the clarification!
nasretdinov
This seems to basically only apply to full-fledged GUI apps and excludes e.g. games, so potentially stuff like Rosetta for CLI isn't going anywhere either
luizfelberti
They barely just released Containerization Framework[0] and the new container[1] tool, and they are already scheduling a kneecapping of this two years down the line.
Realistically, people are still going to be deploying on x64 platforms for a long time, and given that Apple's whole shtick was to serve "professionals", it's really a shame that they're dropping the ball on developers like this. Their new containerization stuff was the best workflow improvement for me in quite a while.
mxey
The OP says nothing about Rosetta for Linux.
luizfelberti
It seems to talk about Rosetta 2 as a whole, which is what the containerization framework depends on to support running amd64 binaries inside Linux VMs (even though the kernel still needs to be arm)
Is there a separate part of Rosetta that is implemented for the VM stuff? I was under the impression Rosetta was some kind of XPC service that would translate executable pages for Hypervisor Framework as they were faulted in, did I just misunderstand how the thing works under the hood? Are there two Rosettas?
mxey
I cannot tell you about implementation difference but what I mean is that this only talks about Rosetta 2 for Mac apps. Rosetta for Linux is a feature of the Virtualization framework that’s documented in a completely different place. And this message says a part of Rosetta for macOS will stick around, so I would be surprised if they removed the Linux part.
On the Linux side, Rosetta is an executable that you hook up with binfmt to run AMD64 binaries, like how you might use Wine for windows binaries
geoffpado
For those unfamiliar with Apple’s new version-numbering system, this is the version that will be released in 2027, presumably around September or October of that year.
shrinks99
RIP a ton of older audio plugins.
bigyabai
macOS has been sending mixed signals to musicians since Catalina. I'd be surprised if people are still seriously using it for studio work.
lostlogin
I can just imagine the Apple statement, like they did with flash/Flash.
‘We fully support the Studio.’
Edit: After hunting around without success, I’m now doubting my memory. I thought I could remember Jobs dismissively replying to a question about Adobe Flash that Apple supported flash (memory). Maybe I made that up?
al_borland
Hopefully this means macOS 27 will be a Snow Leopard type release to focus on bug fixes, performance, and the overall experience, rather than focusing on new features.
lapcat
Why would it mean that?
It's a myth that Snow Leopard was a bug fix release. Mac OS X 10.6.0 was much buggier than 10.5.8, indeed brought several new severe bugs. However, Mac OS X 10.6 received two years of minor bug fix updates afterward, which eventually made it the OS that people reminiscence about now.
Apple's strict yearly schedule makes "another Snow Leopard" impossible. At this point, Apple has accumulated so much technical debt that they'd need much more than 2 years of minor bug fix updates.
null
crims0n
As is tradition.
null
anthonyskipper
This is awful. I love playing games on my MBP and the latest crossover releases have been amazing in the ability to play almost all windows PC games at full speed. Losing rosetta means crossover is dead.
You would hope that apple would open source it, but they are one of the worst companies in the world for open sourcing things. Shame on all their engineers.
evmar
From the OP: "Beyond [the two-year] timeframe, we will keep a subset of Rosetta functionality aimed at supporting older unmaintained gaming titles, that rely on Intel-based frameworks."
null
mxey
Isn’t that part of Rosetta also used in their own Game Porting Toolkit?
Seems premature. My scanner software, SnapScan, still regularly updated, requires Rosetta. Abbyy FineReaser, the best Mac OCR, requires Rosetta. Although they may be related, as the SnaScan software does OCR with the FineReader engine.