If they hadn't deprecated 32 bit we would still be able to play Halo on mac.

Not sure it's only about tidiness. Rosetta 1 was licensed from a third party and Apple didn't want to keep paying the license fees.

I don't know if this is the situation with Rosetta 2.

> It also got deprecated after a year or two.

It was five years, from 2006 to 2011. Rosetta 2 will have been there for seven years (currently at five).

https://en.wikipedia.org/wiki/Rosetta_(software)

Just because the latest OS isn't able to be installed on older hardware does not mean the hardware in no longer usable. I know people to this day that still run the last 2012 cheese grater MacPros with Snow Leopard as daily work machines. They still use Final Cut 7 on them to capture content from tapes. At this point, they are very fancy dedicated video recorders, but they still run and are money making devices.

You got it wrong.

Rosetta is the technology that allows Apple Silicon hardware to execute Intel software. When they introduced Apple Silicon with the M1 processor, not many binaries existed for Apple Silicon, so Rosetta2 was a bridge for that problem.

They used the same technology (Rosetta 1) when they switched from PowerPC to Intel.

Pretty much every binary for macOS is distributed as a "Universal Binary", which contains binaries for both x86 and Apple Silicon, so x86 isn't being abandoned, only the ability to run applications on Apple Silicon that hasn't been redistributed / recompiled in 6-7 years.

I don't think the ability to cross-compile things will go away when Rosetta is phased out, though.

[dead]

The largest impact would be that the reversion would only affect native macOS apps, while catalyst apps, remote iPhone apps and locally installed iPad apps would still have Liquid Glass UX.

I'm sure there's lots of x86_64 specific code in the macOS userland that is much more than just a recompile - things like safari/javascriptcore JIT, various quartz composer core animation graphics stack and video encoder decoder stack libraries, as well as various objective-c low level pointer tagging and message passing ABI shenanigans and so on. This is probably why 32bit intel mac app support was dropped pretty hard pretty fast, as the entire runtime and userland probably required a lot of upkeep. As just one example, 32bit intel objective-c had "fragile instance variables" which was a can of worms.

Until it isn't

Can you enable TSO for ARM executables?

Closer to 5 years old

Yeah, it kind of kills me that I am writing this on a Samsung Galaxy Book 3 Pro 360 running Windows 11 so that I can run Macromedia Freehand/MX (I was a beta-tester for that version) so that I can still access Altsys Virtuoso 2 files from my NeXT Cube (Virtuoso 2 ~= Macromedia Freehand 4) for a typeface design project I'm still working on (a digital revival of a hot metal typeface created by my favourite type designer/illustrator who passed in 1991, but whose widow was gracious enough to give me permission to revive).

I was _so_ hopeful when I asked the devs to revive the Nx-UI code so that FH/MX could have been a native "Cocoa" app....

That's why like 80%+(?) of corporate world runs Windows client side for their laptops/workstations. They don't want to have to rewrite their shit whenever the OS vendor pushes an update.

Granted, that's less of an issue now with most new SW being written in JS to run in any browser but old institutions like banks, insurances, industrial, automation, retail chains, etc still run some ancient Java/C#/C++ programs they don't want to, or can't update for reasons but it keeps the lights on.

Which is why I find it adorable when people in this bubble think all those industries will suddenly switch to Macs.

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?

The current macbook pro was basically a checklist of items professionals wanted away from consumer new shiny thing.

> Everything they've done since them seems to have been to impress the Average Joe, not for serving professionals.

"CIOs say Apple is now mission critical for the enterprise" [1]

[1]: https://9to5mac.com/2025/10/25/cios-say-apple-is-now-mission...

Just went through that thread, I can't believe this wasn't a team of like 20 people.

It's crazy to me that apple would put one guy on a project this important. At my company (another faang), I would have the ceo asking me for updates and roadmaps and everything. I know that stuff slows me down, but even without that, I don't think I could ever do something like this... I feel like I do when I watch guitar youtubers, just terrible

I hope you were at least compensated like a team of 20 engineers :P

Thank you for your work!

Thank you for the clarification!

Believing in hints from Apple about software? Sweet summer child.

Case in point - Microsoft's SQL Server docker image, which is x86-only with no hint of ever being released as an aarch64 image.

I run that image (and a bunch of others) on my M3 dev machine in OrbStack, which I think provides the best docker and/or kubernetes container host experience on macOS.

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

Apple Silicon is ARM64 which is supported by Linux and Docker.

The performance that makes containers usable currently depends on Rosetta on Linux as well. Removing the support makes them much less usable.

It's not just images; any software the images pull down must also support ARM64 now as well. For example, the official Google Chrome binaries used by Puppeteer for headless browsing/scraping don't have a Linux ARM build.

Docker on Mac runs containers in a VM, but the VM is native the cpu architecture and takes advantage of hardware virtualization.

You can of course always use qemu inside that vm to run non-native code (eg x86 on Apple Silicon), however this is perceived as much slower than using Rosetta (instead of qemu).

Wanting it to be fast is not just about "running it on production".

A test suite that becomes 10x slower is already a huge issue.

That said, it doesn't seem llike Rosetta for container use is going anywhere. Rosetta for legacy Mac applications (the macOS level layer) is.

