It won't be because Apple decided to make it's own competing standard.
Every big vendor and platform for 3D games and software, has their own graphics API which work better and faster than OpenGL and Vulkan. It is only CAD still stuck on OpenGL (and the proprietary extensions).
Idealism is not the answer to positive end user experience.
[citation needed]
Not that they have their own API, but that it's at all better or faster than Vulkan. Remember Vulkan primarily came from AMD's Mantle. It's not the creation of a committee catering to the lowest common denominator.
And no, it's not only CAD still stuck on OpenGL. Games use it, too. Most of mobile is also on OpenGL ES. Increasingly more of them use it than they used to, even, as increasingly games are using off-the-shelf engines that are already cross-platform and have an OpenGL back-end.
The single largest consumer OS in the world (Android) only supports OpenGL ES & Vulkan, even, with no proprietary graphics API of any kind.
Largely due to support in Unity/Unreal. They would be using OpenGL ES still if they had their own engines except maybe the biggest game studios that always have custom game engines/rendering integration.
So lumping together all of these variants and calling them "most used OS" is not useful in any sense. They are very different for users, and very different for devs.
This is specially relevant when you want to develop a game against a graphics API. Samsung has Vulkan on their flagships for a couple years now, but not the mid/low-end devices. Pixel supports Vulkan, but the units sold are so low that they are a rounding error. No other major manufacturer significantly supports Vulkan either. In this and similar scenarios, the framework used by ios may well be the "most used" mobile framework.
Then you're correct by your definition, but not by most people's definition.
And even then, it is only required on those that support VR.
Metal is supported on across all iOS devices still getting updates.
Since nearly everyone's GLES 3 hardware both supports vulkan & has vulkan drivers already there's no particular reason to believe that an OEM will decide to just not ship vulkan support. It's more work for them to remove Vulkan from the SoC's base image than it is to just not touch it.
The low-end GLES 2 hardware is the only problem, which is a market iOS simply doesn't exist in at all. So if you're cool with ignoring that market, go for it.
https://godotengine.org/article/abandoning-gles3-vulkan-and-...
Lets see if they have better luck with Vulkan.
True but console is a different beast though, it seems you are focused on that not just mobile which was always just OpenGL ES mainly since '07 until Metal entered the arena.
On consoles/custom handhelds, they have always had their own frameworks to get the most out of their custom hardware and for lock-in exclusives, to compete and advance their hardware as far as possible for the console lifeline, to sell as many games as possible as the hardware ages as game content is where they made profit. Consoles have modified versions of frameworks or their own like gcm from Sony. They do support standard ones but mostly people use the custom ones to get the most out of the hardware and the hardware makers like that.
On desktop, only two essentially in DirectX and OpenGL and was that way for a long time. Portability was fine, DX windows, OpenGL everything else but DX was the major one due to Windows desktop dominance.
On mobile, OpenGL ES on the major mobile platforms, iOS and Android, pretty much the only one since '07 until Metal.
As I mentioned in other areas, not a huge deal to game developers who aren't building their own engine but portability does matter on desktop and mobile, not just consoles which have reasons for custom rendering engines/toolkits.
They were the ones telling Sony that their efforts for having OpenGL ES 1.0 on the PS3 were not worthwhile pursuing.
OpenGL ES on the PS3 was barely used beyond prototypes and simple demos.
Using Vulkan is like writing your own language runtime over system calls: you have to handle memory allocation and synchronization on your own.
IMO, this is a common misconception. Or, at least, the extrapolation of it is. Vulkan might require a lot of code to initialize, and has extra responsibilities related to memory management, synchronization, etc., but in my experience the end product doesn't require significantly more code than other graphics APIs. The up-front cost you pay doesn't translate to increased costs everywhere else, at least not to the same degree.
My library supports D3D11, Metal, Vulkan, and OpenGL, and Vulkan is the second-largest backend, but not by a lot (LOC: ~5k Vulkan, ~3.3k D3D11, ~2.5k Metal, 6k OpenGL). LOC is not the best indicator of complexity, to be fair. My OpenGL backend is definitely the most difficult to maintain and the largest, because the API is such a pain to deal with.