>if they used Vulkan, it would mean they wouldn't have to debug on a Mac.[...] Neither should or would be blindly trusting that things are portable I didn't me

>if they used Vulkan, it would mean they wouldn't have to debug on a Mac.[...] Neither should or would be blindly trusting that things are portable I didn't mean this, just that you can actually run whatever shaders you compile rather than needing a Mac just to see your output. My point was that you would get "a smoother developer experience," which is true. > Vulkan/DX on AMD/NVIDIA also perform differently enough that you can't just assume parity. Vulkan has some pretty strict conformance tests[0]. It's not like you are going to run into differences between conformant Vulkan implementations every day. It's very different from not being able to run the shaders you've compiled at all. You just need to know what extensions are supported. Also, Apple's support for OpenGL was never good. They only supported OpenGL 4.1 for years while 4.5 was out, for example. I don't know if Apple's OpenGL was ever even conformant, being that 4.1 is not listed on the site.[1] >There's no current Vulkan or DX backend for it. There is actually (as an experimental feature currently).[2] And Khronos did not have to send developers to implement it for them. My understanding is that Blender also implemented CUDA/Optix themsleves and only got help from Nvidia, rather than Nvidia implement the whole thing for them, although I could easily be wrong there. >This didn't prove itself out when OpenGL was a thing. OpenGL was everywhere but barely used. OpenGL was not nearly as performant as direct X. When Direct X came out people switched to it. Vulkan and dx12 are very similar however. > That doesn't mean that Vulkan would replace it though Yeah, because each console wants their own special graphics API to force on everyone instead of using an open standard, despite Xbox and Playstation GPUs being from AMD which supports Vulkan on it's consumer GPUs. >Many engines support Metal, in addition to the plethora of console specific APIs And many don't, including the engines of a lot of AAA games like Elden Ring, Cyber Punk 2077 and Baldur's Gate 3 (although CDPR are now switching to UE5). And studios are generally using modified versions of UE so my guess is that means they are generally making low level changes sometimes, and so it makes sense to me that they sometimes may write their Dx/ Vulkan code for different things sometimes. (this is just my guess. I admit to being uninformed here). Even if not there are still ways that you could program something in UE without writing any direct DX/Vulkan code that could still result in worse performance for one of the backends vs. the other. That is why on games that support multiple graphics backends oftentimes one is better than the other. And developers will release updates improving only certain backends. Adding an extra platform like MacOS is not simply clicking a button. although it is easier today than before, if it was that simple, then literally every UE game would be on MacOS. (Yes, you do 'just click a button' to support MacOS in UE5, but there is still more to it than that.) And increasing the surface area of platform divergence does nothing to help the situation. Also, while it doesn't matter for Apple, having to maintain multiple backends adds needless extra work for engine developers [0] https://docs.vulkan.org/guide/latest/vulkan_cts.html https://docs.vulkan.org/guide/latest/vulkan_cts.html [1] https://www.khronos.org/conformance/adopters/conformant-products/opengl https://www.khronos.org/conformance/adopters/conformant-prod... [2] https://code.blender.org/2023/10/vulkan-project-update/ https://code.blender.org/2023/10/vulkan-project-update/