If you want to know how neglected Steam on macOS is... it's an Intel binary (now using 100% CEF for its UI) and about 2/3 of the catalog doesn't work because they targeted x86 (not-_64). If you're looking for native Apple Silicon games it gets even more grim.
I was hoping for that trend to reverse with game porting toolkit, but it doesn't seem like that's happening. Whoever pushes for Gaming at Apple doesn't seem to have massive internal support. Metal VR died almost as soon as it released and somehow they thought making Game Porting Toolkit license incompatible with Wine/Proton/CrossOver was a great move, because all you need to convince a game developer to invest in a dead (to your audience) platform that will likely deprecate your API in a year or two is a proof of concept of how well it can run.
I don't really ever see Mac gaming growing unless a radical shift in philosophy happens at Apple. Similar things have been said about Linux but the reason gaming has been growing on Linux is because no one body lords over it and Valve and others have made a concerted effort to help Linux gaming. Apple LOVES to have control and unless they can create a controlled environment that can make them money off gaming (i.e. selling games off the app store and taking a % of the sale) we won't see them make a serious effort. There might be a few within who are passionate and make things like GPT that give people hope but higher ups will inevitably ask WHY?
I agree that gaming on mac is fairly grim, but I've been quite happy playing games on my 13" M1 macbook (air i think?). This excludes most AAA games, but I've certainly enjoyed Victoria 3 (and other paradox games). They don't seem to run much slower than on intel (which, granted, is typically worse than through wine or windows). Baldurs Gate 3 should be on it soon, I think. The mac market itself should shift pretty rapidly.
Edit: factorio and oxygen not included have both been pretty solid, too. I think factorio is even native.
Well, yes, at the end of the day Macs are still general purpose computers and despite all the hoops Apple puts in place that developers have to jump through, you can still release programs - including games - for them. So they do have and - unless Apple really screws up things somewhere - will always have games.
But what you're writing is basically what Linux gamers were writing for many years - even before Valve started focusing on it too.
That's the one bad experience I had with the game - in Steam it is already marked as available on Mac OS but after downloading the 100GB it tells you that it's actually still the Early Access version (with incompatible save files!) and you have to wait till September for the actual game. Which meant another 110GB download on my fallback device.
Whatever Steam is using to render that CEF to the screen in MacOS, it's not presenting it to the OS as a window, and as such, blithely ignores things like Stage Manager, responding only to things they manually reimplemented, like resizing.
For me Steam on the Mac has an important purpose, which is Remote Play - have an ITX box running Windows somewhere, and connect to it using Steam on a MBP. Now you can play everything from the comfort of your couch. Works pretty well if the wifi is good.
That's not the point. GPT will never be easily accessible to consumers. As stated in this thread, Linux thrives as a platform for games by running Windows binaries very well, and macOS would do well to do the same.
That Apple made GPT but then ignores this obvious route, instead thinking it will somehow mobilize game developers to port their games natively to their bespoke low-level graphics API is ridiculous - "you see, they just didn't know about the graphics capabilities of Apple Silicon before!". Yeah, right.
Lots of game developers can barely be convinced to release usable Windows binaries, see also the mess of badly performing DX12 games (which is more like a low-level console API that needs optimization to perform) vs yeet the pixels out DX11.
> Linux thrives as a platform for games by running Windows binaries very well, and macOS would do well to do the same.
No. Linux gaming thrives because Valve embedded Wine directly, branded as Proton, into the Steam launcher. GPT is the same, only for the Mac target of wine rather than Linux, and obviously Apple can't integrate it into Steam.
In terms of compatibility I've been using Whisky (a wine UI wrapper) + GPT for a few weeks now and window steam loads fine (albeit slowly), and all the windows games I play work fine (certainly far better than wine - GPT).
Of course the problem here is that it's not cleanly integrated into native Steam, so it's (1) requires a separate launcher installed, (2) requires a separate steam install, and (3) if the game ever does get ported you'd need to migrate your saves from the windows container wine uses.
This ignores all the attendant performance thrown away by shader translation (that linux also suffers) and cpu translation (that any non-intel code suffers, but in practice that's just Mac)
Let me restate: Apple does not consider GPT a consumer-facing product. It's meant to entice game developers do "see the power of metal". Proton being well embedded and all sure helps, but it's not the basic prerequisite, which Apple is withholding from being integrated by anyone but themselves, and it doesn't look like they have much interest in it beyond being a cool demo.
The point of GPT is that game developers don't have to target Metal, they can stick with DirectX or Vulkan and let Apple's translation layer do the rest.
Apple has been pretty clear that GPT is there so you can get an idea of how well your game would run on macOS, not to actually ship games with it. The license doesn't allow for that.
I got the 6 months deal and I regret it. GeForce Now has now several times simply not synced back my savegames (Steam claims "upload not started"), including several hours of Baldurs Gate 3.
This has happened only in BG3 with GFN for me. All other titles run perfectly or OK-ish.
It appears that there is some problem with BG3 on GFN. The game’s launcher constantly complains about “corrupt data files” and cloud saves take some time to sync from and to Steam.
Yes. Steam is more or less a good Mac citizen aside from not being fully Apple Silicon native. But, as previously stated, the entire catalog was 32-bit and it evaporated overnight when Catalina ended support for 32-bit executables.
I think the reason is that the 32bit games were first developed as 32bit for Windows. When porting it over to Mac, switching to 64bit would be a big amount of work that wasn’t needed.
I use Proton and will remain a huge fan of Valve as long as they are funding most of the work that makes it feasible for me to run Linux on all my machines.
However, I think that this speaks more to the degree to which Apple have put the torch to Mac gaming than it does to the size of Linux gaming.
If Apple could someone make Macs relevant for gaming again it'd be interesting, but I'm not sure what the roadmap to that result looks like. Implementing Vulkan support would likely help, but PC games are still chiefly written with DirectX, which is a big part of why Proton is necessary.
Perhaps the key is for them to work closely with Valve to make Proton work well on macOS, which would also neatly deal with the 32-bit issue because WINE/CrossOver on macOS handles 32-bit Windows binaries just fine despite macOS having dropped support for 32-bit Mac binaries ages ago.
This however seems unlikely because even setting aside the issue of how Apple might see doing this as pushing users to a competing marketplace, it also cedes some amount of the Mac's functionality and thus marketability to a third party which Apple has never been keen on.
> but I'm not sure what the roadmap to that result looks like.
The only real impediment is that they need to care. The one thing in common across all successful gaming platforms is that the platform owner cares a lot and works closely with game devs to make things work:
- Microsoft/Nvidia/AMD ship game-specific patches and optimizations for Windows games
- console makers work closely with third-party devs and give advice, feedback, certification, etc.
- Valve specifically has put tons of effort into SteamOS and certifies individual games as ready/not ready for the Steam Deck
All it takes is a platform owner who cares, and cares on the level of interventions for particular games, but this is totally foreign to Apple's DNA (both in general, and for games in particular). They'd need a huge culture shift.
> Perhaps the key is for them to work closely with Valve to make Proton work well on macOS
Apple are doing something very similar already with their Game Porting Kit framework. It supports DX12 games translated to Metal and runs very well. This effort only become public this year, though, so the fruits of that labour are yet to be borne.
You are not allowed to release and sell a game using the Game Porting Kit. Apple will strike you down for that. It's only here to help developers port their games to use Metal, which is peak Apple: force everyone to use your unused, non standard API to support a few thousand customers.
But then again, let's face the truth: Apple doesn't care about having Counter Strike on your Macbook. They make billions doing absolutely fuck all and taking 30% of all microtransactions on all App Store games.
We did a lot of online lan during the pandemic. One guy in our party was a staunch Apple enthusiast/fanboy and insisted on his mac for lan. So most of our time was spent on finding Mac compatible games on steam, trying them out (and basically see what breaks), and piling insult on him.
Truth be told we got more pleasure from cussing at the Apple guy than actually playing any game.
My fiancee and I play a few games together with me on my Silicon mac, and her on my Windows gaming machine. Some games that have worked well: Divinity 2, Civ 6, Stellaris, Factorio.
Divinity 2 seems to need Proton, probably would help to use the not-supported community build that includes the kitchen sink video codecs... https://www.protondb.com/app/219780
Civ 6, Stellaris, and Factorio I own copies / licenses of and all three have native builds for Linux so I'd be _amazed_ if they did not also have native builds for OSX too (or failing that, at least the Linux builds should be usable).
Biggest issue with targeting "Linux" is revealed in the Linux OS breakdown. If you throw out the SteamOS, you are left with about 45% of the Linux users in the "Other" category (i.e. not in the 6 most popular linux distributions), compared to about 14% for Arch and Ubuntu.
There's plenty to disagree with RMS on, but he's absolutely right that Linux is not an OS; it's a kernel.
The issue of targeting many distros with different package versions is already solved by Valve's Steam Linux Runtime. They use namespaces/container to provide the same environment on any distro.
Linux Distros, these days especially, are a paint of coat and tire size difference between each other. You make it sound like someone running Fedora (a significant slice of those in the "Other" category) is having a drastically different experience to those using Manjaro, Ubuntu and Pop_OS!.
Given the popularity of Steam, it's a high-visibility, high-priority application, which means your distro may be running it in one of three ways:
1) A snap
2) A flatpak
3) Your distro's native packaging format (deb/rpm, etc.)
So yeah, there might be a bit of variation there. I've already had a handful of problems on the Steam Flatpak on Fedora in which it's been suggested that I should switch to the RPMFusion Steam rpm instead, but so far I have resisted.
The fact that Steam is a program that installs other programs means that it will frequently test the boundaries of the OS and package format's security models.
Snap and Flatpak are both (theoretically) distro agnostic. That's their entire point of existence, to solve scenario three of your list.
Yes, Fedora defaults to and prefers Flatpak and Ubuntu defaults to and prefers Snap, but you can install either on either distro and it should Just Work. In which case, distro-specific differences are an even further moot point.
No, the differences are purely superficial. Which is why they don't pool together.
Your argument is like saying Lutherans and Episcopalians aren't both Protestants because they disagree on the meaning of the trinity, despite agreeing on 99% else.
Most Linux guides do work on all distros, as long as you're willing to adapt for package management solutions and Desktop Environments (when applicable).
Right, but most users don't care about that at all. Particularly for non-technical users who are only ever going to use the GUI frontend to the package manager, almost none of the underlying system matters at all.
In a world that has almost completely standardized on grub, systemd, fhs, etc with major applications being shipped in container-like blobs (snap, flatpak, appimage) that mirror a Windows-style setup.exe workflow and then bypass the filesystem and package manager and talk right to the kernel anyway... yeah, if you're an end user, your distro choice doesn't much matter. Pick whatever has out of the box drivers for your laptop's trackpad.
You're just reinforcing my point, not countering it. There's very little experiential difference, being superficial at best. But governing body and community differences are chasmic, meaning the Debian, Ubuntu and Fedora communities have little reason to add information for other distros to their guides; despite the instructions being 99% compatible.
Also visible in the popularity of the Arch Linux wiki as being reliable, up-to-date "how to fix it" instructions for common problems, regardless of whether you're actually running Arch.
It's not that far off. Whenever I'm looking for distro-level documentation, I end up either on manpages (which are shared), or the Arch Wiki.
And as a Debian user for many years, the differences are surface-level enough that the Arch Wiki is still one of the best resources with completely applicable answers.
I regularly use other distros' docs and guides for getting things done on Debian. I probably spend more time on the Arch wiki than any Debian-specific sites.
As you said, easier/better to target Win32 and just use Proton.
It's also funny because it kinda became true on another level as "Win32 Is Only Stable on Linux". It's easier to run old games and softwares (XP era and earlier) with Proton under Linux than on current Windows 10/11
> It's also funny because it kinda became true on another level as "Win32 Is Only Stable on Linux". It's easier to run old games and softwares (XP era and earlier) with Proton under Linux than on current Windows 10/11
Yeah, I'm gonna call that out as suspicious. Maybe on a few select titles, but the Wine database shows tons of titles that still won't run above "Silver"; all of which run just fine on newer versions of Windows. The older games that Windows can't run are usually due to some insanely intrusive DRM solution which also wouldn't run on Wine.
And this isn't me as some Windows fanboy, my comment history clearly shows I'm a Linux user; but that statement is just ridiculous on its face.
The Wine database is mostly dead for anything gaming related and it only cares about whatever DLLs are bundled with Wine. Nowadays people use at least DXVK and VKD3D-Proton (and most likely also some Microsoft media codecs) which improve compatibility considerably but are not part of Wine itself.
All gaming related checking is now on ProtonDB (pretty much everything that works on ProtonDB also works on Wine/Wine-staging with DXVK and VKD3D-Proton, this is how i play all of my GOG games - of which i have hundreds - for example).
In fact DXVK is so good that people use it to play Windows games... on Windows[0] and AFAIK it was how Intel Arc users played pretty much anything pre-DX12 for a while because Intel's own implementation was too slow/buggy.
[0] Actually this is how i decided it is time to ditch Windows a few years ago: i tried to play a D3D9 game on my Windows 10 PC and had various visual glitches - then threw the DXVK DLLs in the game's directory and everything worked fine. After a couple more occasions of this i decided that if i'm using DXVK for games on Windows might as well use it under the proper environment.
Ok, fine. List ten games that work better (not equal, or equivalently; better) with your aforementioned configuration on Linux than on Windows 10/11 and I'll actively go test each one of them and post the results on YouTube.
I can just about guarantee they will all run fine.
That is pointless, even if the games run fine on your computer it doesn't mean anything, you'd just be lucky enough. It'd be the same as responding with "it works on my PC" whenever someone says they have a problem with a game or other software on their PC - sure, nice for you but that doesn't mean anything aside from being possible to not have issues with some hardware and software configuations.
Also it'd be worthless to even try that, i made the switch almost three years ago and not only the software stack has changed a lot since then (IIRC Windows 11 didn't even exist), there is even a new discrete GPU vendor out. Today's comparison would not be representative at all.
And finally i never commented on how things performed[0] (i am assuming it is performance you have in mind with the "work better" as you mention that this "work" has to be "not equal but better" - anything else would be too vague to matter) - especially since the situation that made me decide DXVK was good was actually making the games i tried to play actually work regardless of performance (i happened to have some screenshots from a game i had issues with since i tried to report the bug in hopes the developer fixes it - they didn't - and this is the result i was getting [0][1][2]. Dropping DXVK in - under Windows - fixed all of those). FWIW in my experience performance was more or less the same (i did some testing with various games on Steam between Linux and Windows 10 after i installed Linux, some games performed better, others worse but the difference was miniscule that i only noticed with tools like mangohud on Linux and RTSS on Windows), which was great as i'd switch even if it was always slightly slower because i dislike Windows' UX, so that was a nice "bonus". But that isn't relevant to the experience i had anyway.
[0] Except that part about Intel Arc, but that was widespread knowledge when these GPUs came out, you can find several YouTube videos about the issues they had and some used DXVK to avoid them - BTW Intel kept improving their drivers, so even if you tried to replicate the results nowadays you wouldn't get the same results.
> pretty much everything that works on ProtonDB also works on Wine/Wine-staging with DXVK and VKD3D-Proton, this is how i play all of my GOG games - of which i have hundreds - for example
I found this usually to be true, but there are exception. For example I can't get Disco Elysium to work with Wine no matter what I try, but it's reported as working on ProtonDB. I've encountered some other exceptions too.
> There was the famous "Win32 Is The Only Stable ABI on Linux"
This has been a common saying for a long time. IIRC even before Valve made Steam available for Linux, the main Overgrowth developer who had Linux versions of some of their games break over time eventually mentioned (in a blog post) that you should just use Wine with their games as it is more likely to be stable.
(this may or may not have to do with the Linux version of their older game, Lugaru, using OSS - though at least the demo did run a few years ago when i tried it with a wrapper... and after removing/messing around with a bunch of .so files)
The current main hurdle keeping people off Linux Gaming is Anti-Cheat rootkit/kernel-module software such as Valorant's Vanguard or Call of Duty's Richochet.
If you need Windows to play Call of Duty, you're probably going to stick with Windows for everything because of the hassle.
My understanding is there is no technical reason these anti-cheats cannot work via Proton, but the anti-cheat makers will ban if they figure out you're not on Windows out of some weird fear of people having root access to the system. I could be wrong, however.
> My understanding is there is no technical reason these anti-cheats cannot work via Proton, but the anti-cheat makers will ban if they figure out you're not on Windows out of some weird fear of people having root access to the system. I could be wrong, however.
So the big anti-cheat platforms VAC, EAC, BattleEye, etc. all support linux, however the developer has to enable it - last I checked Battlefield2042 could run on linux just fine (as BF1 and BF5 did) but they didn't enable the anticheat on linux.
I'm not sure how possible kernel level anti-cheat is via wine, the entire point of that is to be on the ring 0 layer where the best cheat software lives. Drivers generally get permissions to read/modify any memory anywhere using hooks that are difficult/impossible to detect from userland.
The reason you'll get banned on linux if they don't instantly nope-out on launch and don't want to support linux is because what anti-cheat software does is primarily two things: See what is hooked into the game, and see if all the memory is in an expected state. Obviously the compatibility tools don't match windows 1:1 and will look _bizzare_ to software comparing it to what you'd expect on windows. So the state doesn't match which it assumes means something is modifying it = cheat software.
tl;dr - idk if ring0 anticheat could ever work via wine, a lot of games use anti-cheat software compatible with linux but just don't enable it, if anti-cheat was somehow didn't instantly freak out on launch then it'll see a bizarre and heavily modified system compare to a real windows install, with unexpected behaviour.
EDIT: From my understanding DKVX for example presents as the direct3d/directx library which of course has very different behaviour and is very clearly modified/not actual direct3d/directx
This all makes sense. I just don't see someone like Activision caring enough to make their kernel level anti-cheat work cross platforms... which has the effect of keeping people on Windows for no other reason but to play one or a couple games.
To make this work, there has to be some compatibility layer good enough to fool kernel level anti-cheat into allowing the game to run.
I don't know how that would be possible... but that would be the silver bullet, so to speak.
That's the problem though - if the compatibility layer can fool the anti-cheat then so can actual cheats.
Both cheats and compatibility layers do the same thing - modify behaviour.
Generally anticheat will take a "blanket" approach and ban or crash by default and whitelist specific types of behaviour.
What we ultimately would need would be a kernel level interface/process that the game talks to if it identifies it's running under linux. Which is totally possible to do, linux users specifically would hate it, and it would be a lot of work. Without this you're stuck in userland.
Honestly the only realistic hope is the steamdeck becomes a lucrative enough platform for developers to target. Valve has already made sure the popular anti-cheat software supports linux. Valve's stance has been to provide cheat mitigation through other things such as overwatch/trust factor in CSGO (which works well from my experience). VAC itself is actually very primative.
Even with these two, there are no common ground and no stable api. App released today is likely to break in the next distro release, or next after that. There is some hope in flatpak (not shipped with Ubuntu) and snap (ubuntu-exclusive), but these are not stable enough yet. The most stable api for linux is still win32
Meh. That's mostly semantics. Debian and Fedora and Mint and all the others are all still complatible distros. The days of wild changes in library standards or C++ ABIs or whatnot are decades behind us now. Are there still compatibility burps for people wanting to ship cross-distro binaries? Sure. But the overwhelming majority of binary distributors do fine with "build it on whatever the second most recent Ubuntu LTS is". And that includes games (though increasingly "make it work on SteamOS" is supplanting Ubuntu there).
tbf the biggest factor is not steamos, it‘s dxvk, wine and proton , which basically is in itself „an os“ on top of the kernel. It basically brings „windows wrappers“ for Linux with „minimal dependencies“.*
In my experience, if I quote him without citation, then it causes more of a kerfuffle; some people either assume I completely agree with him on everything and go on an anti-RMS rant, or assume that I don't know he said this and go on a pr-RMS rant.
I've been using Void Linux for many years, which is hardly mainstream, and pretty much all Linux games from gog.com "Just Work™" with a minimum of effort (I need to install some 32bit libraries for some, but that's about it).
I believe on Steam it's even better/easier, as it just ships with an Ubuntu base and uses that (but I don't really use Steam).
Point being: I think the differences between distros for this kind of stuff has been rather overstated. For most things, it doesn't actually matter all that much.
Yep, It's really not too hard. While I would very much prefer to get .rpm files for the games, in practice the installer approach (such as what GOG takes) is great.
One minor correction, Modern Steam OS is Arch-based, not Ubuntu-based, but your point still stands.
They probably talk about the Steam Linux Runtime (or it's predecessor), which is called scout and is based on Debian 10. They also have a more recent one called soldier used for proton and are working on a successor for scout called sniper (all TF2 characters).
As far as I understand correctly SteamOS might be based on Arch, but it uses Valve's kernel and mesa while running the games themselves in a container.
Yup, I was talking about the Steam Runtime, or whatever it's called, not SteamOS. Last time I used Steam it downloaded and installed all of that somewhere in my ~/.local or thereabouts.
Basically everyone is using something Debian/Ubuntu-based or Arch-based. If you can install a flatpak or Debian package you’re pretty much golden (which includes Fedora users, who can install flatpaks).
Vulkan is pretty much the graphics API standard for the entire Linux ecosystem.
I've been using linux mint for a while now and the only thing I wanted to play but haven't figured out how to run yet is the twin peaks demo on itch.io. But also most of the games I play are on emulated consoles anyway so usually as long as the emulator works everything is fine.
Hopefully new games will prioritize Linux/SteamOS over Mac, I am still checking games and see them only supporting Win/Mac and Proton rating is not perfect and could at any time fail if game updates.
I hope, but I would not bet on it. Unity supports Linux for a long time and still I see some Unity games are not published for Linux but published for Mac, not sure if why, maybe because some people in the team are using Mac and are fine with testing the Mac builds but don't care about Linux. I am OK with Proton official support, then we know that we get support for breaking bugs.
I'm hoping that the Apple Game Porting Toolkit signals a shift to more games support.
Thankfully, the Apple Silicon machines are powerful enough to support many modern games. I'm currently (and happily) playing Baldur's Gate 3 using Wineskin on my M1 MBP with no problems. So far no bugs, and multiplayer with PC users works great.
Apple isn’t doing itself any favors, but the status quo has been the same for years now.
I consider myself a big old Apple fan boy, have various flavors of Mac machines around the house, etc.
But my Steam Deck has been an absolute revelation. Makes it so easy to pick up games really quick, game in random places, and use my existing library of games whenever I want.
I also have a gaming PC… which I hardly boot up anymore.
The Steam Deck is easily my favorite consumer electronics device, in years. Probably since the original iPhone came out.
The delta between MacOS gaming market share and Linux gaming market share on Steam is exclusively due to the Steam Deck.
If you are saying that Steam Decks comprise nearly the entirety of Steam on Linux usage then I fully agree with you; however the number of macs in the market is so far and away larger than the number of steam decks, that the two platforms ordinarily shouldn't even be comparable.
With every new release of hardware or software that Apple makes, fewer and fewer of the existing game library on MacOS (Steam or otherwise) continue to work; it's absolutely absurd. You know you can't even play Bejeweled on a modern mac, right? How am I supposed to explain that to a widow with Alzehimers who just wants to keep playing the games she remembers? (This actually happened. I had to fucking wine-bottle the windows version myself)
Of 502 games in my Steam library only 163 will run on an Apple Silicon mac. Big kudos to the game authors who even bother anymore.
I'm so curious to know how hard it would be to make another Linux deck.
Back when Steam was trying to make consoles, they were recruiting others to make the hardware. I'm not sure how available software was then, how open options were then. But I so want to know it compares to today.
It sounded like the whole Deck UI was fairly custom at start? And there has to be a decent bit of custom integration, beyond the shell itself. Tweaks to the base Arch OS & it's packages. Supposedly the Big Picture Mode in Steam has gotten a decent overhaul that makes it more Deck like, but I haven't tried it nor a Deck yet!
I hope someone else out there has the courage to try a Linux gaming deck!
> Interesting that the quest 2 wins for Vr headsets even though it’s stand alone.
The reason for this is pretty clear, there's nothing as good as the Quest 2 in the PC VR headset market anywhere near the Quest 2's price, and even if you're willing to fork out more the options are either long on the tooth or mediocre for the price. It's why I use one as a PC headset.
I've been playing War Thunder simulator battles in VR for the past few weeks, and have gotten serious enough about it that I've upgraded my PC and dropped ~$400 on a HOTAS setup.
I'm using my Quest 2 because there's really no other viable options. The resolution isn't high enough to be "good", but it's simply the best available at the moment. I'm anxiously awaiting the Quest 3 and will buy it at release.
There are some headsets out there now with higher resolution, but they're very expensive, hard to actually find for sale, from a small/unknown manufacturer, or all of the above.
Yes and no, by installing Steam as flatpak. The Steam Linux (and Windows) clients still require 32-bit, but with flatpak the rest of the system doesn't have them.
Edit: freedomben commented that Steam works but complains on Fedora w/o 32-bit libraries. So it might work until a game actually needs them.
And macOS has a 64-bit-only Steam client, altough they don't support any 32-bit games anyway.
I want to share a personal anecdote, as I recently spent quite a bit of time deciding whether or not to leave Mac OS for linux (Manjaro) this year for my personal computing needs - primarily because of gaming. Ultimately, I did make the switch.
Several years back, Apple broke most of my steam library with Catalina.
I wasn't a serious gamer, but I had a lot of nostalgic games from the aughts and early 2010s that ran great (pre-Catalina) on my top-of-the-line mid-2015 retina MBP.
I finally retired that machine this year and bought a higher-end gaming pc for less than half of what it would cost me to get a less-than-the-best Apple Silicon MBP.
Yeah, it's heavy. Battery life isn't great. But my phone has replaced so much of my mobile computing needs that I don't really need to take a laptop with me when I'm traveling unless it's for work, in which case I'll have my company-issued machine with me anyway.
I never thought I'd leave MacOS for Linux - but I recently got back into gaming and basically wasn't willing to spend $4k+ on a machine I couldn't game on when all of my personal project needs, etc. can be attended to on a cheaper gaming laptop.
The fact that Apple Silicon is an absolute beast, graphically, made it all worse somehow. Like having a Ferrari in your garage that you aren't allowed to drive - only pay for and look at.
Am I Apple's target demographic? Apart from being a developer - probably not. I don't do a lot of multimedia stuff (at least, I don't do anything that isn't adequately served by a PC with a solid GPU). Because I grew up on linux I'm right at home there with all of my non-work dev / geek / fun stuff and that probably makes me an outlier.
Apple's success clearly speaks for their business savvy - and, there's now a number of chinks in my (previously 100%) Apple loyalty across my wide array of gadgetry (several Apple TVs and one each for me and my wife of: laptop, ipad, iphone, watch, airpods). After a disappointing battery experience with my airpods - I replaced them with some excellent-sounding soundcore buds. My apple watch needs to be replaced soon and I'll probably get a Garmin (again - battery life and consistent failure to capture VO2 max on outdoor runs, other frustrations). I enjoy VR gaming and plan to upgrade from a quest 2 to a quest 3 instead of buying a vision pro. What's next to go in my Apple line-up? I don't know but I've become much more open to shopping around for non-Apple tech than I was in, say, 2016 when it seemed to me that nothing else could compete with Apple.
I wonder how true this is for Apple's "geek core" of tech professionals, and how much of it is just my unique little anecdote? And, in any case - does Apple care? They've cornered the market for both the technical-artistic and "luxury" class. Plenty of meat on those bones without worrying about the geeky whims of the pesky few that are open to (and capable of) something like abandoning Mac OS for Linux.
Still, it was sad to give up my Mac OS personal computing environment. I love Apple - but for what I care about, Apple just doesn't seem to love me. We'll always have our iOS time together I guess, for now anyway.
I was hoping for that trend to reverse with game porting toolkit, but it doesn't seem like that's happening. Whoever pushes for Gaming at Apple doesn't seem to have massive internal support. Metal VR died almost as soon as it released and somehow they thought making Game Porting Toolkit license incompatible with Wine/Proton/CrossOver was a great move, because all you need to convince a game developer to invest in a dead (to your audience) platform that will likely deprecate your API in a year or two is a proof of concept of how well it can run.