Apple will phase out Rosetta 2 in macOS 28

https://developer.apple.com/documentation/apple-silicon/about-the-rosetta-translation-environment

by summarity • 9 months ago

318 335 9 months ago

developer.apple.com

gumboshoes• 9 months ago

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.

caseyohara• 9 months ago

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.

out_of_protocol3• 9 months ago

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)

linguae• 9 months ago

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.

watermelon03• 9 months ago

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.

spacechild13• 9 months ago

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.

sixothree• 9 months ago

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• 9 months ago

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.

eisa01• 9 months ago

You can most likely use Vuescan, I use that with an old ScanSnap i500 (or something)

[1] https://www.hamrick.com

ZeWaka• 9 months ago

Love VueScan for my film scanner!

e402• 9 months ago

I have Vuescan and it’s not even close.

joshuat• 9 months ago

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.

jayd162• 9 months ago

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

al_borland2• 9 months ago

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.

mrpippy2• 9 months ago

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

poemxo• 9 months ago

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?

drob5182• 9 months ago

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.

nomel7• 9 months ago

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.

morshu9001• 9 months ago

Owning a Mac has always meant not relying on 3P software. Forget printer/scanner drivers. Even if they target macOS perfectly, there will come a day when you need to borrow a Windows PC or old Mac to print.

It happens to be ok for me as a SWE with basic home uses, so their exact target user. Given how many other people need their OS to do its primary job of running software, idk how they expect to gain customers this way. It's good that they don't junk up the OS with absolute legacy support, but at least provide some kind of emulation even if it's slow.

e402• 9 months ago

Me, too. Would be horrible to lose access to my scanner. I have no faith in Fujitsu tgat they would support my iX500.

jajuuka2• 9 months ago

QEMU will still be an option. Albeit not the fastest or easiest option compared to Rosetta 2.

geoffpado• 9 months ago

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.

crims0n• 9 months ago

As is tradition.

t_sawyer• 9 months ago

Well this kinda screws me over running docker on macos. Not all images I use have an arm version.

mxey9• 9 months ago

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.

wmwragg3• 9 months ago

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

mxey9• 9 months ago

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

anon7000• 9 months ago

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

TimTheTinker• 9 months ago

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.

physicsguy• 9 months ago

https://github.com/apple/container

They released this a while ago which has hints of supporting amd64 beyond the Rosetta end date.

dur-randir• 9 months ago

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

lostlogin2• 9 months ago

Are you running this via that travesty of a desktop app?

juancn• 9 months ago

Back to the QEMU dark ages

ChocolateGod• 9 months ago

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.

coldtea4• 9 months ago

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.

tobyjsullivan• 9 months ago

How does this work currently? I was under the impression that Docker for Mac already ran containers in an x86 VM. Probably outdated info, but I’m curious when that changed.

cpuguy83• 9 months ago

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

hakube• 9 months ago

Doesn't Orbstack or Colima solve this?

p0w3n3d2• 9 months ago

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

saagarjha5• 9 months ago

That won’t be going away, none of that requires any support from the host OS.

swiftcoder3• 9 months ago

This isn't about the virtualisation support - it's about all the Mac system frameworks being available in the rosetta environment

nicce2• 9 months ago

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

ehutch792• 9 months ago

Ask the maintainers to build arm images. Realistically they should be, unless the project uses lots of x86 assembly.

jamesgeck0• 9 months ago

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.

markus_zhang4• 9 months ago

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.

https://news.ycombinator.com/item?id=42483895

cwzwarich• 9 months ago

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_zhang4• 9 months ago

Thank you for the clarification!

ta9000• 9 months ago

Thank you for your work!

casualscience• 9 months ago

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

nasretdinov• 9 months ago

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

TheTon5• 9 months ago

But games are full fledged GUI apps. At a minimum they have a window.

It’s really unclear what it means to support old games but not old apps in general.

I would think the set of APIs used by the set of all existing Intel Mac games probably comes close to everything. Certainly nearly all of AppKit, OpenGL, and Metal 1 and 2, but also media stuff (audio, video), networking stuff, input stuff (IOHID etc).

So then why say only games when the minimum to support the games probably covers a lot of non games too?

