---
apple is bullish on metal vs vulkan because they want to lock in apps. and they have the upper hand because by not implementing vulkan, they force everyone to chose between the money on IOS or everything else. it's not a technical decision.
middle ware provide only the minimum common denominator, or expensive translation functions, it is not even close to providing the flexibility and speed modern emulators need.
absolutely nobody plays on apple hardware. specially not the people that are into gaming enough to write an emulator. no matter how much you personally want to believe the opposite.
Usually I only find this anti-Apple argumentation in pro FOSS forums.
Do they work with graphics? OSX doesn't really have many native games running on it. So clearly there's a whole group of developers who aren't Mac first.
Like OSX is enjoyed by a lot of developers because it's similar to Linux.
However Apple deprecated openGL, aren't using Vulkan but have their own thing called Metal. So that makes it quite OSX specific.
Edit:
Looks like someone is working on it: https://github.com/PCSX2/pcsx2/issues/18
That they don't bother with supporting Vulkan is incredibly frustrating for me personally, but not even remotely surprising given Apple's mode of business.
"MoltenVK is a Vulkan Portability implementation. It layers a subset of the high-performance, industry-standard Vulkan graphics and compute API over Apple's Metal graphics framework, enabling Vulkan applications to run on iOS and macOS." [1]
The approach taken by AAA game engines, although nowadays it looks more like a bunch of abstract classes/interfaces, depending on the language.
When you look into a game engine, typically 3D API abstractions are like 10% of the whole codebase.
You can look at this article: https://dolphin-emu.org/blog/2017/07/30/ubershaders/ for an example how console graphics programming differ.
Middleware designed for games don't allow nearly enough flexibility to handle all the possible edge case that can arise. Console gpu (and graphics api) and computer gpu don't map one-to-one and they need all the feature and support from the underlying api that they can get for replicating the console way of doing things, supporting a new graphics backend is a lot of work for this reason. middleware try to abstract common pattern and flows, but every console is quite unique (in some way) middleware are not build for that and often are (a form of) a lowest common denominator for graphics api. Which is fine... for games.
edit: some clarification
Even if you stay, lets say OpenGL only, there are multiple execution paths with driver and graphics card specific code paths.
3D libraries like OpenGL/Vulkan are only portable up to a certain extent.
When you are coding at the ultimate performance level, you are also going into that rabbit hole of graphic card specific code paths and driver specific extensions.
So, it is hardly different than having your own plugable abstraction layer.
I wouldn't mind to contribute if paid accordingly.
FTFY
Mac just doesn't make sense for this use-case beyond "I want an Apple logo!". Most people buy a tool to solve a problem, not hammer the problem to fit a brand.