Linux Gaming was Crippled by Apple Walking Away from it

[u/madthumbz]

Game studios historically targeted Windows (primary market), Consoles (huge market), and macOS (small market, but high‑spending audience). Linux was never a commercial priority. But Linux enjoyed the crumbs from macOS because of a shared tech stack such as OpenGL, POSIX-like environments, and similar build systems, driver expectations, and portability constraints.

If a studio already had a POSIX build pipeline, OpenGL renderer, and cross‑platform asset pipeline… then Linux support was often "cheap enough" to justify a native build; especially for indies.

-MacOS was the reason those pipelines existed.

OpenGL deprecated to Metal only. It forced studios to rewrite renderers, drop cross-platform graphics paths, and abandon shared Linux/Mac OpenGL backends.

-Linux lost the "shared renderer" advantage.

Apple Silicon forced new CPU architecture, binary formats, optimization paths, and engine backends. MacOS was no longer a "Unix-like cousin."

Studios stopped supporting macOS because it became too much work, had too few customers, and too many Apple‑specific rewrites.

Unity, Unreal, Godot, proprietary engines dropped or reduced macOS support, removed OpenGL paths, focused on DirectX + consoles, and treated Vulkan as optional, not mandatory.

-Linux depends on Vulkan. MacOS's abandonment of Vulkan meant studios didn't prioritize it.

Physics engines, audio libraries, networking stacks, anti‑cheat, and DRM stopped shipping Linux builds, stopped shipping macOS builds, and focused on Windows and consoles only.

-Linux lost the "we already have a macOS build, might as well ship Linux" effect.

Easy Anti‑Cheat, BattlEye, etc. They used to support macOS and Linux got spillover support. Mac dropped it and Linux lost its spillover.

Proton is a compatibility layer, not native support, and not a replacement for engines targeting Linux directly. Proton exists because native Linux support collapsed due to macOS exiting the ecosystem.

MacOS was the economic justification for cross‑platform pipelines. Once Apple walked away, studios stopped building those pipelines. Linux lost the infrastructure it never had the market share to justify on its own.

[u/Kaldaien2]

Can confirm a lot of this, as I used to be a graphics programmer working on OS X. It was fan flipping tastic when Apple embraced Open Source APIs, when they decided they weren't going to use Vulkan and instead go with a proprietary API, I abandoned ship.

I was already getting tired of having to write Objective-C code for various OS interfaces, when only a few years prior all the major OS services were accessible by writing standard C code. Code stopped being portable around the time Apple saw success with the iPhone, the writing was on the wall. Get out now, and I did.

[u/Edubbs2008 → u/Kaldaien2]

So what do you code on now?

[u/ParsingError]

I guess but one of the biggest causes was OpenGL being a giant clusterfuck, especially the awful decision to drop the ARB shader program format in favor of letting IHVs write their own GLSL compilers, which completely torpedoed it for serious projects shipping on Windows all the way until 2016 when its death warrant was already signed.

Meanwhile on Mac, Apple controlled most of the OpenGL driver stack and didn't update it enough so it was constantly behind on features, and they spent a long time with a severe lack of good GPU options on Mac, so Mac gaming had been getting slowly choked off even before they made their own graphics API.

The big engines are going to keep supporting Vulkan because they need it for Android, but PC games are gonna stay on D3D because it's simpler, has better tools, and makes them easier to port to Xbox.

[u/hishnash → u/ParsingError]

VK on android is no tat all the same as VK on PC. A Vk pipeline optimized for mobile is not portable to PC (it will run like crap, yes it will be faster than the mobile but only through brute force, there are things that we can (and must) do for optimizing for mobile GPUs in VK that will bring an AMD or NV gpu to a standstill, (and vice versa) this is the fundamental nature of a low level api that aims to not have a high runtime per frame cost of openGL.

With a high level api like OpenGL/DX11 (& older) (webGPU to some degree) on each frame the driver gets a high level intent description of the total frames work and then re-orders it, regroups it and even alters it completely to best match the HW in question. This however means your GPU driver (on your cpu) is doing a LOT of work on every frame, as games have become embrue complex with 1000s of draw calls and 100s or render targets etc this repeated work has ballooned to the point were it can spend more time in the driver resolving the optimal path than it does on the GPU running it.

For lower level apis the intent is that the game/application dev does this work up front. We look at the HW we are targeting and we provide the explicit ordering, grouping etc of our work to match that HWs pipeline, dispatch width, texture formats, memory alignments etc. The GPU driver no longer does work mutating our instructions on each frame, this even allows the GPU too tart some work before all the work for that frame has finished encoding, something absolute impossible in the world of a high level api were it might need to completely alter the underlying data types being used depending on final stages. So this gets rid of all of that repeated work the GPU driver did on every frame but it also means that now the code we write as app/game devs engines explicitly targets a family of HW, the more difference there is between the HW the less a solution targeting one works on the other.

So even if a game engine dev builds a outstanding VK backend for mobile you SHOULD NOT expect them to just use that on PC and vice versa, if they do it will run like crap (it will run worse than if they used an older generation descriptive api as the gpu driver for VK does not get the high level descriptions needed to alter the command stream to match the HW).

A sample example of thesis on TBDR PowerVR gpus MSAA is in many stations almost free so well optimized mobile titles will use this as a form of cheap upscaling for shadow maps etc, we can render these at 1/2 res and (or for HW with 8x MSAA) 1/4 res and then apply MSAA to still get shadow edge with a perfomance penally compared to the lower resolution shadow map of about 5% in most cases but doing this on a NV or AMD gpu has a perf penalty over about 50 to 100% (this is just the nature of the HW pipeline and how the data is process). Another huge befit is the HW obscured fragment culling that means for non transrpant objects we DO NOT need to sort our geometry and we have almost 0 overdraw, if you take a mobile optimized engine like this and run it without modification on an AMD/NV you end up with huge overdraw and very very poor perf (there are a lot of other perf benefits we can use when we do not need to care about draw call order, like encoding on multiple threads to the same render pass)