I wonder if their plan is to artificially limit who can use the Intel slices of the system frameworks? Like hardcode a list of blessed and tested games? Or (horror) maybe their plan is to only support Rosetta for games that use Win32 — so they’re actually going to be closing the door on old native Mac games and only supporting Wine / Game Porting Toolkit?

dagmx5• 9 months ago

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.

rincebrain• 9 months ago

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.

anthonyskipper2• 9 months ago

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.

mxey9• 9 months ago

Isn’t that part of Rosetta also used in their own Game Porting Toolkit?

evmar• 9 months ago

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

difosfor• 9 months ago

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

Cloudef• 9 months ago

mac for gaming is just not a good idea

fragmede• 9 months ago

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?

snvzz• 9 months ago

Fortunately, whoever has money for a Mac can also afford hardware that will actually run games.

wooger2• 9 months ago

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.

shrinks99• 9 months ago

RIP a ton of older audio plugins.

bigyabai3• 9 months ago

macOS has been sending mixed signals to musicians since Catalina. I'd be surprised if people are still seriously using it for studio work.

lostlogin2• 9 months ago

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?

Reubend• 9 months ago

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.

p0w3n3d2• 9 months ago

I've already lost my "studio" (a few appliances in the corner of my room) due to upgrade from windows 7 to 10. Now it will happen again after I migrated to mac. I guess the "studio" should be left alone when it comes to upgrades. I'm starting to believe, that a "studio" is a set of software AND hardware, so I guess I won't sell my mac to buy new, but rather maintain it with given software and hardware on it, just maybe unplug it from the internet.

-- EDIT --

or just move back to windows, but I can't imagine it with the current state of AI bloat

wooger2• 9 months ago

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

braebo2• 9 months ago

I lost access to decades of my albums which can no longer open on my MacBooks. Some open partially running Ableton Live with Rosetta. My record label recently reached out asking for stems for an old song for a sync deal with Rocket League — after spending a week trying to revive the old sessions I concluded that it was impossible and they were forever lost thanks to apples complete abandonment of backwards compatibility. It’s heart breaking really.

Mashimo• 9 months ago

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 :)))

yborg• 9 months ago

Photoshop plugins also.

redwall_hp• 9 months ago

Or current ones. I think Yamaha VOCALOID 6 still only ships for Intel and says to put your DAW in Rosetta mode.

al_borland2• 9 months ago

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.

lapcat3• 9 months ago

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.

https://lapcatsoftware.com/articles/2023/11/5.html

dagmx5• 9 months ago

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

JimDabell2• 9 months ago

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

egorfine• 9 months ago

No. Only Steve Jobs could have pulled this.

Modern day Apple cannot. A bugfix-only release is not going to sell anything.

luizfelberti2• 9 months ago

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.

[0] https://github.com/apple/containerization

[1] https://github.com/apple/container

mxey9• 9 months ago

The OP says nothing about Rosetta for Linux.

luizfelberti2• 9 months ago

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?

pjmlp7• 9 months ago

Apple has always been like this, there are other options when backwards compatibility is relevant feature.

jack_tripper3• 9 months ago

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.

WillAdams2• 9 months ago

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

ehutch792• 9 months ago

There are a lot of projects with arm containers on docker hub. It’s not hard to build multi platform containers.

embedding-shape3• 9 months ago

and given that Apple's whole shtick was to serve "professionals",

When was the last time this was true? I think I gave up on the platform around the new keyboards, who clearly weren't made for typing, and the non-stop "Upgrade" and "Upgrade" notifications that you couldn't disable, just push forward into the future. Everything they've done since them seems to have been to impress the Average Joe, not for serving professionals.

conception• 9 months ago

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

alwillis2• 9 months ago

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

PeaceTed• 9 months ago

By the time this happens, it will have been a 7 year transition. That isn't too bad considering the original Rosetta only got 5.

I do have sympathy for those that still use this in their daily work flow, but also... this is Apple. This is how they have always rolled.

sedatk• 9 months ago

Meanwhile, I can still run my apps from the 90’s on my ARM laptop on Windows. That’s two architectures back to be clear: ARM64 -> x86-64 -> x86

