For years, the situation around OpenGL on macOS has felt more or less settled.
Apple deprecated OpenGL in 2018, froze its official implementation at OpenGL 4.1, and moved its graphics ecosystem toward Metal. Since then, anyone wanting newer OpenGL functionality on macOS has generally had to rely on wrappers, translation layers, virtual machines, compatibility projects, or application-specific workarounds.
That is why I was surprised to come across an experimental project recently being discussed on r/opengl under the name Khronos_AppleICDs.
At first, I assumed it was another attempt to translate modern OpenGL calls into Metal at the application level. That would already be useful, but the project appears to be aiming at something considerably more ambitious.
From what I understand, the goal is to build a replacement OpenGL system framework and driver stack for macOS, using Mesa, Gallium, and Metal underneath.
In other words, instead of requiring developers to integrate a separate wrapper into each application, the project is attempting to replace Apple’s deprecated OpenGL components in the system locations where existing macOS applications already expect to find them.
The proposed stack appears to look roughly like this:
Existing macOS OpenGL application
↓
CGL / NSOpenGL / OpenGL.framework
↓
Replacement system framework and ICD-style dispatch
↓
Mesa / Gallium
↓
Metal backend
↓
Apple GPU
That distinction is important.
This would not simply be another compatibility library that applications must link against manually. Existing software could theoretically continue using the standard macOS OpenGL interfaces while reaching a newer Mesa-backed implementation through the normal system framework path.
Recent development updates suggest that the project already has several major pieces working or under active development, including:
- CGL and NSOpenGL compatibility
- Mesa and Gallium integration
- ICD-style context and function dispatch
- A Metal-based driver backend
- NIR-to-MSL shader translation
- Native Metal mipmap generation
- Buffer, texture, shader, and textured-draw test coverage
- Work toward modern OpenGL 3.x and 4.x functionality
One recent update mentioned that the runtime tests are now passing through buffer operations, texture uploads, mipmap generation, shader compilation, program linking, and textured rendering.
The remaining failure was reportedly isolated to pbuffer import and drawable-to-texture synchronization, which is a much narrower problem than the broader shader and rendering failures that existed earlier.
The project is still clearly experimental, and there are some major practical concerns.
Replacing protected system frameworks on modern macOS is not a normal installation process. It apparently requires System Integrity Protection and authenticated root to be disabled, since the framework and driver components must be installed into locations protected by Apple.
That alone means this is unlikely to become something ordinary users install casually, at least not in its current form.
There are also much larger questions around stability, compatibility, code signing, system updates, framework restoration, conformance, and how reliably existing applications would behave on top of the replacement stack.
Still, the project raises an interesting question.
Could modern OpenGL on macOS be revived not by convincing Apple to update its implementation, but by replacing the abandoned stack with a community-built Mesa and Metal solution?
Apple has effectively left its OpenGL framework frozen in time. The hardware is still capable, Metal is actively developed, and Mesa already provides much of the infrastructure required to implement modern OpenGL on different backends.
The missing piece has always been connecting those parts into something that behaves like a native macOS graphics driver rather than a separate compatibility layer.
That appears to be what this project is trying to explore.
It may fail. It may remain experimental. It may encounter macOS security, ABI, conformance, or compatibility problems that are extremely difficult to solve.
But even attempting a full system-level OpenGL replacement is more interesting than another wrapper that only works for a limited number of applications.
At the very least, it suggests that OpenGL 4.x support on macOS may not be as permanently closed as it once seemed.
Has anyone here looked through the project or followed its recent development?
I would be especially interested in hearing opinions from people familiar with Mesa, Gallium, NIR, Metal, CGL, macOS graphics internals, or OpenGL driver development.
Could this approach realistically become a usable modern OpenGL stack for macOS, or are there deeper architectural barriers that would prevent a full replacement from working reliably?