Recently, one of Apple’s focuses at the latest WWDC keynote has been gaming. Two important pillars for this are an HLSL to Metal shader compiler, and the Game Porting Toolkit. Both are important, since HLSL is dominant for shaders in the industry, but the GPTK has become popular outside its intended target audience, with many videos with end-users instead of developers using it to try the latest AAA games. This has led to a lot of speculation online about what obstacles exist for game developers looking to port their games to Mac. What challenges actually matter?
(This is a bit of a rougher post, more addressing common points I see from Mac gamers on why they don’t have games. I’m not a game developer or expert in 3D graphics APIs, but I do keep up with the space. There is also some Kremlinology on Apple, but that’s inevitable considering the secrecy.)
Commodity engines support Macs (but maybe not your shaders)
Most games nowadays, especially anything not AAA, use off-the-shelf engines like Unreal and Unity. If you’re not going deep into engine internals, the rendering pipeline out of the box supports Metal and various other Apple-specific APIs. For your average indie game, you don’t need to worry. What often does vary, even if you aren’t customizing the engine, is shaders. These tend to be rendering backend specific, so the HLSL compiler for Metal is useful here, as it saves you from having to write Metal shaders. For larger games, even more so.
So if the engines make it easy to ship a Mac build, why don’t developers? Easy; QA costs. If you ship something, you’re obligated to support it. If you don’t have any Macs and Mac people, and the number of expected Mac buyers low (historically true), why bother?
Vulkan isn’t as common as you think
Vulkan is very frequently brought up as a reason why game developers don’t target Macs. Apple and the Khronos Group have seemingly had a falling out for a while, so Vulkan and modern OpenGL aren’t on macOS. Wrappers like MoltenVK exist, but aren’t officially endorsed by Apple.
However, this isn’t much of a problem as you think. Vulkan isn’t the standard low-level graphics API on anything but Android and GNU/Linux; support on other platforms is provided by driver vendors or second-tier. Windows and the Xbox have DirectX 12, the PlayStation 5 and Switch have their own custom APIs, and of course, Apple has Metal. For your average AAA studio, you’re going to have to use Sony’s API, and you’re also going to use DirectX 12 for the Xbox, so why not DirectX on Windows as well? For mobile games, Vulkan on Android is obvious, but the iOS users who are likelier to pay for games are supported by Metal, so you’ll support both. And if you’re just using an off-the-shelf game engine, it’s likely going to support Metal anyways. As a result, there’s less Vulkan-based games than what the internet will tell you.
If you’re looking to target Apple platforms, you’re going to have to involve Metal, but this isn’t unlike other platforms. So why do people talk a lot about Vulkan anyways? The most obvious proponents of Vulkan have been id and Valve, the former shipping games with it, and the latter surprisingly shipping games at all. However, Valve’s interest is less in the games, and more infrastructure. Their investments in the Steam Deck require Linux be able to support games, hence why they invest in Vulkan, Mesa, and in particular, Proton/Wine. The latter requires a lot of work to support Windows software transparently (porting is hard), and in particular, wrapping DirectX and adapting to Vulkan with DXVK.
Sidebar: It’s worth noting that these low-level APIs are really complex to deal with for small developers. If you’re an indie game developer doing your own engine instead of going off-the-shelf, Vulkan requires a lot of boilerplate. Some of it is necessity due to having to manage resources yourself, but some of it is simply just Vulkan API design decisions. DirectX 12 is better about this, but isn’t far behind. Metal is considered the easiest to start with, but unless you’re targeting Apple platforms exclusively, you’re likely not going to use it. And you’re inevitably going to have to support multiple platforms. The higher-level APIs like OpenGL and DirectX 11 have been rotting because the large players no longer care about them, but WebGPU outside the web looks like it might provide a modern alternative for low-level, but simple.
Low-level graphics APIs are hardware specific
Vulkan exposes a lot of low-level rendering details – that’s the point, so that developers can tweak performance without drivers getting in the way. However, this means it exposes low-level rendering pipeline details that higher level graphics APIs don’t. One such example is how GPUs render; mobile GPUs like PowerVR (and Apple’s GPUs are very similar) usually use techniques like tiled rendering (TBDR specifically), as opposed to typical desktop GPUs. However, this means the order of some operations, or their presence at all, will have to be different depending on the GPU archetype. If you don’t do this, then performance will suffer, or it might not even work at all. Even Metal has to deal with this.
The higher level APIs can abstract this for you, but when using a lower level API, the point is to give you control over this. Unfortunately, it’s a double-edged sword; if the engine doesn’t account for this scenario, things may work (or possible to be smoothed over by the API or a wrapper), but inefficiently. Much of this is unavoidable with low-level APIs in general. And if your typical PC game is optimized for Nvidia or AMD GPUs….
A more Vulkan specific sore point is extensions. Like in OpenGL (though not as bad as OpenGL), Vulkan has a lot of (often vendor) extensions you’ll want to take advantage of for optimal performance on some hardware. This is a bit more complex for engine developers, but Epic can probably deal with it. On the other hand, if you run that Vulkan game without those extensions, good chance it’s not going to work, or be sub-optimal.
What Apple actually wants out of developers
People are wondering why Apple doesn’t productize the GPTK. Non-developers have had good success with it and its custom DirectX 12 wrapper, but it’s obviously a rough, unpolished experience. Not to mention the license forbidding you from shipping a game with it. But why not use it?
I think it’s obvious – the performance, while impressive if you remember it’s going through several layers (x86 emulation, API translation), isn’t representative of what the APIs and hardware are capable of. Running the latest AAA games poorly isn’t going to look good in comparisons. Not to mention that the GPTK isn’t available on iOS, and Apple would like even larger games to be available there. More of the installed base is on iOS devices, and they’d like to bolster Apple Arcade.
It’s clear the intent is for game developers interested in porting to Macs to use the GPTK to have an idea of where bottlenecks are for porting (i.e. geometry shaders), and work with that when adapting their code. They then ship a native Metal application, ideally on Apple’s own store. Of course, this assumes developers have to be interested in doing a port in the first place, and for doing a proper port to be worth it over throwing wrappers at the problem. Even Valve struggles to get developers to do native ports to the Steam Deck.
However, it’s possible wider trends might make things worth it. The value proposition of a Mac looks far better than it did before 2020, with base model Macs now featuring respectable GPUs. The wider PC platform is declining with Windows use falling, and desktop GPUs becoming no longer worth the cost for many (though gaming laptops fare much better here). It’s going to take a lot of investment to get developers to care, and Apple doesn’t have the best track record with gaming, but it’s possible the state of the market helps.