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.<p>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.<p>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" :)
> ...they don't want to maintain and build and test x86_64 versions...<p>This feels wrong. Apple sold Intel-based Macs until early June 2023. The last one was the 2019 Mac Pro model.<p>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.
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.
The last security update for Snow Leopard was in 2013. Friends don't let friends connect software that vulnerable to the internet.<p>The hardware can be ok, the walled garden is not.
You're right; I still have a 2010 MBP w/8GB of RAM and a SSD upgrade I made to it years ago. My mother still uses her similar vintage MBP with the same upgrades. These work just fine for most non-work tasks.<p>That doesn't mean that I expect these things to be updated or supported 15y after I bought them. I am absolutely certain I made the back $850 I originally paid (edu discount) + the ~$250 in upgrades over the years and I'm entirely ok with just letting it limp along until it physically dies. I think most people have similar expectations.
I still have my 2011 MBP with very similar upgrades, but unfortunately, it has the known bad Nvidia GPU that has been repaired multiple times. The last time it was taken in for repair, Apple said they were no longer supporting the repair. It's still usable as long as nothing tries to access the GPU, but as modern web tries to use GPU it would crash the laptop constantly.
I liked out in that mine never developed any issues with the GPU itself. Though it was stolen in 2014, so who knows longer term. My daughter is still running my (iirc 2014) model. I've been relatively happy with my 16gb M1 Air, aside from my own vision issues.
Lucky you, so to speak. Back in the day I had the same one, but it would pass their diagnostics, so they wouldn't repair it, though I could literally make it crash in front of the Genius Bar techs reliably and repeatedly (essentially the same way, by trying to do anything that hit the GPU a certain way - websites, Photoshop). "Sorry, our diagnostic tool says it's not the GPU". At one point I even demanded they do a completely fresh install of the OS. On first login, I fire up Safari, go to a certain site, crash. Restart, go to a different site, crash. "Sorry."
I don't think the ability to cross-compile things will go away when Rosetta is phased out, though.
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.<p>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.<p>I remember using the first Rosetta to play Starcraft on my Intel Mac. It also got deprecated after a year or two.<p>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.).
> It also got deprecated after a year or two.<p>It was five years, from 2006 to 2011. Rosetta 2 will have been there for seven years (currently at five).<p><a href="https://en.wikipedia.org/wiki/Rosetta_(software)" rel="nofollow">https://en.wikipedia.org/wiki/Rosetta_(software)</a>
To clarify, the complete sentence in my mind was "...after a year or two I got my Intel Mac". I got mine in Q3 2008, just before Unibody ones introduced.<p>So, I effectively got 2 years out of Rosetta 1, but didn't meant to say Apple supported it for two years only.<p>Sorry for the confusion.<p>Looks like I can't edit my comment anymore to clarify.
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.<p>I don't know if this is the situation with Rosetta 2.
I read a comment somewhere, possibly here by an ex-Apple engineer who claimed that they optimized the thing mathematically for the performance it exhibits.<p>So, considering its silicon parts, Rosetta 2 is more of an Apple endeavor and technology.<p>On the other hand 5-7 years a very typical timespan for Apple. So, I don't think licensing fees were <i>that</i> important while ending support for it.
The original Rosetta was based on technology from Transitive which, as I recall, IBM bought. Don't know where Rosetta 2 fits in and any licensing associated with the original Rosetta was a long time ago.
If they hadn't deprecated 32 bit we would still be able to play Halo on mac.
This is the perfect comment because 1) it’s true, and 2) it can be read as supportive, a complaint, or just a neutral observation.
The problem is, keeping older architectures alive creates an exponential workload, grinding everything to halt.<p>So, even though I feel what you are saying, we can't have every nice thing we want, at the same time.
Is there not an emulator at this point?
> including large changes like liquid glass<p>They could just revert all that large change with no loss to the users.
> 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<p>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.
System library calls from x86 don’t get converted into arm64 by Rosetta? I coulda sworn Microsoft’s emulator did that
> Or make room for a new fat binary for a future "arm64v2" :)<p>Or, one can dream: RVA23
It’s basically just a recompile though.
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?
Best take
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
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.<p>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.<p>[0] <a href="https://github.com/apple/containerization" rel="nofollow">https://github.com/apple/containerization</a><p>[1] <a href="https://github.com/apple/container" rel="nofollow">https://github.com/apple/container</a>
Apple has always been like this, there are other options when backwards compatibility is relevant feature.
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).<p>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....
> running Windows 11 so that I can run Macromedia Freehand/MX<p>Freehand still works on Windows 11? I’m happy for you, I never found a true replacement for it.<p>> 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<p>Any reason you haven’t shared the name of the designer or the typeface? That story sounds interesting, I’d really welcome learning more.
Yes, fortunately. I despair of what I'm going to do when I no longer have such an option. Cenon is clunky, Inkscape's cross-platform nature keeps it from having many interface aspects which I depend on, and I'd rather give up digital drawing than use Adobe Illustrator (which despite using since v3.2 on college lab Macs and on my NeXT Cube I never found comfortable).<p>The designer/typeface are Warren Chappell's Trajanus, and his unreleased Eichenauer --- I read _The Living Alphabet_ (and his cousin Oscar Ogg's _The 26 Letters_) when I was very young, and met him briefly on a school field trip back when he was Artist-in-Residence at UVA and did a fair bit of research in their Rare Book Room, and even had a sample of the metal type (missing one character unfortunately).<p>It is currently stalled at my having scanned and drawn up one of each letter at each size which I have available, but only having two letters, _N_ and _n_ in all sizes --- probably shouldn't worry that much about the optical axis, since it was cut in metal in one master size and the other sizes made using a pantograph, but there were _some_ adjustments which I'd like to preserve. There is a digital version of Trajanus available, but it's based on the phototype. I've been working at recreating each character using METAFONT, encompassing the optical size variation in that programmatically, but it's been slow going (and once I'm done, I then have to work out how to make it into outlines....)
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.<p>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.<p>Which is why I find it adorable when people in this bubble think all those industries will suddenly switch to Macs.
The OP says nothing about Rosetta for Linux.
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)<p>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?
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.<p>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
Rosetta Linux executable can be used without host hardware/software support; for example, you can run it on AWS's Graviton instances.<p>However, to get performance benefits, you still need to have hardware support, and have Rosetta installed on macOS [1].<p>TFA is quite vague about what is being deprecated.<p>[1] <a href="https://developer.apple.com/documentation/virtualization/running-intel-binaries-in-linux-vms-with-rosetta" rel="nofollow">https://developer.apple.com/documentation/virtualization/run...</a>
The "other" part of Rosetta is having all system frameworks being also compiled for x86_64, and being supported running in this configuration.
There are a lot of projects with arm containers on docker hub. It’s not hard to build multi platform containers.
> and given that Apple's whole shtick was to serve "professionals",<p>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.
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.<p>"CIOs say Apple is now mission critical for the enterprise" [1]<p>[1]: <a href="https://9to5mac.com/2025/10/25/cios-say-apple-is-now-mission-critical-for-the-enterprise/" rel="nofollow">https://9to5mac.com/2025/10/25/cios-say-apple-is-now-mission...</a>
That's literally sponsored content/an ad by a company who makes money managing Apple devices, of course they'll say it's "mission critical", on a website meant to promote Apple hardware.<p>Happen to have some less biased source saying anything similar, ideally not sponsored content?
Well this kinda screws me over running docker on macos. Not all images I use have an arm version.
<a href="https://github.com/apple/container" rel="nofollow">https://github.com/apple/container</a><p>They released this a while ago which has hints of supporting amd64 beyond the Rosetta end date.
It doesn’t say if that is going away. The message calls out another part as sticking around:<p>> Beyond this timeframe, we will keep a subset of Rosetta functionality aimed at supporting older unmaintained gaming titles, that rely on Intel-based frameworks.<p>Since the Linux version of Rosetta requires even less from the host OS, I would expect it to stay around even longer.
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
Case in point - Microsoft's SQL Server docker image, which is x86-only with no hint of <i>ever</i> being released as an aarch64 image.<p>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
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!
It has a huge impact if you need to run the exact same container as in production. This kills Macs in those shops. And there are more than you might think.
Apple Silicon is ARM64 which is supported by Linux and Docker.
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.
Every port I've done to a new hardware or software platform has shaken loose at least a handful of bugs or assumptions that were well worth ironing out. And in the case of a port to Apple Silicon, you get a very fast development environment at the end of it. This library also helped with 90% of the work:<p><a href="https://github.com/DLTcollab/sse2neon" rel="nofollow">https://github.com/DLTcollab/sse2neon</a>
Or, if you just want to create multi-arch images for your project, on your Mac...so that your non-Mac customers can use them.
I guess now it makes sense. Got 3 years to turn on ARM builds.
No, it still doesn't make sense.<p>And it looks like Rosetta 2 for containers will continue to be supported past macOS 28 just fine. It's Rosetta 2 for Mac apps that's being phased out, and not even all of that (they'll keep it for games that don't need macOs frameworks to be kept around in Intel format).
Parent doesn't want to merely run ARM64 Linux/Docker images. They want to run Intel images. Lots of reasons for that, from upstream Docker images not available to ARM64, to specific corporate setups you want to replicate as close as possible, or who aren't portable to ARM64 without huge effort.
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.
Yep, this is another reason I've needed the use of x86-64 images, as although they should be technically the same when rebuilt for ARM, they aren't always, so using the same architecture image which is run in production, will sometimes catch edge case bugs the ARM version doesn't. Admittedly it's not common, but I have had it happen. Obviously there is also the argument that the x86-64 image is being translated, so isn't the same as production anyway, but I've found that to have far less bugs than the different architecture
> Obviously there is also the argument that the x86-64 image is being translated, so isn't the same as production anyway<p>I've never seen this make a practical difference. I'm sure you can spot differences if you look for them (particularly at the hardware interface level) but qemu has done this for decades and so has apple.
Many container images are multi-arch, although probably not ones that are built in-house.
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
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.
This isn't about the virtualisation support - it's about all the Mac system frameworks being available in the rosetta environment
Ask the maintainers to build arm images. Realistically they should be, unless the project uses lots of x86 assembly.
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.
Docker on Mac runs containers in a VM, but the VM is native the cpu architecture and takes advantage of hardware virtualization.<p>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).
Doesn't Orbstack or Colima solve this?
Surely, as it is on Linux, QEMU can take over here in running the x86 images on ARM.<p>Is it slow? Absolutely. But you'd be insane to run it in production anyway.
That won’t be going away, none of that requires any support from the host OS.
Are you running this via that travesty of a desktop app?
Back to the QEMU dark ages
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.<p><a href="https://news.ycombinator.com/item?id=42483895">https://news.ycombinator.com/item?id=42483895</a>
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.
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.
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)<p>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
<i>>Windows running on a 64-bit host no longer runs 16-bit binaries.</i><p>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.<p>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."<p>A <i>lot</i> of software is for x64 only.<p>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.<p>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.<p><a href="https://docs.parallels.com/parallels-desktop-developers-guide/software-development-specific-functions-of-parallels-desktop/using-rosetta-to-run-x86-64-linux-software-on-apple-silicon-macs" rel="nofollow">https://docs.parallels.com/parallels-desktop-developers-guid...</a>
Paralles x86_64 emulation doesn't depend on Rosetta.
> If Rosetta2 goes away, Parallels support for x64 VMs likely goes away too.<p>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.<p><a href="https://www.parallels.com/blogs/parallels-desktop-20-2-0/" rel="nofollow">https://www.parallels.com/blogs/parallels-desktop-20-2-0/</a><p>Nevertheless, running x64 software including Docker containers on aarch64 VMs <i>does</i> use Rosetta. There's still a significant valid use case that has nothing to do with neglected software.<p>Edited my post above. Thanks for the correction.
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.
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.
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.
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.
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.
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?
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?<p>There are many acceptable opposing answers, depending on the perspective of backwards compatibility, cost, and performance.<p>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.
You can most likely use Vuescan, I use that with an old ScanSnap i500 (or something)<p>[1] <a href="https://www.hamrick.com" rel="nofollow">https://www.hamrick.com</a>
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<p>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.
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.<p>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 <i>running software</i>, 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.
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.
This is Apple's "get your shit together and port to ARM64, you have 2 years" warning.<p>If you're not willing to commit to supporting the latest and greatest, you shouldn't be developing for Apple.
That means Steam will release a native Apple Silicon client circa 2028. Exciting!
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.
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
But games are full fledged GUI apps. At a minimum they have a window.<p>It’s really unclear what it means to support old games but not old apps in general.<p>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).<p>So then why say only games when the minimum to support the games probably covers a lot of non games too?<p>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?
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.<p>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.
That's one implementation, yeah, just have a list somewhere of approved software and make an artificial limitation. But their announcement is so vague, it's hard to say.<p>And then the next question is why? It's not like they've ever promised much compatibility for old software on new macOS. Why not let it be just best effort, if it runs it runs?
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.
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.<p>It feels like keeping it alive could really help long-term x64 support on Apple Silicon, even if Apple decides to move on.
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.
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.
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.
No. Only Steve Jobs could have pulled this.<p>Modern day Apple cannot. A bugfix-only release is not going to sell anything.
Why would it mean that?<p>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.<p>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.<p><a href="https://lapcatsoftware.com/articles/2023/11/5.html" rel="nofollow">https://lapcatsoftware.com/articles/2023/11/5.html</a>
> It's a myth that Snow Leopard was a bug fix release.<p>> Mac OS X 10.6.0 was much buggier than 10.5.8<p>Somebody who worked on Snow Leopard has already disagreed with you here about those things:<p>> As the person who personally ran 10.6 v1.1 at Apple (and 10.5.8), you are wrong(ish).<p>> 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?".<p>> 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.<p>— <a href="https://news.ycombinator.com/item?id=43431675#43439348">https://news.ycombinator.com/item?id=43431675#43439348</a><p>> 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.<p>I don’t think the schedule matters. They just over-commit every time. I said elsewhere:<p>> [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.<p>> A while back, that merely manifested as more and more defects over time.<p>> More recently, they began failing to ship on time and started pre-announcing features that would ship later.<p>> 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.<p>> 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.<p>— <a href="https://news.ycombinator.com/item?id=43436105">https://news.ycombinator.com/item?id=43436105</a>
> Somebody who worked on Snow Leopard has already disagreed with you here about those things:<p>It's instructive to read the entire thread, not just the few sentences you quoted. For example, that person later admits, "So yeah, if you are comparing the most stable polished/fixed/stagnant last major version with the brand new 1.0 major version branch, the newer major is going to be buggier. That would be the case with every y.0 vs x.8."<p>> I don’t think the schedule matters. They just over-commit every time.<p>That's a distinction without a difference. Apple has committed to releasing major OS updates every year on schedule. That's a recipe for over-committment, because they need to produce enough changes to market it as a major release.<p>The "no new features" gimmick of Snow Leopard was a marketing lie but was also unique. It's a gimmick that Apple pulled only once, and it couldn't be repeated frequently by Apple without making a mockery of the whole annual schedule. Maybe they could do it a second time now, but in general the annual schedule is still a major problem for a number of reasons.<p>It should also be noted that Snow Leopard itself took 2 years to produce after Leopard.
Not sure why you’re downvoted because you’re right.<p>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
That is more or less what users asking for another Snow Leopard want: a release that <i>doesn't</i> have gratuitous UI churn and superficial changes, doesn't break the end user's muscle memory, but instead focuses on deep-seated and long-standing issues under the hood. If the right thing for the OS <i>in the long term</i> is to replace an entire subsystem instead of applying more band-aid fixes, then take the time to do a proper job of it.<p>lapcat loves his straw man about OS X 10.6.0 having plenty of bugs, but that misses the point of Snow Leopard. Of <i>course</i> a release that makes changes as fundamental as re-writing the Finder and QuickTime to use the NeXT-derived frameworks rather than the classic Mac OS APIs, and moving most of the built-in apps to 64-bit, is going to introduce or uncover plenty of new bugs. But it <i>fixed</i> a bunch of stubborn bugs and architectural limitations, and the new bugs mostly got ironed out in a reasonable time frame. (Snow Leopard was probably one of the better examples of Apple practicing what they preach: cleaning out legacy code and modernizing the OS and bundled apps the way they usually want third-party developers to do to their own apps.)<p>Fixing <i>architectural</i> bugs is still fixing bugs—just at a deeper level than a rapid release schedule driven by marketable end-user features easily allows for.
> a release that doesn't have gratuitous UI churn and superficial changes<p>There have actually been quite a few of those releases. Some of the California-themed updates have been practically indistinguishable from the previous versions. Of course Tahoe and Big Sur brought huge UI changes, but those are the exceptions, not the norm.<p>> focuses on deep-seated and long-standing issues under the hood<p>Which issues would those be, specifically?<p>> If the right thing for the OS in the long term is to replace an entire subsystem<p>Which subsystems need replacement? You claim that this is what people mean by wanting another Snow Leopard, but which subsystems do people want replaced?<p>> misses the point of Snow Leopard<p>I haven't missed the point of Snow Leopard. You're conflating two entirely different things: (1) the point of Snow Leopard as conceived by Apple in 2008-ish and (2) why people in 2025 look back fondly at Snow Leopard. My claim is that the fond memories are the result of the quality and stability that were themselves the result of 2 full years of bug fixes AFTER the initial release of Snow Leopard. Whereas the initial quality of Snow Leopard was not great, just like the initial quality of all major OS updates is not great. Major updates invariably make software buggier, and the quality comes only after much time spent refining the new stuff.<p>My contention is that the marketing lie of "no new features", which is naturally very memorable, is the reason that a lot of people associate Snow Leopard with bug fixes and quality, but that's not actually what 10.6.0 brought, and the quality came much later in time.<p>I'm not saying that Snow Leopard didn't bring valuable changes. I'm just saying that Snow Leopard existed in various stages over 2 years, and the high quality version of Snow Leopard that we remember fondly now is actually late-stage Snow Leopard, not early-stage Snow Leopard, and those 2 years of minor bug fix releases were crucial. Moreover, that's what we need now, a long series of minor bug fix updates, not any new major updates. The bug backlog has become a mountain.<p>> Of course a release that makes changes as fundamental as re-writing the Finder and QuickTime to use the NeXT-derived frameworks rather than the classic Mac OS APIs, and moving most of the built-in apps to 64-bit, is going to introduce or uncover plenty of new bugs.<p>Which is why I think it's very wrong to claim that people want "another Snow Leopard". Snow Leopard II released in 2026 would be much buggier than even macOS Tahoe, which is precisely what people do NOT want, a bunch more bugs.<p>> But it fixed a bunch of stubborn bugs<p>Which bugs exactly?<p>> Fixing architectural bugs is still fixing bugs<p>Which architectural bugs do you have in mind, or more relevantly, which architectural bugs do people in general have in mind when saying that they want another Snow Leopard?
RIP a ton of older audio plugins.
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.
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.<p>-- EDIT --<p>or just move back to windows, but I can't imagine it with the current state of AI bloat
Photoshop plugins also.
macOS has been sending mixed signals to musicians since Catalina. I'd be surprised if people are still seriously using it for studio work.
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.
For sure. But I'd be surprised if a significant number of those setups were running recent versions of Mac OS, especially in older studios. Stability is preferable to new features since old studio hardware is often very reliable and studio engineers are wary of ruining compatibility with system upgrades
I can just imagine the Apple statement, like they did with flash/Flash.<p>‘We fully support the Studio.’<p>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?
That means the end of the Hackintosh era if the OS won't run x86, I imagine it won't install on x86 either.
Aw that bums me out, brings back a lot of memories. Though I assume it’s been effectively dead for a while.<p>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.<p>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. :)
Tahoe is officially the last version to support x86.<p>I never liked the idea, either get Apple, or get one of the other OSes.<p>It was like getting a Fiat Coupe with a Ferrari logo.
Bring back Rosetta 1.<p>User mode emulation for PPC <i>and</i> Intel Mac apps.
Would be nice if they open sourced Rosetta, so that the community could continue support.
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.
Running Windows in Parallels. Even when running Windows ARM version, you still need Rosetta to run Windows x86 binaries.
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.
Ok, application developers will maybe update by then.<p>But this is another way for Apple to say "do not trust us for your gaming needs no matter what PR says".
From the page, inside an large block marked “Important”:<p>> Beyond this timeframe, we will keep a subset of Rosetta functionality aimed at supporting older unmaintained gaming titles, that rely on Intel-based frameworks.
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.
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.<p>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.
May be M7 CPU will run qemu emulation of x86 fast enough for Rosetta to not be required.
Hopefully this will finally push Sonos to produce an Apple Silicon binary.
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.<p>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.
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."
Isn’t that part of Rosetta also used in their own Game Porting Toolkit?
mac for gaming is just not a good idea
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?
Fortunately, whoever has money for a Mac can also afford hardware that will actually run games.
Just use linux. You learn it once and it works forever.
Linux is so not polished.<p>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.<p>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.
> 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.
If only this were true.<p>Stuff in Linux changes. Not quite as frequently, but it does change and in major ways that require significant amounts of relearning.<p>Example 1: audio<p>OSS -> Alsa -> Random Layers on top of Alsa -> Pulse -> Pipewire<p>Example 2: init<p>SysV -> OpenRC || runit || s6 || upstart -> systemd<p>Examples 3: desktops<p>KDE 1/2/3 -> KDE 4/Plasma<p>GNOME 1 -> GNOME 2 -> GNOME3+<p>Example 4: networking<p>ifconfig -> ip<p>Example 5:<p>Xfree86 -> Xorg -> Wayland<p>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.<p>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.
Yes, Pulse pushed me to make my first hackintosh and move from Linux on the desktop to Mac OS on the desktop.<p>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 wasn't saying that anything had to be done, nor was I saying that each change was good or bad (except for the audio and Xfree86 to Xorg). My preferences really don't enter into it. I was saying that Linux systems do indeed change, and the idea of learn once and you're done is nonsense.
Linux is by far the OS with the highest amount of churn.
Forever only if one never updates.
My company only hands out Macs. So I use Linux in a VM for embedded development. Works great.<p>And now I'm getting an Apple Silicon machine in a few months to replace my Intel Mac and I'm out of luck.
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
It will be interesting to see whether they keep optional TSO in their SoCs after Rosetta 2 is no longer working.
As is tradition.
Tangentially, this was surprising<p><pre><code> 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.
</code></pre>
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.<p>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!