To the surprise of absolutely nobody, Apple’s macOS gaming policy of only offering a proprietary, Apple-only API isn’t exactly paying off. One of the most popular online games in history, CS:GO, is removing support for macOS, and it won’t be coming back. From here on out, the game will only be available on 64-bit Windows and Linux.
That cycle played out again in Valve’s recent Counter-Strike 2 update, which removed the Mac support already present in the outgoing Counter-Strike: Global Offensive. Today, a Valve support document for CS2 confirmed that Mac support had been removed and wasn’t likely to be re-added, along with support for ancient DirectX 9-class GPU hardware and legacy 32-bit operating systems.
Fret not, though, Mac gamers – there’s always Super Tux Kart.
Ever since Tim Cook took over Apple has Changed as a Company. Being less open and more Catered to being a Luxury Brand, Treating the long supporting customers like trash. Apple is trying to squeeze as much money from the user as possible. You’d used to see Large crowds supporting Apple, now they re disappointed with what apple is doing. Less User centric and more Boring. You can’t customize the OS, nor the UI, No Games, no open source. no Developer programs that used to Get a load of people piling in.
iluvcrap2000,
I don’t remember apple being more “open” under Jobs. He didn’t care what users wanted, if anything he was rather notorious for saying customers don’t know what they want and suggesting they shouldn’t be listened to.
https://www.linkedin.com/pulse/steve-jobs-product-fallacy-customers-dont-know-what-want-sarah-kling/
To me it’s perplexing that people miss the days when apple was even more cult-like. Many of us found that stuff extremely off-putting. yet it’s undeniable that some people gravitate to authoritarian cults. Steve Jobs was well known for his reality distortion field, but I’ve been noticing similar patterns elsewhere, there are especially strong parallels in religion and extremist MAGA circles where rational thinking gives way to pure dogma that cannot be reasoned with.
There was a neurological study that investigated this behavior with MRI scans, which I found intriguing though I’d really like to see more followup studies.
https://www.cnet.com/tech/computing/apple-stimulates-brains-religious-responses-claims-bbc/
Apple does sabotage gaming on mac, constantly, and it’s a multi-part problem. They are untrustworthy on a number of fronts – backwards compat especially, but they are also hostile to third party store fronts. Both of these are a total killer, but that’s just the tip of the iceberg.
Valve has shown the way forward to multi-platform games. You have to support Windows x86 binaries, period. macOS is actually (and finally) capable of doing that at a technical level, even on MX CPUs, but it’s worth nothing, until Metal API 3 (which shipped only around a year ago), they weren’t really. But now they can support the various API wrappers we need, since Metal 3 finally supports enough low level hardware features, at least on Apple GPUs. So GPU support is potentially there, finally. But while macOS can technically run x86 code through Rosetta 2 (with actual CPU hardware support), Apple has not promised to keep that around for even the next 2 years. I suspect they are going to remove it, probably years before they remove the x86 memory modes from their CPUs, because they are Apple. I bet Valve suspects the same, which might explain why we haven’t seen much movement on Proton for mac, even though it’s technically possible right now.
So aside from technical support (likely temporary) for realistic path forward for gaming, and aside from Apple policies, which constantly undercuts every effort to entice game developers and gamers to their platform, there is also the issue of basic costs. Apple hardware that is reasonably capable of playing games is EXPENSIVE. Gamers might be used to expensive GPUs, but even by those standards, macs that can game are expensive. (Apple could address this hole in their line-up with some unit that has a lopsided CPU/GPU MX chip, like the AMD units we see in Steam Deck, PS5, etc., but they likely won’t ever do that.)
Gamers aren’t going to jump to an expensive platform that can’t play their back library of games, built by a company that won’t promise future support for basically anything. You can’t even run 32-bit macOS games. It’s literally easier to run 32-bit Windows games… That’s unacceptable. If that’s how they play, then Apple simply isn’t serious about gaming on mac.
CaptainN–,
I agree, Can’t really blame steam and others for not taking advantage of rosetta’s capabilities given that apple won’t commit to supporting it. Also, it’s a shame for users and devs that apple refuses to support vulkan. It would go a very long way towards providing a unified target, however I think apple are generally against interoperable technology since it would detract from their own proprietary tech.
Honestly, I don’t even need Apple to support Vulkan directly. They have Metal 3, and a project like MoltenVK can be good enough, if the underlying tech is good enough – which is seems to be (I’m not an expert though, so defer to someone who is). I’m fine with relying on community projects to fill those kinds of gaps. It’s exactly the same thing Valve does to make D3D work on Linux with DXVK and vkd3d-proton. It’s workable.
The problem is, Apple won’t promise not to mess it up in a months time, let alone 2 or 3 years. Apple could literally solve this problem tomorrow with a letter containing a promise. But they won’t, because they are Apple.
CaptainN-,
I have no hands on experience with these. Do you know if something like MoltenVK requires source code and/or changes to software in order to use vulkan on metal or does it really let you run vulkan software on m1/m2 as is?
Yeah, I know.
Apple are now developing the Game Porting Toolkit
https://arstechnica.com/gadgets/2023/09/macos-14-sonoma-the-ars-technica-review/16/#game-porting-toolkit
so at least at some point in the future it should be easier to develop cross-platform for the Mac. But yeah, around the time they dropped support for 32-bit games I think a lot of gamers (myself included) got fed up with Macs for gaming and started looking for alternatives.
Moochman,
The thing is, even the article you linked to claims that apple doesn’t intend for game porting toolkit to provide cross platform support. They still expect developers to rewrite code for mac…
There’s nothing technically stopping apple from offering great binary portability ala wine/proton for macs. They could even partner up with steam, but it doesn’t fit into apple’s business plans. Apple considers binary interoperability bad, instead they really want developers to sell native mac games through their app store so apple can collect fees. I really think this is the reason apple have discouraged easy portability with macos – it’s to protect their ecosystem.
Alfman,
Crossover (from Wine fame) + GPTK seems to finally bridge the gap:
https://eightify.app/summary/mac-tips-and-apps/crossover-23-5-a-revolutionary-mac-game-changer-gptk-tutorial
Apple has made some mistakes with the APIs and such. But this combination brings Vulkan, Direct3D support, which seems to work okay. (Probably thanks to Proton and other open source work as well).
I might not vouch for all games working well, but the situation is significantly better even compared to early 2023.
sukru,
Thanks for that info. The response linked here gives me the impression that crossover handles the API translation on the x86 side and then uses rosetta for translation into ARM.
https://www.codeweavers.com/support/forums/general/?t=27;msg=234547
This makes me curious whether crossover does anything with ARM at all or if it’s all going through rosetta? I guess maybe crossover were willing to depend on rosetta despite apple’s lack of long term commitment. This could prove painful for some if/when apple deprecates x86 & rosetta.
Alfman,
Even though I cannot speculate about Apple’s long term plans, having released Game Porting Toolkit, which essentially does a similar thing (but at lower level, and only for developers), I would assume some x86 compatibility will be there as long as this exists: https://www.applegamingwiki.com/wiki/Game_Porting_Toolkit
This is also now integrated into Crossover (which has a higher level and user friendly interface, and supports non-gaming software), without making any promises, that seems to make that software too a bit less fragile. At least for now.
(And we always have Wine-on Qemu-on Arm): https://github.com/AndreRH/hangover, and a more native one: https://wiki.winehq.org/ARM64)
sukru,
Yea, as a developer though you’d want to know how committed they are to supporting it in the future.
I’ve done this myself and I’ve found it works well with linux applications. I’ve never tried using qemu and wine together, but quoting Jeremy Newman of codeweavers: “it was painfully slow”. To be fair I haven’t benchmarked it in a long time, but IIRC cross architecture qemu incurred something like a 40% performance loss, whereas rosetta is maybe half that. Of all the types of x86 applications average users might want to run on an arm mac, games are probably the most demanding, I guess x86 games might run ok if they are older or have high FPS to start with and/or are GPU limited rather than CPU limited.
Alfman,
According to: https://news.ycombinator.com/item?id=28731534
Apple M1/M2 chips has a special memory mode for x86 emulation. Meaning, unless Qemu has somehow made use of that, it would be slower, unfortunately.
(This is similar to Xbox having additional GPU hardware for their older games, etc).
Don’t know how it works, but there is also Rosetta support for Linux virtual machines using the virtualization API:
https://www.infoq.com/news/2022/06/apple-virtualization-framework/
Though no 3d-acceleration as far as I know.
And coming back to how long this is going to be supported? Your guess would be as good as mine.
sukru,
From what I recall, those chips support the x86’s stricter memory barriers. This allows software to assume concurrent memory consistency without having to use explicit synchronization. It would be extremely costly to implement this hardware behavior through software emulation. I’m not sure if it requires a separate mode, or if those barriers are simply always enforced on the m1/m2 (even for native ARM software)? After all, there’s no harm in specifying ARM behavior more strongly than required.
https://www.cs.utexas.edu/~bornholt/post/memory-models.html
I’m not even sure if QEMU handles this or it naively exposes host memory as is?
In any case, I agree with what zamadatix said from your link: