Mac gaming is finally getting the overpowered upgrade it deserves
macworld.com
macworld.com
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.
> landing patches to make Wine better on Mac
AFAIK they dont contribute back to Wine. There some chance they quietly pay to CodeWeavers, but likely this wouldnt be kept secret. > I fail to see why it matters if they support dx to metal conversion or if they support vulkan
It matters because if Apple embraced Vulkan it would give more market share to one standard API for non-Windows platforms.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.
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.
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 sure the community needs that much support from apple either. Lot of projects have figured out how to targete AIR directly by now.
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.
Needlessly dismissive of a large swath of people too.
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.
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.
It'll never be enough until it is. Making porting lower-effort and higher performance can only help.
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.
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.
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.
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.
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.
You cite a bunch of changes, but none of them are what people have actually been claiming for the past 19 that Apple will do: preventing us from installing arbitrary software on our Macs.
I still have my MacPorts installation, which works fine, and installs all kinds of command-line tools.
I can still write anything I want on my Mac, compile or interpret it, and run it.
I can still install whatever I want from outside the Mac App Store.
This is a classic example of goalpost-moving.
That isn't worth the effort
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.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.
Not true? macOS has like 12-14% and Linux 3-4%
I have a macbook home, the one issued by my employer. My personal laptop runs Linux.
Maybe Unity or Godot also offer this benefit? If so then Mac gaming could become much better supported, at least from indies!
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.
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.
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).
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 :(
Some dev support is being retained but you shouldn't consider that "will be retained". It is going away.
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.
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?
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 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.
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.
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.
1: (Laptop)
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
I think this is an article allowing quiet optimism rather than all-out celebration.
Just like programming languages, graphical API choice is irrelevant now.
Anything in Unreal Engine that you think Fable wouldn't be able to adapt on its own to a different graphics API?
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.