kstenerud• 9 months ago

Would be nice if they open sourced Rosetta, so that the community could continue support.

keyle• 9 months ago

That means the end of the Hackintosh era if the OS won't run x86, I imagine it won't install on x86 either.

cmckn• 9 months ago

Aw that bums me out, brings back a lot of memories. Though I assume it’s been effectively dead for a while.

I haven’t dabbled with hackintoshes in nearly a decade, I stepped away around the time iMessage started needing those extensive hacks to work. Things seemed to shift away from driver/bootloader gaps to faking Apple hardware. Years earlier, I had an Asus Eee PC (remember “netbooks”?) that ran macOS without any major issues. I even built a machine that I believed I could hackintosh easily, though it never quite worked as well as I hoped.

The era of random companies selling pre-built Hackintoshes was so cool. Kids these days probably wouldn’t even believe it if you told them, like how Netflix used to actually send you a DVD in the mail. :)

pjmlp7• 9 months ago

Tahoe is officially the last version to support x86.

I never liked the idea, either get Apple, or get one of the other OSes.

It was like getting a Fiat Coupe with a Ferrari logo.

0x02• 9 months ago

I'm guessing they don't want to maintain and build and test x86_64 versions of all the macos libraries like Appkit and UIKit (including large changes like liquid glass) when they are no longer shipping x86_64 macOS versions. Which is not entirely unreasonable as I'm sure it takes a lot of effort to keep the whole ui library stack working properly on multiple archs.

Perhaps that's what they're hinting about with the note about a "subset of Rosetta". So maybe there is hope that the core x86_64 binary translator will stick around for things like VM and emulation of generic (linux? wine?) binaries, but they don't want to maintain a whole x86_64 macOS userspace going forward.

Space savings from not shipping fat binaries for everything will probably also be not insignificant. Or make room for a new fat binary for a future "arm64v2" :)

saagarjha5• 9 months ago

It’s basically just a recompile though.

WanderPanda• 9 months ago

Until it isn't

RossBencina• 9 months ago

Can you enable TSO for ARM executables?

0x02• 9 months ago

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.

zaphirplane• 9 months ago

It’s not like they were doing it to make me happy, they are doing it to sell Mac and lock people into the Apple ecosystem. Maybe there is a negligible % of people using it, possible m1 is 6 yrs old iirc

rs186• 9 months ago

Closer to 5 years old

swiftcoder3• 9 months ago

So maybe there is hope that the core x86_64 binary translator will stick around for things like VM and emulation of generic (linux? wine?) binaries

It's mostly for their game-porting toolkit. They have an active interest in Windows-centric game developers porting their games to Mac, and that generally doesn't happen without the compatibility layer.

bayindirh8• 9 months ago

Apple always phases out these kinds of technologies after some time to keep the ecosystem tidy and give a last push to developers to abandon legacy code.

In this iteration, it might also allow some simplification of the silicon since Mx chips have some black magic to mimic x86 (mostly in memory access IIRC) to allow Rosetta to work that fast. IOW, Rosetta 2 is not a software only magic this time.

I remember using the first Rosetta to play Starcraft on my Intel Mac. It also got deprecated after a year or two.

So leaving things behind despite some pains is Apple's way to push people forward (e.g.: Optical media, ports, Rosetta 1, Adobe Flash, etc.).

cactusplant73743• 9 months ago

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

latexr6• 9 months ago

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)

dreamcompiler• 9 months ago

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.

thw_9a83c4• 9 months ago

...they don't want to maintain and build and test x86_64 versions...

This feels wrong. Apple sold Intel-based Macs until early June 2023. The last one was the 2019 Mac Pro model.

Ending support for Rosetta in macOS around 2028 also means ending support for any x86_64 versions of software. This means that those unfortunate users who bought an Intel Mac Pro in 2023 only got five years of active usability.

bayindirh8• 9 months ago

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

dylan6043• 9 months ago

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.

Bud• 9 months ago