if you run x86 code without rosetta (probably using the qemu) it will work painfully slow

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.

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)

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.

If it's ok now then what's even the problem with letting it be?

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.

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.

I have Vuescan and it’s not even close.

Love VueScan for my film scanner!

Rosetta for PPC apps was supported from the first Intel Macs released in January 2006 until 10.7 Lion was released in July 2011.

So it was not released yet. What is keeping Valve from release it? Apple is "giving a hand" now.

Games use a very small portion of the native frameworks. Most would be covered by Foundation, which they have to keep working for Swift anyway (Foundation is being rewritten in Swift) and just enough to present a window + handle inputs. D3DMetal and the other translation layers remove the need to keep Metal around.

That’s a much smaller target of things to keep running on Intel than the whole shebang that they need to right now to support Rosetta.

If you'd like to see an interesting parallel, go look at how Microsoft announced supporting DirectX 12 on Windows 7 for a blessed apps list - basically because Blizzard whined hard enough and was a big enough gorilla to demand it.

> 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

Somebody who worked on Snow Leopard has already disagreed with you here about those things:

> As the person who personally ran 10.6 v1.1 at Apple (and 10.5.8), you are wrong(ish).

> Snow Leopard's stated goal internally was reducing bugs and increasing quality. If you wanted to ship a feature you had to get explicit approval. In feature releases it was bottom up "here is what we are planning to ship" and in Snow Leopard it was top down "can we ship this?".

> During that time period my team and I triaged every single Mac OS X bug coming into the company every morning. Trust me, SL was of higher quality than Leopard.

— https://news.ycombinator.com/item?id=43431675#43439348

> 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.

I don’t think the schedule matters. They just over-commit every time. I said elsewhere:

> [Apple] were never building and have never built software at a sustainable pace, even before the yearly cadence. They race ahead with tech debt then never pay it off, so the problem gets progressively worse.

> A while back, that merely manifested as more and more defects over time.

> More recently, they began failing to ship on time and started pre-announcing features that would ship later.

> And now they’ve progressed to failing to ship on time, pre-announcing features that would ship later, and then failing to ship those features later.

> This is not the yearly cadence. This is consistently committing to more than they are capable of, which results in linear growth of tech debt, which results in rising defects and lower productivity over time. It would happen with any cadence.

— https://news.ycombinator.com/item?id=43436105

Not sure why you’re downvoted because you’re right.

Snow leopard brought a huge amount of under the covers features. It was a massive release. The only reason it had that marketing was because they didn’t have a ton of user facing stuff to show

Could you not open the project on a windows computer or older mac?

I also think current Native Instruments luncher "Native Access" still requires rosetta for the installation :)))

It's just a choice between competent AI bloat (Microsoft) vs. laughable non-functional AI bloat (Apple).

There are tons of musicians on Mac, and it gets lots of studio use. I'd say at least 50% of music studios are on Macs from what I've seen.

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?

> This is simply not true.

Ok, then try to run a pre-compiled macOS M1 compatible application on your new Sequoia system, such as https://github.com/rochus-keller/oberonsystem3/ or https://github.com/rochus-keller/leancreator/. Requires quite some tricks so that at least some applications run without Apple's benedictions, but the tricks don't work for all such applications; and as it looks, they will also remove the last remaining work-arounds in future.

Shocking. Good idea but shocking coming from Apple.

AU plugins work, the AU framework itself spins up a separate process to host the translated Intel plugin.

What about the newer games that are maintained, just not supported on anything but windows?

What are you talking about? There's Do I have enough RAM to run Slack, all my Chrome tabs, and a terminal program; there's what terminal program shall I run today: Ghost edition; there's Can I get Colima to run, now with docker DLC. There's Kubernetes on Mac: Kind edition; there's Let's with Tart!; Nix is for Ops: New and more obtuse config edition. With so many fun games to play, who's got time for anything else?

A Macbook (air) is no longer a crazy expensive unobtainable thing, just a perfectly reasonable mid-price choice for most people.

Whereas a good graphics card alone is still insane money.

> I miss macOS polish, where basic things just work.

Funny, since iOS 26 my iPhone has been failing to bring up the screenshot UI half to time, completely broke guided access, and now I can’t figure out how to close all tabs in safari because all the buttons make no sense anymore.

Oh yeah and my battery life sucks now.

You should look into atomic Linux distros. They take getting used to but they’re awesome for being stable and easy to revert changes.

> virtual desktops > vscode > wayland Sounds like you have a misconfigured system. Jokes aside, this looks like a bug in your WM. Macs may be more polished, but my point was not about polish.

Yes, Pulse pushed me to make my first hackintosh and move from Linux on the desktop to Mac OS on the desktop.

Good job, Poettering.

You don't have to install gnome, kde, wayland or systemd. You are just talking about your preferences masked as something that “had to be done”. I only had to fiddle with audio on the raspberry pi when connecting bluetooth. Everything works out of the box nowadays. If wayland was a good protocol, the user would not have to know about it.

I use less than 10 gui programs on linux. They never change. The command line programs do not change either. Unless the devs get a dumb idea to rewrite them in Rust, because they sunk so many hours into learning it.

Depends on the distro.