As has long been the story at One Infinite Loop, what Apple giveth is what Apple taketh, and Apple’s latest rendition of OSes is going to be no exception. Listed in the developer release notes for both iOS and macOS, Apple is deprecating support for what are now their legacy graphics and compute APIs: OpenGL, OpenGL ES, and OpenCL. Instead, Apple is strongly encouraging developers to use their proprietary Metal API, which has been available for a few years now.

Apple’s lack of interest in Khronos’s Open APIs has not gone unnoticed over the years. Apple never added support for OpenGL ES 3.1 or later on iOS, and similarly macOS doesn’t go beyond OpenGL 4.1 (Khronos is up to 4.6 now). Instead, Apple has been pushing developers to Metal almost as soon as it became available. And now by deprecating support for these older APIs, Apple is signaling that they are reserving the right to remove them entirely in the future.

And unlike other OS vendors who may keep deprecated APIs around for years (if not forever) in the name of backwards compatibility, Apple has proven it has no such qualms. The company has already excised 32-bit apps from iOS and is in the process of doing the same for macOS, despite the number of applications (and games!) that will break. So Apple’s threats are generally credible: if these APIs are being deprecated now, then they likely aren’t going to be available much longer.

Which means that with the loss of OpenGL support across the Mac and iOS ecosystem, so too will go support for the only truly common cross-platform graphics API across the industry. OpenGL ES in particular will run on every Mac, iOS device, Android device, Windows device, and Linux device. And while the other vendors have rallied around (or at least supported) the successor Vulkan API, Apple has not. So once the deprecation becomes a removal, the only graphics and compute API supported in the Apple ecosystem will be their proprietary Metal.

As an aside, this announcement goes for GPU compute as well as graphics. Nearly a decade ago, Apple was the big supporter of OpenCL, kickstarting the whole initiative. OpenCL never saw the success it needed, and like the other vendors, Apple has essentially rolled GPU compute into their graphics API. Still, it’s an interesting turn of events when the first vendor to drop support for OpenCL is the vendor that originally championed it to being with.

Comments Locked

52 Comments

View All Comments

  • fux0r - Wednesday, June 6, 2018 - link

    Rubbish. The open standards define an api, not an implementation. If Apple finds a way to do something more optimally, that can happen behind the API. If Apple wants to add new functionality, they could do so via an extra library. Both their OpenGL implementation and the extra library could talk directly to hardware, or Metal - allowing developers who want to compile cross-platform to use OpenGL and developers who want to make titles exclusively for Mac (ha!) to do so with their own Metal API. Already gamers bear the brunt of dx vs OpenGL. This will be bad for the consumer
    - existing games will stop working and won't be ported (publishers have zero benefit to doing so)
    - new games are less likely to come to macos - devs already have either OpenGL or dx experience or both - unless engines like Unreal and Unity support it, and then that's not good for healthy game engine competition
    - this is likely to impact Linux gaming to as the argument to support because of similarity (at least in graphics API) to macos goes away.

    As with so many Apple decisions, it's the consumer who loses out here. Apple are taking a leaf out of the 1995 Microsoft playbook.
  • techconc - Friday, June 15, 2018 - link

    OpenGL allows for extensions which in turn allow GPU makers a means of exposing new functionality. However, it's a clumsy approach and you end up needing to have code paths for each type of video card. Not ideal. Further, OpenGL is old and fundamentally different in terms of the instruction pipeline. Think of it this way, to draw a scene in OpenGL, the CPU needs to send the GPU a bunch of different commands to make that happen. With more modern APIs like Metal, Vulkan, etc. the CPU sends the GPU a scene description and the GPU figures out all of the details to make it happen. These results in far fewer draw calls and better overall performance.

    The fact is, Apple was burned by OpenGL moving at a snails pace. So, they did they only thing they could to improve the problem and that was to role their own API. Vulkan followed and shares similar design goals, but it is considerably further behind in terms of maturity and development. The bottom line is that users get the best experience when developers use Metal. The popularity of the platform will determine if it is worth the effort of developers to do so.
  • xpusostomos - Wednesday, August 1, 2018 - link

    Users get the best experience when the program they own runs. Funny that.
  • BillBear - Tuesday, June 5, 2018 - link

    You can do the same thing that Google did with Chrome on Windows.

    >ANGLE (Almost Native Graphics Layer Engine) is an open sourced graphics engine abstraction layer developed by Google that translates OpenGL calls to Direct3D.

    Microsoft has even created their own fork of the project.
  • hosps - Tuesday, June 5, 2018 - link

    This is one of the main reasons I can't get behind Apple. They artificially limit choice by restricting technologies which are widely utilized by others. Limiting choice only hurts the consumer. I can only hope the industry takes notice and doesn't cater to Apple's forced decision.
  • techconc - Tuesday, June 5, 2018 - link

    What choice is artificially limited? It's not like there is no porting effort required just because apps use a common API like OpenGL. There is either a business decision to target Apple's platform or not. Over the past several years, pretty much any application that matters has embraced Metal on Apple's platforms. All of the major gaming engines support it as well.

    OpenGL was fine in it's day, however for many years now, it has held Apple back. It was time to move on.
  • PeachNCream - Tuesday, June 5, 2018 - link

    "It's not like there is no porting effort required just because apps use a common API like OpenGL."

    Correct, but now there is _more_ porting effort to bring programs over to Apple which will further marginalize and isolate Apple from mainstream computing. As you implied already porting goes from some other platform to Apple which already indicates where Apple stands in the human centipede of the computer industry as viewed by software developers.

    "Over the past several years, pretty much any application that matters has embraced Metal on Apple's platforms."

    I wouldn't be so quick to speak in absolute terms. It's a perilous matter to presume to speak for everyone else by claiming what matters to them has already been moved to Metal.
  • techconc - Friday, June 15, 2018 - link

    I'd suggest that you're also missing some market realities. Cross platform APIs sound like a nice idea, but in practice, take Apple out of the equation and what do you really have? Microsoft has their own DirectX APIs and nobody seems to complain about that. Apple tried very had to champion OpenCL and yet developers have preferred to use the proprietary CUDA. The same goes for Metal. Metal will always be better on Apple's platforms than Vulcan, OpenGL, OpenCL could ever be. Why? Because they can optimize for their specific use cases and hardware.
  • GreenReaper - Tuesday, June 5, 2018 - link

    Oh yeah? Deprecate this! *throws teapot at the wall, shattering it into shards of volcanic metalloids*
  • plopke - Tuesday, June 5, 2018 - link

    So no official Vulkan,OpenGL and off course no DX which is all understandable for their mobile offerings. But all this plus no openCL for macOS. Low level API's are fine but making it the only option?
    The circle continues in the IT-industry , Make something lacking functionality/abstraction -> add functionality/abstraction -> wonder if it is to bloated -> Make something new lacking functionality/abstraction -> .....

Log in

Don't have an account? Sign up now