With the announcement of an upcoming new macOS release also come the usual changes in which Macs will still be supported. MacOS 27 Golden Gate is an important release in this regard, as it will be the first release of Apple’s desktop operating system that will be entirely ARM-only, dropping support for all Intel Macs. It’s important to note that Apple will provide three more years of security updates for the final Intel release of macOS, so Intel users won’t be dropped like a brick immediately.
Still, the Intel Mac Pro was still being sold all the way up until mid-2023, and I’d be royally pissed off if my expensive 2023 Intel Mac went out of support a mere six years after purchase. They weren’t cheap machines, and while you can argue everybody knew the writing was on the wall for the Intel Mac Pro in 2023, it still feels way too short of a supported lifespan for such an expensive, high-end piece of equipment. It didn’t sell many units, I’m sure, but still.
In addition, MacOS 27 will be the last release to include the Rosetta 2 translation layer that allows Intel binaries to run on ARM macOS. I have no idea how many important applications are still Intel-only, but I have a feeling that number is going to be relatively small, and will become even smaller as the first macOS release without Rosetta 2 support nears release. On top op of that, I’m sure enterprising users will find a way to transplant Rosetta 2 onto unsupported macOS releases, and if all else fails, there’s always virtual machines.
If I had bought a Mac Pro in 2023, I would know what I was buying. I think 6 years of core OS support is a reasonable expectation, after which, the machine still functions, albeit without security support. But it could be reused for a Linux install to prevent the hardware from being e-waste.
That said, I suspect no one was buying these without any idea of what they were doing. I bet they were mostly enterprises keeping the existing fleet stacked. And they had to know time was short for the Mac Pro.
One use case I can think about is people who need endless amount of RAM. Although, by now, most software/datasets that required such amount of memory are probably now optimized for ARM or architecture/OS-agnostic and are probably now running on Linux and something akin to a ThinkStation.
For me, from 2003 until the time Apple ended support for Mojave, macos and Apple were the best solution around. The latest classic Mac Pro was legendary – I daily drove one for ages and, for a while, I quad-booted macos, windows, freebsd and Linux – and even Haiku ran perfectly well! MacOS could run everything. I had photoshop, I had quick access to most open source tools, a decent terminal. I could still run ancient scanners, deal with huge image scans (thanks RAM), drive audio interfaces and even reboot into Windows to (very rarely) play a game or deal with the oddball application. But 99% of what I had to do, I did under macos.
Then, little by little, Apple disappointed me. Migrating away from Aperture was a HUGE trauma. I relied on almost all its pro features. I didn’t like dropping 32bit support either. Some old software realistically will never get ported and not everything is an online tool with a huge attack surface. Then yea, the huge middle finger, let’s spend thousands of euros with audio interfaces – no thanks. I’d rather retire one day.
So now I live under Linux/FreeBSD, eventually boot into Windows for my IT gigs or to drive legacy hardware and the macpro is here if I need to load my old aperture libraries or use my hdmi capture card. Apple used to cover all my edge use cases and my daily needs and now they only cover the needs of users who are fully within the ecosystem or people who only depend on the most modern productivity tools.
I have SEVEN iMacs (including my 1998 Bondi blue iMac and the ones with the largest screens for each generation of iMacs) that I have running on my two six foot tables with my seven monitors. Not everything is Mac though. I have an OS/2 machine (yes, OS/2) and I’m working on a Haiku OS (not the poems but the OS) so that is Nine computers with 10 monitors. And if I could fit more (note, more and more are being stacked vertically since I have no more room on my tables.
My most current Mac is a late 2019 27″ iMac. My eyes are getting WORSE, not better, so smaller screens is not better Apple! So far I haven’t decided if I’m going to buy another Mac or not. 50/50 right now
It SUCKS that you can’t run a lot of the great old games on newer Macs but are forced to run old Macs to play games that I still love. Which is part of the reason that I like running OS/2 because I can run a LOT of old retro games for DOS and Win 3.1 which run SIGNIFICANTLY better than booting up DOS or Win 3.1 outside of OS/2.
I’m still hoping that the Haiku group finds some people to create graphics drivers for that OS. So if you know how to write graphics drivers and you are looking for a challenge, contact the Haiku team https://www.haiku-os.org/ because they could really use your help as they work on getting that open source version of BeOS running AAA games which can’t be run now. PS: Forget about 32-bit versions, focus on 64-bit) Thanks in advance
For anyone who is not sure how to identify installed Intel apps before Rosetta is discontinued, there are two easy ways to do so.
1) Open the “System Information” app in the Utilities folder, scroll down the left sidebar to the “Software” section, click on “Applications”, and then sort the resulting list by “Kind”. (It may take a moment or two for the list to appear.)
2) Use a third party tool, like the free “Go64” from St. Claire Software. As with “System Information”, let it scan your drive and then sort by “Architecture”.
Of course, there are other ways to scan your drive for Intel software, but the two above are quick and easy.
My daily driver is an Apple Silicon Mac whose software has been migrated through a series of Macs going back roughly twenty years, so one might expect that I’d have a lot of Intel apps installed. In fact, most of the Intel apps that remain are small support utilities. The only Intel apps that I have that will be mild annoyances to lose are some vendor-supplied utilities for ancient printers, a quirky graphics app, and a very old darg-and-drop PDF optimizer. Everything else has been quietly upgraded to either Universal or Apple Silicon architectures over the years.
An important bit of context here is that Apple has only been providing 6-7 years of support for their hardware since about 2012. Support for Mac Pro has been based on release year, not when you bought it.
If you bought a Macbook in 2015, you got 5 years of major updates (to Monterey) and then 2 years of security updates. If you bought the last Intel Macbook Air in 2020, you got 5 years of major upgrades (to Sequoia) and 2 years of security updates. Those are both 7 years total support.
If you bought a Mac Pro in 2023 (Intel) you get 3 years of major upgrades (to Tahoe) and 3 years of security updates. That is 6 years. Less but not much less.
How about the Mac Pro specifically?
Well, the 2012 Mac Pro Tower got 6 years of upgrades and 2 years of security updates – 8 total. The 2013 trash can Mac Pro got 8 years of upgrades and 2 years of updates – 10 total. The 2019 Mac Pro got 7 years of major upgrades and 3 years of updates – 10 total.
So, the 2019 Mac Pro is getting the exact same level of support, or even better support, as previous generations.
If you bought a Mac Pro in 2023, it was the 2019 model. And yes, that means you are only getting 6 more years of support. But if you bought the 2013 Mac Pro brand new in 2018, you would have only gotten 5 years of support. Even worse!
I am not defending Apple here. I do not use macOS. This is being typed on a 2012 Macbook Pro running version 7.0.10 of the Linux kernel and KDE Plasma 6.6.5. I hate old software. But Apple is offering the same level of support now that they have for the last 20 years. If you chose to be an Apple customer, it is a bit late to be outraged by that.
It’s a bit sad to see it go considering that Rosetta 2 is a top notch x86 code translator. It doesn’t need to die and in an ideal world apple would open source it so the community could continue its development rather than consigning rosetta 2 to the grave yard. Alas, the world is not ideal.
In a less than ideal world, Apple could sell it as a paid addon in the future.
The123king,
I didn’t see anything about this, did you read that apple were doing this anywhere? I’m under the impression that it’s being completely killed.
I was talking in exactly the same sort of hypotheticals as you.
Apple wouldn’t open source it, selling it as a paid product would be much more likely. But no, there is no evidence they are doing either.
I am perfectly fine with ending Rosetta 2 MacOSAPI for Mac Apps at this point. There is little reason a Mac App should not be native by now. Dropping the macOS-x86 frameworks saves space and simplifies. I understand that, especially from an efficiency perspective. once upon a time, I would have disagreed, but this has been the status quo for a while, and all critical apps are available for Mac. I have not even used wine in a year.
I do wish/hope they keep the lower level Rosetta 2 available for things like running x86 vms on an arm Mac. This also helps with Wine which I do use ones in a while. I know we can still run older macOS in a VM, to keep Rosetta on a newer machine. If you want to, you can run Snow Leopard Server under a Rosetta2 vm. That lets use run PPC apps using rosetta1. :). Except you loose graphics acceleration.
mattsaved,
I would imagine most people don’t require legacy software for their daily use cases. However being able to run old software can be useful. Sometimes I feel inclined to pull out old software and give it a go, even if just to show the kids old games and software I grew up with. Apple’s 6-8 year target window isn’t very long, especially for irreplaceable niche software where the original developers are longer be around, it makes windows a safer choice for niche applications. Also sometimes the old software is just better. For example, many people feel that new software is getting enshitified. So even if a new version of say Adobe or Office is available, some users may prefer to keep running the old version as long as possible. Obviously the loss of rosetta 2 is unfortunate for them.
There’s a plethora solutions to this, not least virtualization/emulation. Sure, you won’t be able to run Rosetta on your bare metal MacOS install, but there’s nothing stopping you from using a VM to run older versions of MacOS.
You’re making it sound like this is the first time an OS has dropped support for something. But here i am, still able to run Win16 applications on an x64 Windows machinemachine, whilst simultaneously running MacOS System 7 in an emulator, whilst i code BASIC programs for my obscure RCA MS2000 in another emulator.
Of course, if you’re dead set of keeping Rosetta on an M1 Mac’s bare metal install, then just /don’t upgrade/. Or keep an older machine around if you don’t want to daily it.
There’s many ways around this issue, as it’s an issue we have had since computers were invented pretty much.
The123king,
You’re not wrong about being able to use an emulator,/translator as a solution, but I think it’s fair to point out that Rosetta 2 already IS that solution for x86 on ARM. Ending this solution is what’s unfortunate.
Maybe qemu could be used to replace rosetta 2 to continue running x86 programs, but I can tell you QEMU is not nearly as optimal at runtime translation. The main benefit to switching from Rosetta 2 to QEMU wouldn’t be that it works better, but that it’s FOSS and not subjected to apple’s corporate whims.
Of course I get that…that’s apple’s ultimatum. However I don’t see how it rebuts the point I am making that it represents a real loss for the retro software community. Obviously I don’t think apple gives a crap, but if they did the best case outcome would be for apple to open source Rosetta 2 and just let the community maintain it. Frankly Rosetta 2 was one of the better solutions and though I do accept your point that there are other solutions, none are as good.
@ mattsaved
FWIW there is a strong possibility that Rosetta support will be removed from future macOS releases, and that future Apple cores may drop HW support for aspects of the x86 memory model.
That said, recent ARM extensions add features that can significantly improve performance when emulating stricter memory ordering semantics. Qualcomm and Microsoft appear to be using similar mechanisms with Prism in Windows on Arm’s x86 emulation. As a result, virtualization or emulation frameworks for non-ARM blobs on macos could remain viable even without Rosetta, though probably not at the same performance or efficiency levels.
Virtualization/Emulation acceleration aside. Codebases should have been ported to ARM long ago. For any well-behaved Xcode based project, the process is usually fairly straightforward, and most serious macos vendors should already be shipping native AS builds.
while linux runs on 15 year old hardware with zero problems. Browsers have no issues, while on a Mac, Apple Chokes you into upgrading, why? THEIR profit. With the increase of mem prices converting over will be more expensive. in the next decade mac’s WILL be more expensive, there is No Doubt on that. Milk out your intel mac as long as you can!
I’ve got a late 2019 27″ iMac and I’m one of those milking it out for as long as possible. I still haven’t decided if I’m buying any new Apple devices other than iPhones. Android phones … just a no-go for me and there really isn’t any other phones of any interest to me. Not because they aren’t Apple but because I can’t use them as my key for my Tesla and many other things that are iPhone/Android only options for connecting to many devices.
I still run all of my iMacs (one (or more) for each generation going back to my ’98 Bondi Blue iMac. I have too many games I still enjoy that only run on very narrow (five to seven year) windows. The reason I have multiple of any generation is because the others are from my wife who isn’t using them anymore so I’m adding to my backup hardware in case/for when my iMacs die.
This may affect some scientific open-source projects that have been slow to port to ARM64, such as 3DSlicer, which, despite being quite popular in medical imaging research and having more or less adequate funding support, has struggled to fully transition to ARM64 on Mac. They just commented in their forums that they now have to put the foot on the pedal. For those projects that may end up in abandonware but are still used by small pockets here and there, this will be bad news.
I still use (writing in one right now) my old 128 GB iMac Pro, which was the best investment I could have made in 2017, and that is already not supported in Sequoia. The only reason I might have to put it aside is my institution forcing me to unplug it because it’s no longer receiving updates, and it would be a shame because it still runs super smoothly. And no, I won’t install Linux on it, the recent months with our brand new Linux workstations have showed us in what such bad shape is Linux Desktop.
SamAskani,
I assume that iMac Pro is x86? If so it should be pretty well supported by linux. Of course whether or not linux serves your needs is a different matter. Users often lament switching after using windows or macos for so long. I was forced to use macos a couple of times and honestly I felt the same way about macos as you feel about linux, It felt off-putting that my skills didn’t carry over cleanly (made worse by the fact that it was making me look like a nube in front of the client, haha). Things that don’t work the way one is used to causes frustrations and this gets amplified moreso if you have to switch the OS AND the applications.
Naturally people are most comfortable with the platforms they’ve spent the most time with and unless there’s a significant factor motivating them to switch the tendency will be to stick with whatever they know.
I used Linux as my desktop back 10-15 years ago, and I was all happy. I have used *nix variants since SunOS/AIX/HP-UX times, so loooong time ago. When I used Linux at that time, if I just had regular package channels, I just kept a regular update for security, successful upgrades to newer distributions, and the occasional “oops, that distro upgrade broke things”, but they were rare. Fast forward 2026: Brand new Dell Precision workstation with 768 GB, dual CPU , dual GPU, Ubuntu installed in factory. It boots, all ok, let’s do a first update of packages using the default channel… booom…. it messed up the drivers, black screen, only way to fix it is via SSH because the the graphics are dead. Some roll back that didn’t work, so let’s reinstall Ubuntu cleanly, and follow obscure instructions how to re-enable in one of the 10 “official” guides how to have NVIDIA GPUs with the right drivers (it feels like russian roulette) with CUDA enabled.. Ok, it boots again, let’s install xRDP and XFCE because we prefer a light environment. XFCE starts…. then all menus are broken, like you click somewhere, and the menu appears 100 pixels away, if you try to open terminal with the right click button, nothing happens, the only way to have a terminal is to call gnome-terminal because the XFCE one does not bother either from the menu (once you play 100 pixels away with the mouse)…. Firefox refuses to open… or shows broken pages… it is a random thing… sometimes open, others not, then forced to install chrome, which seems to work ok, but the XFCE issues continue to mount, so we gave up, back to GNOME… so all looks stable now… then the first automatic update happens, and back to black screen. Reinstall OS and repeat, and we end up freaking disabling automatic updates, which is harder than in Windows these days, with multiple settings to look through, so we end with a system that is too disruptive when you do the most minimal update, so it will remain unpatched for , let’s say a year, since we know we will have to deal with all this. Back in the day, I never ever had to deal with such a level of brokenness. In the old days of SunOS (even before it was called Solaris), I had fun installing new software and compiling the whole thing from scratch. Even in many of the early Linux distros (I have fond memories of how rock-solid CentOS was, man, even Fedora was never this broken), the whole experience was great… Now… sorry but no, this is not an issue that I’m too macOS-ed, I worked for years with Linux desktop, the problem is that I’m old enough to remember how good it was, so I can attest how insanely bad it is now.
SamAskani,
This used to happen to me a lot when installing the proprietary nvidia driver. It would disable the distro’s driver. The proprietary driver would work for a period until broken by linux ABI changes. To make matters worse, the distro’s default nouveau driver that works remains disabled and the screen goes black on bootup. This matches what you are describing. Sideloading out of tree drivers on linux has always been problematic. This problem is not characteristic of drivers that ship with the distro.
Given the “driver update -> black screen”, I’m almost 100% sure it’s the way you installed the driver that’s caused that. There’s different ways to install nvidia’s proprietary driver and if you follow an old guide it may have put you on a path of using the old fragile method. It’s absolutely critical that you install the “open source” nvidia driver, and not the proprietary one, which is very misleading because the only real open source driver for nvidia cards is nouveau….what nvidia’s talking about is the open source kernel ABI they committed to mainline.
End users shouldn’t have to know any of this, however most end users don’t attempt to install their own drivers and would not have ended up in your predicament, haha. The changes you made likely created the problems you had, they don’t normally happen out of the box. I can’t fault you for not knowing what you don’t know….the situation with proprietary drivers on linux kind of sucks. Incidentally this is why a lot of linux users hate nvidia.
To be perfectly honest, Linux has gotten so much better with respect to out of the box hardware compatibility. I get that you needed to use CUDA, which isn’t supported out of the box 🙁
But had you stuck to the default open source drivers that ship with the distro, I am quite confident that you wouldn’t have had any of these problems.
I sympathize with you over the bad experience, however I put it to you that maybe the linux distro was not at fault and it was the proprietary drivers you installed. Blaming the distro here would be like blaming apple when a user installs a 3rd party kex driver that breaks the system. Obviously it leads to a bad experience on macos, but it isn’t necessarily apple’s fault.
The problem you’re highlighting there is that so long as Rosetta exists, some developers simply won’t bother porting their applications to ARM. Even today there are things which are still being shipped as x64 only because “it works in Rosetta” despite the hit to performance and battery life.
Apple dropping Rosetta forces these holdouts to finally update.
In many cases (and certainly if your application was properly written to start with) it’s no more than a recompile anyway.
bert64,
You could be right about there being some developers of supported software who hold back. However old software and games with perpetual licenses that are no longer supported will become unusable since there isn’t going to be a replacement.
Granted apple tends to break compatibility more often, and we could argue that apple users have come to expect this from apple. But imagine if windows tried to pull this off, both gamers and industry would be livid. Those customers expect titles they bought to keep running long term. Heck microsoft were severely reprimanded by their customers for their move to degrade legacy applications in windows 8.
Yeah. Any Mac developer whose codebase was not already capable of producing fat binaries should probably be treated as deeply incompetent.
This has been the intended model since the NeXTSTEP days FFS. Apple’s system APIs, development tools, and platform conventions have long treated portability as a first-class citizen.
So if anyone is out there writing software in Xcode and their codebase cannot be recompiled for ARM without falling apart, they have effectively missed the last 30+ years of how this platform was designed to work… they are bad and they should feel bad about it.
A bit harsh but I mostly agree with you. Apple has had about the same support lifetimes for decades now and this is not their first hardware transition. Apple applications are expected to migrate to newer versions of the OS more than macOS is expected to maintain compatibility with older applications. This has been the expectation since forever. That is the contract you agree to when you develop for macOS.
Xanady Asem,
I’d agree usually code bases can be recompiled for ARM assuming you have all the code. However commercial software especially can link in proprietary libraries that don’t get distributed with source. Years later, the full source code may not be available to port the software. Even if a new ARM library available for purchase and the publisher is willing to buy a new license for it, it may not be a 1:1 replacement for the old obsolete library. New development/testing/debugging could be required just to get the software going on ARM. For titles like games where the development was done by contractors and who’s teams have long since been disbanded after completion, it could genuinely be infeasible to create a new ARM build without buying new licenses and hiring a new team for a discontinued game.
IMHO this is best avoided by only using FOSS, however for better or worse it’s common practice for commercial software to rely on proprietary tooling without source.
Yep, I knew it. I knew they’d kill of Rosetta 2. Called that one!
Next they will remove the x86 memory modes from their silicon. Be ready for it!
CaptainN-,
I’ve asked this before but wasn’t able to find the answer: is there actually an x86 memory mode that needs to be enabled or did apple just implement x86’s strict memory behavior by default such that memory behavior is always the same for both x86 and ARM code?
The reason this question is important is if apple implemented coherency by default across the chip, it means apple cannot take it away without potentially introducing new bugs in software that assume x86 memory behavior even on ARM. This is potentially very significant because the majority of software was ported to ARM from x86 and it seems plausible for macos software developers to have never tested their software on an ARM chip with less strict memory barriers & coherency.
In other words, the moment apple removes x86 memory coherency might be the first time macos 3rd party software gets tested in such a configuration. Consequently this could result in software starting to exhibiting strange race conditions on new ARM hardware.
This link is for illustrating the concepts and does not cover apple chips specifically.
https://github.com/Broadcom/arm64-linux/blob/master/Documentation/memory-barriers.txt
Apple’s TSO mode (aka the x86-like memory ordering model) is vertically integrated with Rosetta. It is primarily there to support translated x86 code, so it is used by Rosetta code paths only.
For everything else, Apple’s cores use the standard ARM weak memory model. That is what the ARM ABI and native code generation models are built around.
So if Rosetta is eventually removed, there is little reason for Apple to keep supporting that proprietary extension in future cores indefinitely.
First, there is a performance cost. On M1, I believe TSO mode had roughly an 8.94% average perf hit compared with normal native ARM ordering. There is also a business and engineering cost. Supporting TSO adds validation overhead, microarchitectural design complexity, and another special execution mode that has to be tested across generations. With Rosetta gone, Apple’s HW design teams likely pushed to remove that feature from future cores.
FWIW, native macos ARM software does not need x86-style ordering at all. It targets ARM’s memory model only using the appropriate acquire, release, and barrier semantics, so it should never need to trigger the TSO paths in the uArch. Once Rosetta is no longer part of the system stack, TSO becomes mostly a vestigial compatibility feature w/o any strategic application.
Also, recent ARM arch revs have added features such as FEAT_LRCPC, LRCPC2, and LRCPC3, which help code generators obtain stronger ordering semantics more efficiently through documented ARM mechanisms. That means future emulators or runtimes can still support x86 memory-ordering semantics but using public ARM instructions, instead of relying on Apple’s proprietary (mostly undocumented) TSO mode.
The only strong reason I can see for Apple keeping TSO mode support after Rosetta’s retirement would be efficient x86 VM support. But even there, the same issue remains: those modes are not broadly documented as a stable architectural contract unless Apple provides and controls the virtualization infrastructure itself.
So my guess is that Apple will not bother keeping TSO support in future cores once Rosetta is no longer part of the system software stack. There is no value proposition for it w/o Rosetta.
Xanady Asem,
I understand this, but that does not automatically imply that apple made the logic conditional. Without a source I wouldn’t say the matter is settled. However I did manage to find a source…
https://www.sciencedirect.com/science/article/pii/S1383762124000390
Apple does not publicly disclose much of apple’s micro-architecture, which is what I ran into, but they managed gain insights by reverse engineering and they do confirm that it is a toggle.
I agree that’s the normal ARM convention, although nothing would prevent an ARM implementation from using strict memory conventions like x86 does. In any case the link earlier answered this to my satisfaction and you are right that it can be disabled in apple’s implementation.
They are definitely going to remove that from Silicon, as it was always tied to their own interest in backward compat support for x86. But that said, it’s not as big a deal now in 2026, as it would have been in 2022. There are other projects that can emulate x86 on ARM, such as Valve’s own FEX – so maybe this isn’t as catastrophic as I initially suggested. https://www.osnews.com/story/143782/valve-brings-x86-gaming-to-arm-linux-with-fex/
CaptainN-,
I know there are x86 on ARM emulators, I’ve used both Qemu and FEX to emulate x86. Unfortunately both are quite slow. Worse yet, when I tried FEX a year ago there were a lot of things that just didn’t work (I actually alluded to this in your link); I found FEX to be alpha quality at best. Much like ReactOS, it’s a good idea in theory, but reality leaves a lot to be desired. Hopefully it does get better. because I have use cases where FEX would be useful for me personally. FEX is designed for linux though and it’s not clear to me that it could fully replace Rosetta on macos?
This is not to write off steam’s ability to make it happen, but I’m not sure where they stand. There’s already precedence for dropping backwards compatibility with architectures unsupported by apple.. 32bit games are already gone for example.
https://arstechnica.com/gadgets/2023/11/steam-drops-macos-mojave-support-effectively-ending-life-for-many-32-bit-games/
Steam did release a native ARM client for support macos going forward, but I haven’t seen an indication it will support legacy software.
https://www.macobserver.com/news/steam-to-drop-support-for-macos-big-sur-in-october-2025/
In the same way that steam/proton has not solved all windows software compatibility issues on linux and FEX has not yet solved all compatibility & performance problems across architectures, I think would be premature to conclude that legacy software is a solved issue on a post-rosetta macos. If you have any info that they intend to continue supporting x86 software on macos despite apple’s plan to kill off legacy support, I’d certainly like to hear about it!
And Tahoe is unfortunately not yet supported with OpenCore Legacy Patcher