macOS 15.8.2 breaks OpenGL: why NSOpenGLView windows go blank, and the workarounds that work

Since the first macOS Sequoia 15.8.2 release candidate, build 24H219, OpenGL apps on Apple silicon Macs have been opening blank windows. Terminals such as kitty and Alacritty, the Godot project manager, 3D slicers like OrcaSlicer and Bambu Studio, and FreeCAD all draw nothing where their content should be. A developer who reduced it to a minimal Objective-C reproducer traced it to one path: an OpenGL context attached to a window through NSOpenGLView or -[NSOpenGLContext setView:] gets no drawable at all (Apple Developer Forums).

This article explains exactly what fails, which builds and apps are affected, how to confirm it on your own Mac in a minute, and the workarounds that reporters have confirmed — for people who use these apps and for developers who ship them. The second release candidate did not fix it, so if you own a Mac app with an OpenGL view, now is the time to test.

What does macOS 15.8.2 break in OpenGL?

It breaks window-backed OpenGL drawing: the context never receives a surface, so every frame is drawn into nothing. The original report on the Apple Developer Forums, filed as FB25133383, lists the symptoms on an M1 Pro after updating from 15.8 to 15.8.2 RC:

• CGLGetParameter(..., kCGLCPHasDrawable, ...) returns 0.
• glCheckFramebufferStatus(GL_FRAMEBUFFER) returns GL_FRAMEBUFFER_UNDEFINED (0x8219).
• glClear raises GL_INVALID_FRAMEBUFFER_OPERATION (0x506) — the same error kitty logs before exiting (kitty #10645).
• CGLSetSurface returns kCGLBadDrawable, and the kernel logs IOGPUGLDrawableUserClient::set_surface(...): Invalid surface ID = N on every attach.

The reporter stepped through CGLSetSurface: the window-server bind succeeds, then the call into the GPU driver's user client fails with kIOReturnBadArgument. In other words the window and the context are fine; the hand-off of the window's surface to the GPU driver is what is refused. It fails the same way for arm64 and x86_64 binaries under Rosetta, with or without layer backing, on the main thread or a background one.

NSOpenGLContext *ctx = [self openGLContext];[ctx makeCurrentContext];GLint hasDrawable = -1;CGLGetParameter(ctx.CGLContextObj, kCGLCPHasDrawable, &hasDrawable);GLenum status = glCheckFramebufferStatus(GL_FRAMEBUFFER);glClearColor(0, 1, 0, 1);glClear(GL_COLOR_BUFFER_BIT);GLenum err = glGetError();printf("hasDrawable=%d status=0x%x glError=0x%x\n", hasDrawable, status, err);[ctx flushBuffer];

$ clang -fobjc-arc -Wno-deprecated-declarations -framework Cocoa -framework OpenGL repro.m -o repro && ./reprohasDrawable=0 status=0x8219 glError=0x506

On a healthy build the same line reads hasDrawable=1 status=0x8cd5 glError=0x0 and the window turns green.

Which macOS builds are affected?

Both 15.8.2 release candidates are affected; 15.8.1 is not. Apple published RC 1 (24H219) on 7 October and RC 2 (24H225) on 13 October, to developers and public beta testers, describing both only as "important security fixes" (9to5Mac, 9to5Mac). The forum reporter retested on 24H225 and got identical output; the GPU driver components (IOGPUFamily 104.6.6, AGXG13X 329.2, IOSurface 372.5.4) were unchanged between the two builds, and only the kernel build moved (Apple Developer Forums).

Why CAOpenGLLayer still works when NSOpenGLView does not

Because the two paths hand pixels to the screen differently. NSOpenGLView and setView: bind the context directly to the window's surface through CGLSetSurface — the step that now fails. CAOpenGLLayer gives the context a layer-owned target that Core Animation composites, so it never asks the GPU driver to accept a window surface ID.

That also explains the odd pattern of who is hit. Apps that draw OpenGL straight into a window — terminals, Qt 6 apps such as DJI Studio, slicers and engines with an OpenGL renderer — go blank. Apps that render with Metal, or put OpenGL inside a Core Animation layer, carry on. Apple deprecated OpenGL in macOS 10.14 and points developers to Metal (Apple, AppleInsider), but deprecated is not the same as removed, and Apple has not said this change is intended.

Which apps are affected by the macOS 15.8.2 OpenGL bug?

Any app that attaches an OpenGL context to a window. The public reports so far, with what each project has said:

How to check whether your Mac is affected

Check the build number, then look for the kernel message the regression leaves behind. If you see it while an app shows a blank window, you have this bug and not a problem with the app.

# Which build are you on? 24H219 and 24H225 are the affected RCssw_vers # Open the blank app, then look for the driver refusing the surfacelog show --last 10m --predicate 'eventMessage CONTAINS "Invalid surface ID"'

Workarounds for users: hold the update or switch renderer

If you depend on an OpenGL app, do not install 15.8.2 until a build is confirmed fixed. If you already have it, the only workaround offered by the kitty and OrcaSlicer maintainers is to go back to 15.8.1 (kitty #10645, OrcaSlicer #16382). If you manage a fleet, hold this update for machines that run OpenGL tools.

Some apps can avoid the broken path themselves. Godot's maintainer confirmed that launching with a different rendering driver works, because only the project manager defaults to OpenGL; the reporter confirmed both flags (Godot #124311). The cost of Metal, in the maintainer's words, is "a bit longer first-time startup time".

# Use Metal instead of native OpenGL/Applications/Godot.app/Contents/MacOS/Godot --rendering-driver metal # Or keep the Compatibility renderer, but through ANGLE/Applications/Godot.app/Contents/MacOS/Godot --rendering-driver opengl3_angle

For Alacritty, the maintainer suggested trying the other GPU backends; on the reporter's M4 Max only the Glsl3 backend launched, and the page does not say whether it drew correctly (Alacritty #9067).

Workaround for developers: draw through CAOpenGLLayer

Move your OpenGL drawing into a CAOpenGLLayer subclass. Two reporters on the Apple Developer Forums confirmed that a CAOpenGLLayer in the same process draws correctly on both release candidates while every NSOpenGLView variant stays blank. The change is mostly mechanical: your render code moves from drawRect: into the layer's draw callback, and the layer, not you, owns the context's target.

#import <Cocoa/Cocoa.h>#import <QuartzCore/QuartzCore.h>#import <OpenGL/gl.h> @interface GreenLayer : CAOpenGLLayer@end @implementation GreenLayer- (void)drawInCGLContext:(CGLContextObj)ctx             pixelFormat:(CGLPixelFormatObj)pf            forLayerTime:(CFTimeInterval)t             displayTime:(const CVTimeStamp *)ts {  CGLSetCurrentContext(ctx);  glClearColor(0, 1, 0, 1);  glClear(GL_COLOR_BUFFER_BIT);  printf("glError=0x%x\n", glGetError());  [super drawInCGLContext:ctx pixelFormat:pf forLayerTime:t displayTime:ts];}@end int main(void) {  @autoreleasepool {    [NSApplication sharedApplication];    [NSApp setActivationPolicy:NSApplicationActivationPolicyRegular];    NSWindow *w = [[NSWindow alloc]        initWithContentRect:NSMakeRect(0, 0, 320, 240)                  styleMask:NSWindowStyleMaskTitled | NSWindowStyleMaskClosable                    backing:NSBackingStoreBuffered                      defer:NO];    NSView *v = w.contentView;    v.wantsLayer = YES;    GreenLayer *layer = [GreenLayer layer];    layer.frame = v.bounds;    layer.autoresizingMask = kCALayerWidthSizable | kCALayerHeightSizable;    [v.layer addSublayer:layer];    [layer setNeedsDisplay];    [w center];    [w makeKeyAndOrderFront:nil];    [NSApp activateIgnoringOtherApps:YES];    [NSApp run];  }  return 0;}

Three things to know before you ship it. CAOpenGLLayer calls you when Core Animation wants a frame, so a render loop that used to call flushBuffer on its own timer needs asynchronous = YES on the layer or an explicit setNeedsDisplay. If a toolkit creates the window and context for you — DJI Studio's Qt 6 build is among the affected apps — the fix belongs to the toolkit's maintainers, not to your code. And the forum reporter's other suggestion — render into an IOSurface-backed framebuffer and present it in a CALayer — has not been confirmed by anyone else (Apple Developer Forums).

The longer-term answer is the one Apple has given since 2018: move rendering to Metal, or to a translation layer such as ANGLE, as Godot's opengl3_angle driver does (Apple).

Sources and further reading

• Apple Developer Forums: NSOpenGLView / NSOpenGLContext setView: get no drawable on macOS 15.8.2 RC (FB25133383)
• kitty #10645: blank window on macOS 15.8.2 (24H219)
• Alacritty #9067: window always empty after 15.8.1 → 15.8.2
• Godot #124311: project manager blank on macOS
• OrcaSlicer #16382: 15.8.2 kills Prepare and Preview
• Bambu Studio #12530: panels missing on Sequoia 15.8.2
• 9to5Mac: first RCs for macOS Sequoia 15.8.2 and Tahoe 26.7.2
• 9to5Mac: second RCs for macOS Sequoia 15.8.2 and Tahoe 26.7.2
• Apple: OpenGL deprecation notice
• Hacker News discussion