macOS 15.8.2 Breaks OpenGL Window Rendering, Leaving Apps Blank
After updating to macOS 15.8.2, every OpenGL context attached to a window loses its default framebuffer. NSOpenGLView and NSOpenGLContext setView: both fail, so apps like kitty, Alacritty, Godot, and Bambu Studio render blank windows. Apple's DTS engineer acknowledged the report but won't comment on fixes. A workaround is to render into an IOSurface-backed FBO or use CAOpenGLLayer.
Every OpenGL context that is attached to a window has no default framebuffer.
- Aurornis
15.8.2 isn't released.
This is a report from the developer forums where people are supposed to report these bugs.
The second response in the thread is an Apple engineer acknowledging the bug, assigning a number, and asking the person to retest when new builds are available.
If you only read the comments here you'd come away with a completely different impression of what's happening.
- mosura
The general Apple software quality decline seems to be accelerating. We are in the thousand papercut stage where lots of small things just don’t work properly.
One of my Macs has developed the most insane habit of losing audio output capability, and then tries to route it to another one - a feature I didn’t even know existed.
- ryandrake
Sad but not surprising. Apple marked their OpenGL subsystem as deprecated all the way back in 2018 with macOS 10.14 Mojave and iOS 12. By some miracle it has kept working all that time. While I hate it that Apple can just up and declare a widely used cross-platform API 'deprecated,' it's their system, not ours. So, we should not expect them to care or lift a finger if they accidentally break it.
- flohofwoe
Bitrot in the Apple OpenGL shim or (especially) window system glue really isn't unusual unfortunately.
E.g. the most recent actual bug in the Apple GL shim I stumbled over is that when copying data from the pixel unpack buffer bindpoint, the two ways to provide an offset into the source data are both broken.
I suspect that any feature that's not on the beaten path (e.g. used by a handful legacy but popular GL applications) simply isn't tested, assuming any testing even happens at all.
PS: also personal opinion, and not related to the Apple mess: just let GL go, it's really not a great API to work with (at least not since version 2). Vulkan isn't all that great either, but at least it has slowly started to change into the right direction in the last couple of years, while GL will remain a mess forever since Khronos has dropped the API too - and on Apple devices, Metal is clearly the better (and much nicer to work with) choice compared to both GL and Vulkan.
- corysama
Seems like a good time to mention that LunarG’s Vulkan-on-Metal wrapper reached Vulkan 1.4 conformance recently.
https://www.lunarg.com/the-state-of-vulkan-on-apple-oct-2026...
Now we need Mesa’s OpenGL-on-Vulkan to be production-ready when running on KosmicKrisp
- Haunt1000
Right I'm still on 15.5. But random app windows flicker! FLICKER! And it's a brand new 2025 M4 MacBook Air. This is the kind of thing I would expect from like Linux in say 1998?
- 1over137
WTH. 15.8.1 is current, 15.8.2 ought to be security fixes only.
- cadamsdotcom
Related positive note. It's wonderful Apple is still looking after macOS 15 users!
I'm insanely grateful to the humans inside Apple who keep macOS 15 patched.
- potatoproduct
There's a few very annoying audio and Bluetooth bugs on MacOS. I've even installed 3rd party software to hack a fix one of them.
- zimpenfish
Fails to reproduce on macOS Version 26.6 (25G70) (but I can't post a reply on the forums because developer.apple.com currently hates me.)
I get the green triangle and `hasDrawable=1 status=0x8cd5 glError=0x0` which is the expected result.