It's reasonable to say this is wrong. But really, this seems like a tiny subset of users. Who bought a Mac Pro in 2023 after Apple Silicon had been out for 3 years already? Almost nobody, because it wasn't a real performance improvement by that time. For those extremely niche folks for which it was somehow still beneficial, they definitely won't want to still be using such a machine in 2028. They will have moved on to something like an M5 Ultra Mac Studio or whatever form the Mac Pro takes next.

8fingerlouie2• 9 months ago

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.

nottorp6• 9 months ago

including large changes like liquid glass

They could just revert all that large change with no loss to the users.

dwaite• 9 months ago

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.

rangestransform• 9 months ago

System library calls from x86 don’t get converted into arm64 by Rosetta? I coulda sworn Microsoft’s emulator did that

zer0zzz• 9 months ago

Best take

somanyphotons• 9 months ago

Or make room for a new fat binary for a future "arm64v2" :)

Or, one can dream: RVA23

ngcazz3• 9 months ago

Tangentially, this was surprising

  The system prevents you from mixing 
  arm64 code and x86_64 code in the 
  same process. Rosetta translation 
  applies to an entire process, 
  including all code modules that the 
  process loads dynamically.

I've been using this VST from Arturia (Minimoog V) since they distributed it for free back in like 2011 or 2012, and it runs as well on my M1 Mac as it did on my previous Intel Macs.

I mean, it's literally the same DMG from way back when and there's no chance it doesn't run under Rosetta, but I run Ableton natively!

spacechild13• 9 months ago

Seems like you're trying to load an Intel-only plugin binary in a native ARM application. This doesn't work. DAW and plugins must use the same archicture. You would either have to run Ableton in Rosetta or use a plugin bridge. (This is similar to Windows if you want to run 32-bit plugins in a 64-bit DAW.)

lukeh• 9 months ago

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

darkamaul• 9 months ago

I’ve always been amazed by Rosetta, such an incredible piece of engineering. But I wonder if we’ll ever see its source code opened up.

It feels like keeping it alive could really help long-term x64 support on Apple Silicon, even if Apple decides to move on.

smat• 9 months ago

Check out Asahi Linux, they run on Apple Silicon and have translation for 32 and 64 bit x86, so they even go further than what Rosetta achieved. Open Source as well.

ferguess_k3• 9 months ago

I'd also love to see the source code of the embedded M68K emulator for PPC Macs. I believe there are two versions -- one interpreter style and one dynarec style.

aranw• 9 months ago

For a few years now it's been feeling like Apple are pushing devs away and are more interested in catering for general consumers. Just look at what DHH has written and said about it, and his move to Omarchy

tonyedgecombe• 9 months ago

Hopefully this will finally push Sonos to produce an Apple Silicon binary.

matjazk• 9 months ago

Running Windows in Parallels. Even when running Windows ARM version, you still need Rosetta to run Windows x86 binaries.

Rochus5• 9 months ago

This is very frustrating. As if they couldn't afford to continue it. And at the same time they keep making the system more and more closed, so that you can't even run applications without Apple's permission. I don't understand why people still buy such products.

matthewmacleod• 9 months ago

And at the same time they keep making the system more and more closed, so that you can't even run applications without Apple's permission.

This is simply not true.

Rochus5• 9 months ago

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.

rowanG0772• 9 months ago

It will be interesting to see whether they keep optional TSO in their SoCs after Rosetta 2 is no longer working.

kburman• 9 months ago

Phasing out Rosetta 2 seems like a reasonable move. Maintaining backward compatibility indefinitely adds complexity and technical debt. Apple has supported Intel-based systems for a long time, and this step aligns with their goal of keeping macOS streamlined for Apple Silicon.

AshamedCaptain• 9 months ago

Backwards compatibility may be many things, but it is never technical debt.

jajuuka2• 9 months ago

I wouldn't call 6 years a long time for support. Imagine if Microsoft announced that any software older than 2020 will not longer work. Not be out of support or not get any more updates, just become not runnable.

The problem I have with it is Apple unilaterally deciding that support ends. I don't see the harm in no longer supporting it but leaving it as an option for legacy support. No garentee that anything will work with it and no support for it. They've done this with their hardware before but here it's just a cudgel to force devs to update their apps.

wosined6• 9 months ago

Just use linux. You learn it once and it works forever.

BirAdam4• 9 months ago

