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.
This is the world that was born from demoscene, where exploiting cool hardware specific tricks was more valuable than writing portable code.
There were several efforts in the past to revamp OpenGL (e.g. long's peak), but they all failed. OpenGL was stuck and there was little reason to think the situation would improve. Writing OpenGL code that worked across multiple platforms was worse than it is today to write multiple per-graphics-API render backends.
OpenGL was not stuck, either. OpenGL's AZDO project was alive & well: https://www.khronos.org/assets/uploads/developers/library/20... (just not on macOS because AZDO is GL4.2+ whereas macOS is stuck on 4.1)
I am not saying opengl or vulkan is bad.
Apple Metal launched in 2014.
Sony and Nintendo and NEVER used OpenGL for anything extensive. Sony talked the talk around 2005 and 2006 with the launch of the PS3 and OpenGL ES but PSGL was always more performant.
Source https://developer.nintendo.com/
Just like Sony did in the past with the PS 3 and GL ES 1.0, they are just testing waters to see which way devs go.
In the PS3 devs preferred to pick Sony's API instead.
PLEASE prove me wrong.
Uou have convinced me that Metal might not be so bad... at least is all the consoles have custom APIs then it’s not as unusual as I thought.
On the other hand, when I develop OpenGL programs on Linux, it takes maybe a few hours to fix up the few compile errors I might encounter on OSX. Swapping out the graphics API would dwarf all the other porting work combined.
Seriously, all I want is to be able to write graphics programs using compute shaders and share them among my colleagues who use OSX, Linux and Windows. I don't want to write my programs three times. Is that really too much to ask?
The bummer about Apple is that they did help fund Khronos/OpenGL ES and subsequently WebGL from that stack that really revolutionized mobile/handheld gaming. They were big in helping open tech like that as well as canvas, html5, svg etc when the iPhone first came out. They killed Flash essentially and brought H.264 to take a big part of what Flash did, video. Part of how they won was using OpenGL ES and a decent rendering hardware device, it was an amazing thing to see in 2007 and changed handheld gaming big time.
Now Apple has Metal, their own rendering kit, that only works for macOS/iOS where OpenGL was easier to then port to iOS, Android, *nix, even use on Windows etc for desktop/mobile games especially. Apple used open rendering to allow easier porting to their platform, now they have flipped and have taken on a big part of rendering on their devices, a big software part that they hopefully will keep well maintained and up to compete.
But really today there are so many great engines that are middle tier in Unity and Unreal for instance that low level rendering frameworks aren't as big of deal to integrate as it is handled by these middle layer engines. Metal being so prevalent on iOS is only because Unity and Unreal support exporting with that as those two engines make up the largest part of mobile games.
There are four major rendering frameworks now with OpenGL, DirectX, Vulkan and Metal, including others like libGCM and flavors of OpenGL like ES/WebGL. This does complicate things for game engine developers, maintenance and portability with four market standards now. On mobile there are now a few instead of just OpenGL ES versions the dominant one since handheld gaming was taken over by Apple iOS/Google Android. Console game development is a different beast than mobile and desktop in terms of rendering frameworks used for many reasons, mainly that the hardware has to age longer and you need to get every bit of performance.
Most game studios now let the middle tier companies like Unity/Unreal/Cry/Source be their engine team now so it isn't as impactful, so studios can focus on game development, design and content. Back when you did have to write your own engine and rendering layer, it was nice to only have two essentially in DirectX and OpenGL on desktop, and OpenGL ES on the major mobile platforms, console development being the area where there are many frameworks and custom ones per hardware device. The slow progress before mobile and new frameworks was frustrating at times but primarily due to hardware progression, currently it is good to advance and get rendering kits competitive again.
Yet here we are again. If Valve had to port software to Nintendo or Sony; they would be using the native, supported API's. Not porting over Vulkan or OpenGL.
Just use Metal. It really is, very good.