Apple could easily make gaming on Mac feasible by contributing to Proton, Wine, DXVK and officially supporting Vulkan at least through translation layer.
Or just partner with Valve to do exactly this for their platform.
Instead they choose to build another proprietary solution nobody gonna use and that will die as soon as they lose interest.
I agree with you on wine, and I wouldn’t be surprised if they are doing this quietly (landing patches to make
Wine better on Mac), but for the purposes of making directx shaders perform better I fail to see why it matters if they support dx to metal conversion or if they support vulkan (for the goals of making games run better for their customers)?
> It matters because if Apple embraced Vulkan it would give more market share to one standard API for non-Windows platforms.
How does this actually help Apple customers have a better experience in some unique way that live translation to Metal does not? Runtime GPU compilers already do plenty of runtime translation; having worked on several I could be convinced having a simpler interop layer would make things smoother but your argument comes across as ideological more than about shipping product.
> Their strategy trying to push proprietary solutions simply doesnt work when their OS have 2% of PC gaming market share.
Hardly anyone one uses their proprietary solution (Metal) directly. But that doesn't mean Vulkan is going to be some panacea of gamer/game-dev adoption.
> Apple announced game porting toolkit 3 years ago and no one uses it. Well, unless Apple fund ports as PR stunts.
While I agree its not that widely used for porting actual games, I think a lot more people probably do use D3DMetal to run Windows games on mac.
> How does this actually help Apple customers have a better experience in some unique way that live translation to Metal does not?
By decoupling the support for Windows games from Apple's whimsical downstream release cycle, obviously. Proton would build perfectly fine on macOS with proper DXVK support, enabling the "same day" support patches that the Steam Deck and Steam Frame enjoy. There would be no need to wait to play games like Arc Raiders because all you'd need to do is update your Proton runtime. Users would get have more flexible options for playing new games that Apple doesn't support with GPTK point releases.
> But that doesn't mean Vulkan is going to be some panacea of gamer/game-dev adoption.
They can perfectly well support both APIs. If Apple wants to have a mobile-first rendering API on their desktop, fine, but it shouldn't hamstring the other features of a computer like eGPU support or basic third-party drivers like Mesa. There's no reason it would.
I’m not entirely sure what apple’s interest in any of this is. Would it get them any additional customers? What portion of their customers would be significantly more happy with games being somewhat more optimized a few months sooner? I just don’t see the value add here.
I’m not sure the community needs that much support from apple either. Lot of projects have figured out how to targete AIR directly by now.
I wish this were/is true, that Apple supports Wine development.
But as far as we know, a year from now Apple will end Rosetta 2 support in macOS 28, and with it the ability to run Wine.
My theory is that Apple chooses to make gaming a second class experience on Mac because they don't want the Mac brand to be associated with the main demographics that play AAA games.
The Mac brand is already associated with Apple zealots, and they don't seem to care about that, so that's obviously not it. It's more that Jobs personally didn't care for games. He put an end to Pippin and Game Sprockets as soon as he returned. Now there's still some inertia against gaming, but if they can figure out how to make money off gamers, they'll be more than happy to.
Granted this is just my personal spend, but Apple has lost out on something like $12k of hardware sales from me over the past six years because they don’t support gaming. I switched to Linux in 2020 because it meant I could have a proper development environment AND play games. Before I was split between Windows and Mac, having to buy two machines— one for gaming and one for development.
If Apple didn’t treat gaming like a red-headed step child I’d have never made the switch. Now, it’s an incredibly steep uphill battle to win me back to MacOS. Linux slaps and NVidia has way better performance (though I wish I could get more than 32GB of VRAM without forking over $10k).
So yeah, while they might not like stereotypical gamer[1] types, I’m sure they’d like their money. For me the only Apple device I buy is a new iPhone once every 4-5 years. My lifetime value (to Apple) is essentially roughly 25%-33% of what it would have been if they supported gaming.
[1] I think more people play games now than ever before. While 20 years ago gaming might have been niche, we have multiple generations at this point who have been playing video games their entire lives. Realistically, it’s only boomers who haven’t played video games (or had access to them) the majority of their lives.
This, once again, misses the elephant in the room.
The fact is simple, there isn't enough of a Mac gaming market for the game developers to go through the effort.
The hardware has been good enough for a while now.
I'm not saying this will never change but the developers that shipped games on PC and Mac report something along the lines of 6-11% of users use a Mac. That isn't worth the effort unless you have a very strong IP and you've already targeted the switch2, the PS5 and XBox.
I disagree. When OS X went to Intel, there was an explosion of Mac games on Steam. Valve went all in with big ports of TF2 (complete with exclusive era-appropriate in-game items like the earbuds), and all their other games soon followed.
Apple self-owned themselves by slowly killing off support for this, culminating with the transition to the M chips and the upcoming removal of Rosetta to put the final nail in the coffin. Their negligence to support a major market is their downfall here. The hardware is more than willing, the software and company are causing the fumbles.
It could be argued that was a "right place at the right time" situation. macOS supported OpenGL at the same time as Valve was pushing for the original Steam Machine and native Linux ports. Writing a macOS port was a much easier job back then.
Apple's pivot to Metal and mobile-first distribution was the beginning of the end. The iPhone's revenue potential eclipsed the value that Mac gaming could ever provide, and Apple made sure to capture it with the App Store. Once Tim Cook showed everyone how easy it was to make service revenue, the execs probably realized that they could make bank off of a captive, game-deprived customerbase.
Easy fix. Apple can just stop breaking compatibility and partner with Valve to port Proton support to Mac.
But they wont do it because they want to push their own walled garden. And obviously no one will support it because macOS market share is smaller than Linux market share.
That's because it makes no sense to use Steam on macOS because there are nearly no compatible games and Steam itself only has an ARM version on Beta and the Intel version is unusably slow. Overall a catch-22 situation though.
Its not like every single Linux PC have Steam installed either. And if you run Steam client under Wine / Crossover it able to properly detect real platform.
That's not the elephant in the room. The elephant in the room for gaming on Mac is Apple's policy non-commitment to traditional gaming. Technical support for non-gambling gaming is just a checkbox item to them for mandatory 45-second segments in product launches. That transcends into their customers and develop into various gaming and Mac related chicken and egg problems.
Maybe I'm too unambitious as a small indie, but "porting" my game to mac merely requires building that target (I use unity & have both mac and windows automated building scripts - I press a button and it builds and uploads both to steam). There's nowhere in my codebase where I had to specifically adapt to one or the other.
Some engines nicely support Mac out of the box. I’m making a party fighter in LOVE2D and am having a good time developing and playing on Mac (cross platform online play is working well too, my friends are all Windows).
Maybe Unity or Godot also offer this benefit? If so then Mac gaming could become much better supported, at least from indies!
Apple is getting kind of a PR problem with developers. In theory they don't do all the same things on Mac as they do on iOS, but as long as they continue to do them on iOS and keep feature creeping the gatekeeper stuff, people are hesitant to end up stuck with Apple taking 30% of their revenue or denying their app for opaque reasons after they've spent big money to develop it.
At which point who is going to spend development resources helping the platform of the company they're most afraid of screwing them if it becomes more popular? Half the reason more game developers are targeting Linux is a hedge against Microsoft doing that sort of thing, and Apple is on the opposite side of where they want to move.
This idea that Apple has been plotting this whole time to turn the Mac into iOS, in terms of limiting the software you can run to their own App Store, is a tired meme that makes zero sense given what we've seen from Apple in the past...checks...19 years.
Like, seriously, do you think they need longer than that to do it if it's really what they plan?
If they were ever going to do it, it would've been when they switched to Apple Silicon chips, and...they didn't!
Perpetuating the idea does no one any favors. It's just pointless paranoia.
They've been gradually making it harder to install third party software without their approval.
The Mac App Store hasn't existed for 19 years. Then they started displaying scary warnings for apps downloaded from the internet. Now they require code signing for third party apps. Meanwhile they not only obviously do it on iOS but are adamant that no one even attempt to do otherwise, even in the face of law requiring them to.
It's not paranoia when they're really out to get you.
> If they were ever going to do it, it would've been when they switched to Apple Silicon chips, and...they didn't!
They did, though;
- macOS lost support for eGPU and dGPU drivers
- OpenGL support was frozen to focus on Apple's mobile GPU API
- Apple promoted Mac Catalyst apps instead of pushing Mac-native ones
- The iOS and iPadOS App Stores became available on macOS alongside the native store
- The macOS design language was reworked to take cues from overly padded touch-first design
- iBoot became the hardware entrypoint, which Apple has authority over with OTA updates in macOS
- UEFI and ACPI went away, forcing devicetree drivers to be reverse engineered with zero documentation
Old Macs are just computers. None of these limitations apply to them because you can pick one up and install a normal OS if these concessions concern you. Apple Silicon was shipped in a way that deliberately prevented reverse-engineering and gives Apple the ability to revoke boot-time features if alternative OSes ever threaten them. They depreciated vast swathes of functionality that professionals relied on, and eventually depreciated the Mac Pro altogether. Their tentpole desktop products are a Mac Mini, a bigger Mac Mini, and the iMac. There's not any hardware left for real pros.
But you're still unconvinced, right?
Well, look at Apple's revenue breakdown. The Mac is not carrying much water, and it's a huge sinkhole of resources to constantly maintain and update the OS on a yearly update cadence. Conversely, the iPad is doing great, making almost as much money as the Mac does with vastly cheaper hardware (and bigger profit margins, too). If Apple could have their druthers, they'd start polishing the iPad experience, ship "Pro" hardware to entice developers and boundary pushers, slowly roll out support for HID and external display support, and eventually provide a sort of cloud service for building applications within the Apple ecosystem. Oh wait, I've just described things they've already done! https://developer.apple.com/xcode-cloud/
Apple has no obligation to their niche pros, anymore. They already cut them out and depreciated their rackmount and short-lived wheeled PC. I have no doubt in my mind whatsoever that Apple is internally laser-focused on depreciating the Mac and macOS both, either with the Vision hardware or by promoting the iPad as a laptop replacement a-la Microsoft's Surface Pro.
Nah there will be a new model and a new OS version on it that will only lets you use the App Store (30% tax of course). People here will complain and a fuck ton of people will dick ride Apple with bullshit about how they shouldn't buy that new laptop and they should feel privileged for Apple allowing any money to go to the person actually providing you value.
If it gets popular enough then they start trying to get games to use their app store instead of Steam, gradually make it easier to use that and harder to use anything else, then the gate closes only after the herd is where they want it.
Better, then, if it never gets popular enough to begin with.
I think you are right. I suspect any mac gaming share that gets bootstrapped will have to come the crossover/proton way. Thats probably good enough for starters.
Most of those are gonna work using Rosetta, crossover, and the game porting toolkit.
You really don’t need Apple to support 32Bit x86 macOS games when it’s not much more overhead to run windows x86 games (which is easily the better library to spend time
Optimizing for).
It isn't; they specifically have said it will be retained. They aren't too specific but I think what they mean is all the Framework and App support for it will be gone. But as far as keeping a lot of self contained games and wine running I think it'll likely continue to work fine.
I’d really be surprised if they broke codeweavers’ stuff.
Also who cares if the wine exe itself can run as x86? Ideally you want something that resembles windows chpe where the loader is native but works with the translator to bridge translated game code to native sys/lib calls.
Why bother with macos version at all then? Soon current version becomes unusable as well, and needs windows fallback to run since macos version is useless
If there's a macos port, it'll of course be better optimized. I play CS2 on mac from time to time. It runs really smoothly on my Studio, but if it were a native port I could run it on a macbook air.
from the point of the dev - work done on the port will rot very soon, return of investment is really low. Also, the studio may not exist at all by time changes will be necessary - as fast as few days after public release nowadays :(
The high pixel response time on macbook displays means you'll want an external monitor for multiplayer shooters etc., which most gamers are already fine with, but annoying if you want to game while travelling.
I don’t think it matters. My Studio Display XDR has pretty bad motion performance (similar to Macbook, maybe a touch better) and you can still play first-person shooters perfectly fine. In the general case you don’t notice it much. It’s only a problem with fast planar movement, e.g. strafing along a wall and trying to read some text that’s written on it. (Spelunky 2 is much worse than CS in this regard, but still not a massive issue. Just a bit ugly.)
Not a “Gamer” so I’m always surprised small things like this make a difference.
As a rule of thumb, what is a minimum frame rate a game needs? From there how much does each extra fps make a difference, and at what point do you hit diminishing returns?
Pixel response time is a related concept to framerate but more about how long it takes a pixel to change from one color to the next. Usually measured in cycle time from grey to grey again, a low rate just means that images will be smooshy looking, have unclear boundaries, and end up with a 'motion blur' effect. So even if your mbp supports a reasonable sounding 120hz (8.33ms for a full frame sweep), some of those pixels will still be in transition when the next frame hits. At least, my take on it as a somewhat casual gamer.
e.g. if you're playing a single player turn-based strategy game, you might be taking a few seconds between each decision & UI interaction. Some hard turns you might step away from the computer to think things through for minutes without touching the controls. 30fps for a game like that could be fine. 15-20fps might even be fine, especially if the game engine manages to avoid adding unnecessary input latency & is able to process input events at a faster rate even if the render runs at a low framerate.
If you're playing competitive FPS games, where reflexes matter, you'd want to get input, network & video latency as low as possible, within reason. Not high-frequency trading low. I have no idea at what point it stops making a competitive difference. If you have +100ms more latency than I do, I suspect that'd give me a noticeable advantage. If you have +10ms more latency than I do, I'm not sure that matters.
Dan Luu wrote an article about input latency [1] in 2017 where he measured latency by running experiments pressing a key & measuring how long it takes to see a response on the screen. New computers from 2017 would have around 70ms-170ms latency, depending on the model.
I very much don't trust that article as a baseline. YMMV but I measured with a 240hz camera with a mid-high tier computer and a 144hz monitor in 2018 and a nice computer w/ 165hz in 2025 and I never got the huge latencies he experienced, I had click to photon of something like 10 frames max, so 42ms, with the average IIRC being closer to 5 frames.
input lag is a minor part of it. it depends on the game, but for example in CS2, refresh rate changes game mechanics like recoil, movement, even trajectories of thrown grenades.
i went from 60hz to 240hz, with <100fps average, and the difference was still immense. refresh rate is more important than fps, that's how big it is.
Game Porting Toolkit will be irrelevant unless it's as open and free to use as Proton is. Linux has far and away taken the lead here.
It also doesn't help that x86 compatibility is being ejected, so you can't even run basic Wine in the near future. Due to all this, there's no reason to be excited for this misguided endeavor of Apple's.
If Apple wants to really show they are serious about gaming, they’d have some in-house game studios release some AAA games as Mac exclusives, that people actually want to play. System sellers.
This is effectively how every other platform gets people in the door and builds the critical mass of gamers for 3rd parties to show up.
They claim enough of Rosetta will continue to exist for games and things like wine to work. I suspect the main thing they want to kill off are all the x86 slices in the mach-o fat binaries for all of the frameworks.
My source is I know how they handled Intel 32-bit support for Wine the last time they deprecated it. They went out of their way to keep codeweavers happy even though they let all the 32bit games on steam straight up die.
The original GPTK was mostly comprised of forked code. This bump likely includes a lot of the upstream optimizations that other ARM gamers have been using for a while now.
Rosetta will go away. Game support won't.
"Starting with computers using macOS 28, Rosetta functionality will be available only for certain older, unmaintained games that rely on Intel-based frameworks."https://support.apple.com/en-us/102527
You might want to not only re-evaluate what you consider a real GPU, but also take a look at what the latest Intel integrated graphics is capable of (Panther Lake laptop chips with 12-core GPU chiplet fabbed by TSMC). Intel is still way behind NVIDIA and AMD in the discrete graphics card market, and their drivers don't have the decades of accumulated hacks to work around badly-written games, but their good iGPUs aren't a nightmare of incompatibility and missing features like they were 15 years ago.
People say they think it's faster than top of the line RTX 3070[1] and hands down the fastest GPU ever for local LLM purposes, and OTOH they're like Intel integrated graphics with RAM shared VRAM for ultra thin laptops, so the truth is either of that, or somewhere between those two. Probably wherever its TDP suggests.
Yeah, but at 176 FPS, at first glance it seems competitive with the abilities of some fairly recent dGPUs from nvidia/AMD, though obviously we don't have benchmark-level details here.
I think this is an article allowing quiet optimism rather than all-out celebration.
The game porting toolkit allows windows DX shaders to get runtime translated to high performance metal shaders.
It provides a path for Rosetta and Wine to handle what they are good at while letting Apple handle the shader lowering in many cases better then dxvk -> moltenvk -> metal (or whatever the new state of the art thing is, I forget the name).
It’s not JUST for helping with manual porting of the cpu side code.
Apple could easily make gaming on Mac feasible by contributing to Proton, Wine, DXVK and officially supporting Vulkan at least through translation layer.
Or just partner with Valve to do exactly this for their platform.
Instead they choose to build another proprietary solution nobody gonna use and that will die as soon as they lose interest.
I agree with you on wine, and I wouldn’t be surprised if they are doing this quietly (landing patches to make Wine better on Mac), but for the purposes of making directx shaders perform better I fail to see why it matters if they support dx to metal conversion or if they support vulkan (for the goals of making games run better for their customers)?
Their strategy trying to push proprietary solutions simply doesnt work when their OS have 2% of PC gaming market share.
Apple announced game porting toolkit 3 years ago and no one uses it. Well, unless Apple fund ports as PR stunts.
At the same time Valve released Steam Deck 4 years ago and by now nearly all Windows games are playable on Linux.
> It matters because if Apple embraced Vulkan it would give more market share to one standard API for non-Windows platforms.
How does this actually help Apple customers have a better experience in some unique way that live translation to Metal does not? Runtime GPU compilers already do plenty of runtime translation; having worked on several I could be convinced having a simpler interop layer would make things smoother but your argument comes across as ideological more than about shipping product.
> Their strategy trying to push proprietary solutions simply doesnt work when their OS have 2% of PC gaming market share.
Hardly anyone one uses their proprietary solution (Metal) directly. But that doesn't mean Vulkan is going to be some panacea of gamer/game-dev adoption.
> Apple announced game porting toolkit 3 years ago and no one uses it. Well, unless Apple fund ports as PR stunts.
While I agree its not that widely used for porting actual games, I think a lot more people probably do use D3DMetal to run Windows games on mac.
> How does this actually help Apple customers have a better experience in some unique way that live translation to Metal does not?
By decoupling the support for Windows games from Apple's whimsical downstream release cycle, obviously. Proton would build perfectly fine on macOS with proper DXVK support, enabling the "same day" support patches that the Steam Deck and Steam Frame enjoy. There would be no need to wait to play games like Arc Raiders because all you'd need to do is update your Proton runtime. Users would get have more flexible options for playing new games that Apple doesn't support with GPTK point releases.
> But that doesn't mean Vulkan is going to be some panacea of gamer/game-dev adoption.
They can perfectly well support both APIs. If Apple wants to have a mobile-first rendering API on their desktop, fine, but it shouldn't hamstring the other features of a computer like eGPU support or basic third-party drivers like Mesa. There's no reason it would.
I’m not entirely sure what apple’s interest in any of this is. Would it get them any additional customers? What portion of their customers would be significantly more happy with games being somewhat more optimized a few months sooner? I just don’t see the value add here.
I’m not sure the community needs that much support from apple either. Lot of projects have figured out how to targete AIR directly by now.
I wish this were/is true, that Apple supports Wine development. But as far as we know, a year from now Apple will end Rosetta 2 support in macOS 28, and with it the ability to run Wine.
AFAIK Crossover is now able to run without Rosetta:
https://www.codeweavers.com/blog/mjohnson/2026/6/11/whats-in...
Most likely Wine will work soon too. Only some 32-bit apps will break.
My theory is that Apple chooses to make gaming a second class experience on Mac because they don't want the Mac brand to be associated with the main demographics that play AAA games.
A strange thing to comment on an article specifically about a toolkit produced by Apple to improve gaming on Macs.
Needlessly dismissive of a large swath of people too.
I’m not claiming to like the choice (I don’t) merely that it likely is the real motive for Apple.
The Mac brand is already associated with Apple zealots, and they don't seem to care about that, so that's obviously not it. It's more that Jobs personally didn't care for games. He put an end to Pippin and Game Sprockets as soon as he returned. Now there's still some inertia against gaming, but if they can figure out how to make money off gamers, they'll be more than happy to.
Granted this is just my personal spend, but Apple has lost out on something like $12k of hardware sales from me over the past six years because they don’t support gaming. I switched to Linux in 2020 because it meant I could have a proper development environment AND play games. Before I was split between Windows and Mac, having to buy two machines— one for gaming and one for development.
If Apple didn’t treat gaming like a red-headed step child I’d have never made the switch. Now, it’s an incredibly steep uphill battle to win me back to MacOS. Linux slaps and NVidia has way better performance (though I wish I could get more than 32GB of VRAM without forking over $10k).
So yeah, while they might not like stereotypical gamer[1] types, I’m sure they’d like their money. For me the only Apple device I buy is a new iPhone once every 4-5 years. My lifetime value (to Apple) is essentially roughly 25%-33% of what it would have been if they supported gaming.
[1] I think more people play games now than ever before. While 20 years ago gaming might have been niche, we have multiple generations at this point who have been playing video games their entire lives. Realistically, it’s only boomers who haven’t played video games (or had access to them) the majority of their lives.
This, once again, misses the elephant in the room.
The fact is simple, there isn't enough of a Mac gaming market for the game developers to go through the effort.
The hardware has been good enough for a while now.
I'm not saying this will never change but the developers that shipped games on PC and Mac report something along the lines of 6-11% of users use a Mac. That isn't worth the effort unless you have a very strong IP and you've already targeted the switch2, the PS5 and XBox.
I disagree. When OS X went to Intel, there was an explosion of Mac games on Steam. Valve went all in with big ports of TF2 (complete with exclusive era-appropriate in-game items like the earbuds), and all their other games soon followed.
Apple self-owned themselves by slowly killing off support for this, culminating with the transition to the M chips and the upcoming removal of Rosetta to put the final nail in the coffin. Their negligence to support a major market is their downfall here. The hardware is more than willing, the software and company are causing the fumbles.
It could be argued that was a "right place at the right time" situation. macOS supported OpenGL at the same time as Valve was pushing for the original Steam Machine and native Linux ports. Writing a macOS port was a much easier job back then.
Apple's pivot to Metal and mobile-first distribution was the beginning of the end. The iPhone's revenue potential eclipsed the value that Mac gaming could ever provide, and Apple made sure to capture it with the App Store. Once Tim Cook showed everyone how easy it was to make service revenue, the execs probably realized that they could make bank off of a captive, game-deprived customerbase.
Easy fix. Apple can just stop breaking compatibility and partner with Valve to port Proton support to Mac.
But they wont do it because they want to push their own walled garden. And obviously no one will support it because macOS market share is smaller than Linux market share.
>macOS market share is smaller than Linux market share
Not true? macOS has like 12-14% and Linux 3-4%
If you check Steam hardware survey you'll see Linux market sgare is 3% against macOS 2%. This is what matter for game studios.
That's because it makes no sense to use Steam on macOS because there are nearly no compatible games and Steam itself only has an ARM version on Beta and the Intel version is unusably slow. Overall a catch-22 situation though.
Its not like every single Linux PC have Steam installed either. And if you run Steam client under Wine / Crossover it able to properly detect real platform.
A very big portion of that is corporate.
I have a macbook home, the one issued by my employer. My personal laptop runs Linux.
That's not the elephant in the room. The elephant in the room for gaming on Mac is Apple's policy non-commitment to traditional gaming. Technical support for non-gambling gaming is just a checkbox item to them for mandatory 45-second segments in product launches. That transcends into their customers and develop into various gaming and Mac related chicken and egg problems.
Isn’t the point that significantly reducing the effort required changes the “is it worth it” equation?
Some engines nicely support Mac out of the box. I’m making a party fighter in LOVE2D and am having a good time developing and playing on Mac (cross platform online play is working well too, my friends are all Windows).
Maybe Unity or Godot also offer this benefit? If so then Mac gaming could become much better supported, at least from indies!
I don't get this attitude.
It'll never be enough until it is. Making porting lower-effort and higher performance can only help.
Apple is getting kind of a PR problem with developers. In theory they don't do all the same things on Mac as they do on iOS, but as long as they continue to do them on iOS and keep feature creeping the gatekeeper stuff, people are hesitant to end up stuck with Apple taking 30% of their revenue or denying their app for opaque reasons after they've spent big money to develop it.
At which point who is going to spend development resources helping the platform of the company they're most afraid of screwing them if it becomes more popular? Half the reason more game developers are targeting Linux is a hedge against Microsoft doing that sort of thing, and Apple is on the opposite side of where they want to move.
This idea that Apple has been plotting this whole time to turn the Mac into iOS, in terms of limiting the software you can run to their own App Store, is a tired meme that makes zero sense given what we've seen from Apple in the past...checks...19 years.
Like, seriously, do you think they need longer than that to do it if it's really what they plan?
If they were ever going to do it, it would've been when they switched to Apple Silicon chips, and...they didn't!
Perpetuating the idea does no one any favors. It's just pointless paranoia.
They've been gradually making it harder to install third party software without their approval.
The Mac App Store hasn't existed for 19 years. Then they started displaying scary warnings for apps downloaded from the internet. Now they require code signing for third party apps. Meanwhile they not only obviously do it on iOS but are adamant that no one even attempt to do otherwise, even in the face of law requiring them to.
It's not paranoia when they're really out to get you.
> If they were ever going to do it, it would've been when they switched to Apple Silicon chips, and...they didn't!
They did, though;
- macOS lost support for eGPU and dGPU drivers
- OpenGL support was frozen to focus on Apple's mobile GPU API
- Apple promoted Mac Catalyst apps instead of pushing Mac-native ones
- The iOS and iPadOS App Stores became available on macOS alongside the native store
- The macOS design language was reworked to take cues from overly padded touch-first design
- iBoot became the hardware entrypoint, which Apple has authority over with OTA updates in macOS
- UEFI and ACPI went away, forcing devicetree drivers to be reverse engineered with zero documentation
Old Macs are just computers. None of these limitations apply to them because you can pick one up and install a normal OS if these concessions concern you. Apple Silicon was shipped in a way that deliberately prevented reverse-engineering and gives Apple the ability to revoke boot-time features if alternative OSes ever threaten them. They depreciated vast swathes of functionality that professionals relied on, and eventually depreciated the Mac Pro altogether. Their tentpole desktop products are a Mac Mini, a bigger Mac Mini, and the iMac. There's not any hardware left for real pros.
But you're still unconvinced, right?
Well, look at Apple's revenue breakdown. The Mac is not carrying much water, and it's a huge sinkhole of resources to constantly maintain and update the OS on a yearly update cadence. Conversely, the iPad is doing great, making almost as much money as the Mac does with vastly cheaper hardware (and bigger profit margins, too). If Apple could have their druthers, they'd start polishing the iPad experience, ship "Pro" hardware to entice developers and boundary pushers, slowly roll out support for HID and external display support, and eventually provide a sort of cloud service for building applications within the Apple ecosystem. Oh wait, I've just described things they've already done! https://developer.apple.com/xcode-cloud/
Apple has no obligation to their niche pros, anymore. They already cut them out and depreciated their rackmount and short-lived wheeled PC. I have no doubt in my mind whatsoever that Apple is internally laser-focused on depreciating the Mac and macOS both, either with the Vision hardware or by promoting the iPad as a laptop replacement a-la Microsoft's Surface Pro.
That really doesn’t make any sense. Do you really think Apple will ban steam on macOS overnight?
Nah there will be a new model and a new OS version on it that will only lets you use the App Store (30% tax of course). People here will complain and a fuck ton of people will dick ride Apple with bullshit about how they shouldn't buy that new laptop and they should feel privileged for Apple allowing any money to go to the person actually providing you value.
That's not how you boil a frog.
If it gets popular enough then they start trying to get games to use their app store instead of Steam, gradually make it easier to use that and harder to use anything else, then the gate closes only after the herd is where they want it.
Better, then, if it never gets popular enough to begin with.
Personally I would gladly switch to mac as my actual personal PC if games ran well on it.
I think you are right. I suspect any mac gaming share that gets bootstrapped will have to come the crossover/proton way. Thats probably good enough for starters.
Gotta start somewhere
Oh, who gives a damn. Half the games in my Steam library don't work since Apple killed 32bit. When they fix it, I'll know they care about Mac gaming.
Most of those are gonna work using Rosetta, crossover, and the game porting toolkit.
You really don’t need Apple to support 32Bit x86 macOS games when it’s not much more overhead to run windows x86 games (which is easily the better library to spend time Optimizing for).
Kind reminder that Rosetta is being removed.
It isn't; they specifically have said it will be retained. They aren't too specific but I think what they mean is all the Framework and App support for it will be gone. But as far as keeping a lot of self contained games and wine running I think it'll likely continue to work fine.
It isn't being retained in the way it is now. You won't be able to open Intel apps, and won't be able to use x86 CLI items like wine.exe
Some dev support is being retained but you shouldn't consider that "will be retained". It is going away.
I’d really be surprised if they broke codeweavers’ stuff.
Also who cares if the wine exe itself can run as x86? Ideally you want something that resembles windows chpe where the loader is native but works with the translator to bridge translated game code to native sys/lib calls.
Why bother with macos version at all then? Soon current version becomes unusable as well, and needs windows fallback to run since macos version is useless
If there's a macos port, it'll of course be better optimized. I play CS2 on mac from time to time. It runs really smoothly on my Studio, but if it were a native port I could run it on a macbook air.
*for a brief moment it actually runs.
from the point of the dev - work done on the port will rot very soon, return of investment is really low. Also, the studio may not exist at all by time changes will be necessary - as fast as few days after public release nowadays :(
The high pixel response time on macbook displays means you'll want an external monitor for multiplayer shooters etc., which most gamers are already fine with, but annoying if you want to game while travelling.
I don’t think it matters. My Studio Display XDR has pretty bad motion performance (similar to Macbook, maybe a touch better) and you can still play first-person shooters perfectly fine. In the general case you don’t notice it much. It’s only a problem with fast planar movement, e.g. strafing along a wall and trying to read some text that’s written on it. (Spelunky 2 is much worse than CS in this regard, but still not a massive issue. Just a bit ugly.)
Not a “Gamer” so I’m always surprised small things like this make a difference.
As a rule of thumb, what is a minimum frame rate a game needs? From there how much does each extra fps make a difference, and at what point do you hit diminishing returns?
Pixel response time is a related concept to framerate but more about how long it takes a pixel to change from one color to the next. Usually measured in cycle time from grey to grey again, a low rate just means that images will be smooshy looking, have unclear boundaries, and end up with a 'motion blur' effect. So even if your mbp supports a reasonable sounding 120hz (8.33ms for a full frame sweep), some of those pixels will still be in transition when the next frame hits. At least, my take on it as a somewhat casual gamer.
It depends wildly on the type of game.
e.g. if you're playing a single player turn-based strategy game, you might be taking a few seconds between each decision & UI interaction. Some hard turns you might step away from the computer to think things through for minutes without touching the controls. 30fps for a game like that could be fine. 15-20fps might even be fine, especially if the game engine manages to avoid adding unnecessary input latency & is able to process input events at a faster rate even if the render runs at a low framerate.
If you're playing competitive FPS games, where reflexes matter, you'd want to get input, network & video latency as low as possible, within reason. Not high-frequency trading low. I have no idea at what point it stops making a competitive difference. If you have +100ms more latency than I do, I suspect that'd give me a noticeable advantage. If you have +10ms more latency than I do, I'm not sure that matters.
Dan Luu wrote an article about input latency [1] in 2017 where he measured latency by running experiments pressing a key & measuring how long it takes to see a response on the screen. New computers from 2017 would have around 70ms-170ms latency, depending on the model.
[1] https://danluu.com/input-lag/
I very much don't trust that article as a baseline. YMMV but I measured with a 240hz camera with a mid-high tier computer and a 144hz monitor in 2018 and a nice computer w/ 165hz in 2025 and I never got the huge latencies he experienced, I had click to photon of something like 10 frames max, so 42ms, with the average IIRC being closer to 5 frames.
input lag is a minor part of it. it depends on the game, but for example in CS2, refresh rate changes game mechanics like recoil, movement, even trajectories of thrown grenades.
i went from 60hz to 240hz, with <100fps average, and the difference was still immense. refresh rate is more important than fps, that's how big it is.
Frame rate has absolutely nothing to do with the screen you project the frames on. In competitive multiplayer shooters, frame rate matters a lot.
Game Porting Toolkit will be irrelevant unless it's as open and free to use as Proton is. Linux has far and away taken the lead here.
It also doesn't help that x86 compatibility is being ejected, so you can't even run basic Wine in the near future. Due to all this, there's no reason to be excited for this misguided endeavor of Apple's.
If Apple wants to really show they are serious about gaming, they’d have some in-house game studios release some AAA games as Mac exclusives, that people actually want to play. System sellers.
This is effectively how every other platform gets people in the door and builds the critical mass of gamers for 3rd parties to show up.
The last time they tried that (Halo CE), Microsoft bought the studio from under them, after they had already announced it at MacWorld
The corresponding WWDC video for toolkit v4 is at https://developer.apple.com/videos/play/wwdc2026/357
How it is getting priority if they deprecated Rosetta? Or am I understanding it wrongly?
They claim enough of Rosetta will continue to exist for games and things like wine to work. I suspect the main thing they want to kill off are all the x86 slices in the mach-o fat binaries for all of the frameworks.
Do you have a source on that, them claiming continued support for "things like wine"?
My source is I know how they handled Intel 32-bit support for Wine the last time they deprecated it. They went out of their way to keep codeweavers happy even though they let all the 32bit games on steam straight up die.
The original GPTK was mostly comprised of forked code. This bump likely includes a lot of the upstream optimizations that other ARM gamers have been using for a while now.
Isn't the translation layer going away soon though?
Rosetta will go away. Game support won't. "Starting with computers using macOS 28, Rosetta functionality will be available only for certain older, unmaintained games that rely on Intel-based frameworks." https://support.apple.com/en-us/102527
Do they plan to have a whitelist of games? I guess they could remove rosetta support for most Cocoa frameworks while keeping OpenGL translation layer.
I would assume people would switch to using FEX which is tuned for game performance for the x86 emulation bit.
Do macs really have GPUs though? Or are they like intel integrated graphics?
You might want to not only re-evaluate what you consider a real GPU, but also take a look at what the latest Intel integrated graphics is capable of (Panther Lake laptop chips with 12-core GPU chiplet fabbed by TSMC). Intel is still way behind NVIDIA and AMD in the discrete graphics card market, and their drivers don't have the decades of accumulated hacks to work around badly-written games, but their good iGPUs aren't a nightmare of incompatibility and missing features like they were 15 years ago.
This is not the greatest question because it makes it seem that you think unified gpu+cpu socs are all like intel graphics.
People say they think it's faster than top of the line RTX 3070[1] and hands down the fastest GPU ever for local LLM purposes, and OTOH they're like Intel integrated graphics with RAM shared VRAM for ultra thin laptops, so the truth is either of that, or somewhere between those two. Probably wherever its TDP suggests.
1: (Laptop)
> hands down the fastest GPU ever for local LLM purposes
Not really. On pure speed a 5090 will still comfortably beat a top end Mac configuration. Just constrained to 32gb mem ofc
Top Mac has mem throughput around the 900 mark while a 5090 is at 1800
Apple integrated graphics is quite good. Software is the problem.
Yes they have GPUs.
An on-board GPU is not a GPU?
It’s only a GPU if it’s made in the RTX region of Silicon Valley, otherwise it’s just sparkling floating point calculations.
What's all the fuss about? I've been gaming on my Mac just fine. https://files.catbox.moe/dfcfha.png
The example they give is a frame rate boost on GTA V - a game released 16 years ago.
Yeah, but at 176 FPS, at first glance it seems competitive with the abilities of some fairly recent dGPUs from nvidia/AMD, though obviously we don't have benchmark-level details here.
I think this is an article allowing quiet optimism rather than all-out celebration.
The boosted framerate picture seems to show noticeably less of the rain effect.
It's not the author's fault that GTA VI hasn't come out yet.
It is, and has been for a long time, a concious choice for apple to avoid gaming.
Geforce Now is my platform of choice for gaming on the Mac. It works pretty well, as long as you don't want to install mods for your games.
I don't think the Game Porting Toolkit is useful these days: LLMs one-shot ports from one graphics API to another.
Just like programming languages, graphical API choice is irrelevant now.
You're going to need a source for an LLM one-shotting a port of a AAA title from one graphics API to another...
I one-shotted non trivial software from OpenGL to Metal with a cheap (=non state of the art) LLM. That was 6 months ago.
Anything in Unreal Engine that you think Fable wouldn't be able to adapt on its own to a different graphics API?
The binary is the source.
The game porting toolkit allows windows DX shaders to get runtime translated to high performance metal shaders.
It provides a path for Rosetta and Wine to handle what they are good at while letting Apple handle the shader lowering in many cases better then dxvk -> moltenvk -> metal (or whatever the new state of the art thing is, I forget the name).
It’s not JUST for helping with manual porting of the cpu side code.