If only this were true.

Stuff in Linux changes. Not quite as frequently, but it does change and in major ways that require significant amounts of relearning.

Example 1: audio

OSS -> Alsa -> Random Layers on top of Alsa -> Pulse -> Pipewire

Example 2: init

SysV -> OpenRC || runit || s6 || upstart -> systemd

Examples 3: desktops

KDE 1/2/3 -> KDE 4/Plasma

GNOME 1 -> GNOME 2 -> GNOME3+

Example 4: networking

ifconfig -> ip

Example 5:

Xfree86 -> Xorg -> Wayland

Now, it's important to note that people were attempting to resolve issues. The transitions weren't always clean, but the results are usually great. For example, moving to pipewire is possible the greatest advancement of audio ever. Linux audio finally doesn't suck. Xfree86 to Xorg was likewise great. For the last few years of X11, I usually didn't have to modify the config. I kind of don't care about init systems most of the time. The only major complaint for systemd is that disk I/O on embedded systems is kind of an issue, but things like Alpine are better there and Alpine doesn't use systemd.

With that said, I think the real issue is that people dislike advancements that break things. Early in Pulse's life, people absolutely hated it. Early in Wayland's life, people absolutely hated it, but it wasn't default so no one complained. With Windows and macOS, stuff changes seemingly constantly and randomly and breaks things, so people hate it. Saying, however, that Linux doesn't change seems a little daft to me. It changes faster than anything else on small levels, and different distributions have breaking changes at different rates.

wosined6• 9 months ago

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.

nottorp6• 9 months ago

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.

vbezhenar2• 9 months ago

Linux is so not polished.

Just few days ago something updated and my virtual desktop switching now behaves erratically. I'm pressing <Super>+<1>, it changes to desktop 1 with vscode opened. And immediately it starts typing "1" into vscode. Seems to bug with all X applications. I fixed it for vscode to make it work under wayland, but now it doesn't draw border around vscode window. Another irritation and I have other X apps.

It works, it's free, I love it. But it's so not polished and it'll never be. I miss macOS polish, where basic things just work.

wosined6• 9 months ago

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.

dangus3• 9 months ago

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.

pjmlp7• 9 months ago

Forever only if one never updates.

wosined6• 9 months ago

Depends on the distro.

mxey9• 9 months ago

Linux is by far the OS with the highest amount of churn.

wosined6• 9 months ago

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.

joezydeco• 9 months ago

My company only hands out Macs. So I use Linux in a VM for embedded development. Works great.

And now I'm getting an Apple Silicon machine in a few months to replace my Intel Mac and I'm out of luck.

stuaxo• 9 months ago

Bring back Rosetta 1.

User mode emulation for PPC and Intel Mac apps.

dangus3• 9 months ago

https://sheepshaver.cebix.net/

ioma8• 9 months ago

Does this mean end to macOS wine gaming? From what I know you need to be using x86_64 build of wine on macos to run the x86 built windows games.

BirAdam4• 9 months ago

No, follow the link. The article states that a subset of Rosetta 2 will remain for things like games.

nottorp6• 9 months ago

Ok, application developers will maybe update by then.

But this is another way for Apple to say "do not trust us for your gaming needs no matter what PR says".

latexr6• 9 months ago

From the page, inside an large block marked “Important”:

Beyond this timeframe, we will keep a subset of Rosetta functionality aimed at supporting older unmaintained gaming titles, that rely on Intel-based frameworks.

nottorp6• 9 months ago

Shocking. Good idea but shocking coming from Apple.

vbezhenar2• 9 months ago

May be M7 CPU will run qemu emulation of x86 fast enough for Rosetta to not be required.

ksec• 9 months ago

I guess this is another way of Apple saying x86 is dead. Would have loved if Intel and AMD joined force to open up x86. Instead they are following the same path as POWER, likely doing it when it is too little too late.

pohl• 9 months ago

That means Steam will release a native Apple Silicon client circa 2028. Exciting!

Sekhmet• 9 months ago

Steam already has Apple Silicon build in Steam Beta channel.

davidkwast• 9 months ago

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

Apple will phase out Rosetta 2 in macOS 28

Related Stories