Ugggggh. As if graphics support on macOS weren't middling enough already. It's like they're trying to become as irrelevant as possible in that area.
I could understand if they were deprecating it in favor of Vulkan. That would be in-line with Apple's history of aggressively pushing forward new standards. But by no means do they have the clout to coerce developers into their own bespoke graphics API that doesn't work anywhere else. All they'll accomplish is further killing off the already-small presence they have in the gaming space.
Fortunately you can still use Vulkan on iOS and Mac OS through MoltenVK[1], a Vulkan implemention in Metal.
Why is Apple investing in Metal at all then?
Same reason Microsoftinvests in DirectX. Lock in software developers and consumers alike.
I can kind of understand iOS, but it’s not like there’s a thriving graphical computing market worth locking in on the mac side. All major titles already use game engines. They’d just be locking out smaller developers who can’t invest in porting all their shaders: it’s not gonna be worth the effort.
Granted, this may also be true for OpenGL.
But iOS is a lot bigger than macOS.
You notice that Apple supported OpenGL while they were making most of their money from desktop and laptop sales; but once iOS became so profitable, they decided to go their own way and start pushing Metal.
Lock in, or at least getting people to do more iOS first development (helped by lower profits on app store sales on Android, Android fragmentation, etc), helps Apple out a lot. You get the first version of apps and games, or more polished versions of apps and games, on iOS this way.
So why lock in macOS at all?
Because the developers who would be working on OpenGL on macOS are working on Metal instead, because that's where the value is for Apple.
Maybe.... why would you assume they continue developing for macs at all? Small studios might not have the resources, and the market is tiny for many apps, eg indie games, modeling software, and ML (to be fair, apple has repeatedly emphasized they don’t care about ML on the desktop by not offering nvidia cards...).
And again, I don’t see the benefit for apple over supporting cross platform apis to encourage development. It seems like a net loss for everyone but some line in their budget on driver maintenance.
Providing macOS gives a developer and designer platform for iOS. That is really important for them. So Metal being available on macOS is important for that reason. But it's also important in that the Mac platform is still important, just not nearly as important as iOS.
OpenGL doesn't really have much of a future. Everyone is moving towards the next generation frameworks. It just happens that there was a lot of uncertainty about whether OpenGL could adapt or whether there would be a successor, and during that time Apple decided to invest in developing Metal. It wasn't until a couple of years later than Vulkan was released.
In the meantime, Apple has built up quite a lot of tooling around Metal.
And it's not like it's that difficult to write cross platform apps that target the Mac. If you write against major engines, they will already have support for the different backends. If you are writing your own software, you can still target OpenGL, or you can target Vulkan and use MoltenVK to run it on macOS.
And for the next several years, people writing portable software are going to have to either just target OpenGL, for compatibility with older graphics cards, or maintain at least two backends, OpenGL and Vulkan. Given that lots of games target DirectX first, and consider any of the cross-platform frameworks a porting effort, Apple probably doesn't consider it a big loss to add one more platform that needs to be ported to.
What's going to wind up happening is more software like ANGLE (https://github.com/google/angle), MoltenVK (https://github.com/KhronosGroup/MoltenVK), and gfx-rs (https://github.com/gfx-rs/gfx and https://github.com/gfx-rs/portability, see http://gfx-rs.github.io/2018/04/09/vulkan-portability.html for details) for providing one set of abstractions on top of several different backends.