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.
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).
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.
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 isn't worth the effort
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.
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.
1: (Laptop)
I think this is an article allowing quiet optimism rather than all-out celebration.
Just like programming languages, graphical API choice is irrelevant now.
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.