Delve into the world of graphics and game development. Discuss creating stunning visuals, optimizing game mechanics, and share resources for game developers.

Posts under General subtopic

Post

Replies

Boosts

Views

Activity

GameSaveSyncedDirectory.openDirectory() crashes in CloudDocs initUIApplicationWillResignActiveNotification
We use the GameSave framework to sync player save data to iCloud. Since iOS 27, our game crashes a few seconds after a cold launch, the first time it calls GameSaveSyncedDirectory.openDirectory(). We call the API only from the main actor, but the crash is on a cooperative thread inside GameSave: EXC_BAD_ACCESS (SIGSEGV) KERN_INVALID_ADDRESS at 0x400000000000bad0 libobjc.A.dylib objc_release CloudDocs initUIApplicationWillResignActiveNotification CloudDocs -[BRQuery _setQueryState:] CloudDocs -[BRQuery _runQuery] CloudDocs -[BRQuery executeWithOptions:] Foundation -[NSMetadataQuery startQuery] GameSave BundleUpdatesWaiter.initMetadataQuery() GameSave BundleUpdatesWaiter.init(bundleURL:) GameSave closure #1 in GameSyncedDirectoryHolder.allowReaders(for:)Other threads are inside the same BRQuery path at the same moment. The crash reproduces without GameSave: starting twoNSMetadataQuery objects at once on background threads in a fresh process crashes 94 times in 100 in the iOS 27.0 Simulator, and never on iOS 26.5, so this seems like a regression. Starting one query on a single thread never crashes. I've submitted a support request (FB25352978) so hopefully this will be looked at fairly soon - if anyone else runs into this it would be good to know!
3
0
566
3d
CGSetDisplayTransferByTable is broken on macOS Tahoe 26.4 RC (and 26.3.1) with MacBook M5 Pro, Max and Neo
The CGSetDisplayTransferByTable() is not working on the latest round of Mac hardware, namely the MacBook Neo (external display), MacBook M5 Pro (both built-in and external display) and possibly the M5 Max. All tested apps (BetterDisplay, MonitorControl, f.lux, Lunar) exhibit the very issue both in macOS Tahoe 26.3 and macOS Tahoe 26.4 RC. Tested on multiple Macs and installations on the MacBook Neo and MacBook M5 Pro. This issue breaks several display related macOS apps. Way to reproduce the issue using an affected app: Install the app BetterDisplay (https://betterdisplay.pro) Launch the app, open the app menu, choose Image Adjustments and try to adjust colors. Adjustments take no effect Way to reproduce the issue programmatically: Attempt to use the affected macOS API feature: https://developer.apple.com/documentation/coregraphics/cgsetdisplaytransferbytable(::::_:) Here are the FB numbers: FB22273730 (Filed this one as a developer on an unaffected MBP M3 Max) FB22273782 (Filed from an affected MBP M5 Pro running 26.4 RC, with debug info attached)
18
7
8.1k
3d
EXC_BAD_ACCESS in SkyLight SLSWindowServerClientManagedDisplayGetCurrentSpace called from `-[NSScreen _notchFrame]` during display cycle (macOS 14.7.4, Intel MacBook Pro)
Our macOS app crashes intermittently on the main thread inside system frames only. No frame of our own code is in the crashed thread's stack. I would like to know whether others have seen this, and whether there is a known cause or workaround. Environment macOS 14.7.4 (23H420) MacBookPro16,1 (16-inch, 2019), Intel Core i7-9750H, dual GPU (Intel UHD Graphics 630 + AMD Radeon Pro 5300M, automatic graphics switching) Built-in display only, as far as we can tell. We have no record of an external display being connected. The same machine crashed 3 times in 7 days with this same crash signature. Crash Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x000000010a5f9008 Crashed Thread: 0 Dispatch queue: com.apple.main-thread Time Since Wake: 4798 seconds VM Region Info: 0x10a5f9008 is not in any region. CoreAnimation 10a5f8000-10a5f9000 [4K] rw-/rwx ---> GAP OF 0x2000 BYTES CoreAnimation 10a5fb000-10a5fd000 [8K] r--/r-- Thread 0 Crashed: 0 SkyLight SLSWindowServerClientManagedDisplayGetCurrentSpace + 181 1 AppKit -[NSScreen _notchFrame] + 85 2 AppKit _NSScreenFrameByAdjustingFrameForNotch + 55 3 AppKit -[NSScreen _layoutFrame] + 130 4 AppKit -[NSScreen visibleFrame] + 47 5 AppKit -[NSWindow(NSWindowResizing) _resizableEdgesForGrowing:shrinking:] + 589 6 AppKit -[NSWindow(NSWindowResizing) _getEdgeResizingRects:] + 37 7 AppKit -[NSWindow(NSWindow_Theme) _regionForOpaqueViewsModifiedForResizing:] + 53 8 AppKit -[NSWindow(NSWindow_Theme) _resetDragMargins] + 343 9 AppKit -[NSWindow(NSWindow_Theme) _resetDragMarginsIfNeeded] + 43 10 AppKit __NSWindowGetDisplayCycleObserverForUpdateStructuralRegions_block_invoke + 375 11 AppKit NSDisplayCycleObserverInvoke + 140 12 AppKit NSDisplayCycleFlush + 878 13 QuartzCore CA::Transaction::run_commit_handlers(CATransactionPhase) + 95 14 QuartzCore CA::Transaction::commit() + 377 15 AppKit -[_NSScrollingConcurrentMainThreadSynchronizer _synchronize:preCommitHandler:completionHandler:] + 336 ...What we know The faulting address is just past a mapped 4K CoreAnimation region, which suggests a stale pointer into a dynamically mapped region. Near the faulting instruction there is a loop that advances by 0x14 bytes per iteration, which might be a table walk. This is our reading of the disassembly only, not confirmed. About 1 second before the crash, our app closed a secondary window (a standalone chat window). This is the only UI action we see just before the crash, and it happened once, so we cannot say it is the trigger. The crash is not tied to a specific app feature, and it was not right after wake (about 80 minutes after the last wake). Separately, we see crashes on other Intel Macs inside SkyLight called from NSDisplayTiming, across macOS 13 to 26, with the same kind of "address outside any mapped region" fault. We believe they may share a root cause, but we have not proven it. Questions Has anyone seen _notchFrame / SLSWindowServerClientManagedDisplayGetCurrentSpace crashing like this, especially on a Mac with no physical notch? Is -[NSWindow _resetDragMargins] known to read screen geometry at a time when the display configuration or active space can change? Is there anything an app can do (for example, when and how it closes windows, or where it reads NSScreen.visibleFrame) to avoid this, or is this a system bug that should go to Feedback Assistant? I can share the full crash report if it helps. I'll also file a Feedback and post the FB number here.
1
0
496
5d
PHASE occluder silences direct sound instead of muffling it
I’m using PHASE for an outdoor soundscape with only .directPathTransmission enabled. A point source and listener are 2 metres apart. Between them is a PHASEOccluder built from a 2 × 2 × 0.02 metre MDLMesh box, with a .cardboard material assigned to every shape element. Without the occluder, the sound is loud. With it, the sound is completely inaudible. Switching to .glass and setting the sampler’s cullOption to .doNotCull makes no audible difference. This happens on both iOS Simulator and a physical iPhone. Adding .lateReverb produces faint audible sound, but room reverb is inappropriate for this outdoor scene and doesn’t establish whether direct transmission works. Is this expected attenuation, or is additional configuration required to hear muffled sound through an occluder? Is there a working sample demonstrating material-dependent transmission with reverb disabled?
3
1
2.0k
1w
Separate CGBitmapContexts drawn concurrently produce wrong pixels when another thread fills translucent shapes (FB25211753)
Hi, my first post :-) feel free to say hi! I’ve filed this as FB25211753 and am posting in case others hit it. When several threads each draw into their own CGBitmapContext (separate buffers, separate contexts), one context’s output is corrupted if another thread is filling translucent shapes at the same time. QA1238 says drawing to separate Quartz objects on separate threads is supported. With only identical renders running concurrently, 0 of 64 differ from a serial reference. With another thread filling translucent ellipses into an unrelated context, 32 of 32 differ. On macOS 27.0.1, each corrupted render has about 0.3–4.6% of its bytes wrong, by up to 219 of 255 levels. On 26.5.1 it was smaller: 0.2–0.5%, up to 55. It’s triggered by translucent ellipses or paths. Opaque fills and translucent rectangles don’t trigger it, and per-thread colour spaces don’t help. Thread Sanitizer reports no race in the test code. Configuration: MacBook Pro (M4 Pro), macOS 26.5.1 and 27.0.1, Xcode 26.4 / Swift 6.3. Minimal reproduction (Core Graphics only). Run with swiftc -O repro.swift -o repro && ./repro: // Separate CGBitmapContexts drawn on separate threads give wrong pixels while another thread fills translucent // shapes. Seen on macOS 26.5.1 and 27.0.1 (Apple M4 Pro). Core Graphics only. // Run: swiftc -O repro.swift -o repro && ./repro // Minimal repro: separate CGBitmapContexts on separate threads, Core Graphics only. import CoreGraphics import Foundation let sRGB = CGColorSpace(name: CGColorSpace.sRGB)! /// A fixed drawing: black, a few large translucent ellipses and a stroked circle. func victim() -> [UInt8] { let w = 600, h = 400 let ctx = CGContext(data: nil, width: w, height: h, bitsPerComponent: 8, bytesPerRow: w * 4, space: sRGB, bitmapInfo: CGImageAlphaInfo.premultipliedLast.rawValue)! ctx.setFillColor(CGColor(srgbRed: 0, green: 0, blue: 0, alpha: 1)) ctx.fill(CGRect(x: 0, y: 0, width: w, height: h)) for i in 0..<6 { ctx.setFillColor(CGColor(srgbRed: 1, green: Double(i) / 6, blue: 0.3, alpha: 0.5)) ctx.fillEllipse(in: CGRect(x: 40 + i * 80, y: 100, width: 120, height: 120)) } ctx.setStrokeColor(CGColor(srgbRed: 1, green: 1, blue: 1, alpha: 0.3)) ctx.strokeEllipse(in: CGRect(x: 100, y: 50, width: 400, height: 300)) let p = ctx.data!.assumingMemoryBound(to: UInt8.self) return Array(UnsafeBufferPointer(start: p, count: w * h * 4)) // read the context's own memory: no image decoding } /// Unrelated work on another context: many tiny translucent ellipses. func aggressor() { let ctx = CGContext(data: nil, width: 800, height: 500, bitsPerComponent: 8, bytesPerRow: 0, space: sRGB, bitmapInfo: CGImageAlphaInfo.premultipliedLast.rawValue)! for k in 0..<1600 { ctx.setFillColor(CGColor(srgbRed: 1, green: 1, blue: 1, alpha: Double(k % 7) / 7)) ctx.fillEllipse(in: CGRect(x: k % 800, y: k % 500, width: 1, height: 1)) } } let reference = victim() for mode in ["victims only", "victims + aggressors"] { let lock = NSLock() nonisolated(unsafe) var bad = 0, compared = 0 DispatchQueue.concurrentPerform(iterations: 64) { i in if mode != "victims only", i % 2 == 1 { aggressor(); return } let same = victim() == reference lock.lock(); compared += 1; if !same { bad += 1 }; lock.unlock() } print("\(mode): \(bad) of \(compared) renders differ from the serial reference") } Has anyone else seen this, or found a workaround other than drawing on a single thread?
4
0
1.7k
1w
NSOpenGLView / NSOpenGLContext setView: get no drawable on macOS 15.8.2 RC (24H219), windows render blank (FB25133383)
After updating a MacBook Pro (M1 Pro) from macOS 15.8 to the 15.8.2 release candidate (24H219), every OpenGL context that is attached to a window has no default framebuffer. NSOpenGLView and -[NSOpenGLContext setView:] are both affected, so anything drawn that way shows a blank window. I filed FB25133383 with a minimal sample, kernel log and call trace. Symptoms kCGLCPHasDrawable is 0, glCheckFramebufferStatus(GL_FRAMEBUFFER) returns GL_FRAMEBUFFER_UNDEFINED (0x8219), and glClear raises GL_INVALID_FRAMEBUFFER_OPERATION (0x506). For every attach attempt the kernel logs: (IOGPUFamily) IOGPUGLDrawableUserClient::set_surface(sIOGPUGLDrawableClientSetSurfaceData *): Invalid surface ID = N CGLSetSurface returns kCGLBadDrawable (10005). Stepping through it, CGSBindSurface succeeds and the IOGPU user-client call then fails with kIOReturnBadArgument. What still works Offscreen FBOs in the same context. CAOpenGLLayer and NSOpenGLLayer render correctly in the same process. Only the window-surface path is broken. Minimal sample (public API only) // clang -fobjc-arc -Wno-deprecated-declarations -framework Cocoa -framework OpenGL repro.m -o repro && ./repro #define GL_SILENCE_DEPRECATION 1 #import <Cocoa/Cocoa.h> #import <OpenGL/OpenGL.h> #import <OpenGL/gl.h> #import <OpenGL/glext.h> @interface ReproView : NSOpenGLView @end @implementation ReproView - (void)drawRect:(NSRect)dirtyRect { 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); fflush(stdout); [ctx flushBuffer]; } @end int main(void) { @autoreleasepool { NSApplication *app = [NSApplication sharedApplication]; [app setActivationPolicy:NSApplicationActivationPolicyRegular]; NSWindow *win = [[NSWindow alloc] initWithContentRect:NSMakeRect(200, 300, 240, 240) styleMask:NSWindowStyleMaskTitled | NSWindowStyleMaskClosable backing:NSBackingStoreBuffered defer:NO]; NSOpenGLPixelFormatAttribute attrs[] = { NSOpenGLPFADoubleBuffer, NSOpenGLPFAAccelerated, 0 }; NSOpenGLPixelFormat *pf = [[NSOpenGLPixelFormat alloc] initWithAttributes:attrs]; [win.contentView addSubview:[[ReproView alloc] initWithFrame:NSMakeRect(20, 20, 200, 200) pixelFormat:pf]]; [win makeKeyAndOrderFront:nil]; [app activateIgnoringOtherApps:YES]; dispatch_after(dispatch_time(DISPATCH_TIME_NOW, 5 * NSEC_PER_SEC), dispatch_get_main_queue(), ^{ [app terminate:nil]; }); [app run]; } return 0; } Expected: a green square and hasDrawable=1 status=0x8cd5 glError=0x0. On 24H219: nothing is drawn and it prints hasDrawable=0 status=0x8219 glError=0x506. Scope Same result for arm64 and x86_64 under Rosetta, layer-backed or not, main thread or background thread. Affected on my Mac: Sony Imaging Edge Desktop Viewer (NSOpenGLView), DJI Studio (Qt 6, NSOpenGLContext) and its Quick Look extension. Public reports with the same symptom on 24H219: kitty #10645, Alacritty #9067, Godot #124311, Bambu Studio #12530 (all on GitHub). They cover M1, M4, M4 Pro and M4 Max, and the Alacritty report says 15.8.1 was fine. Questions Is this a known issue in the 15.8.2 RC, and will it be fixed before 15.8.2 ships? Is anyone seeing it on the macOS 26.7.2 RC or the 27.2 beta? Workaround for developers in the meantime: render into an IOSurface-backed FBO and present that surface in a CALayer, or use CAOpenGLLayer.
8
4
22k
1w
macOS 27.2 RC (26B118) Built-in display canvas cropped with black bar at bottom-right after login
Description: MacBook Air M5, using only built-in display. The login window renders full screen normally. After logging into desktop session, the display canvas gets cropped with a black bar on the bottom-right corner. This issue is reproducible in Safe Mode and with a brand-new admin user account. No third-party display or window management software installed. Suspected WindowServer display coordinate calculation bug within user session. Environment Device: MacBook Air M5 OS: macOS 27.2 RC (26B118) Display: Built-in display only, no external monitor Reproduction steps Boot to login window, display works fine Log into desktop session Display canvas cropped, black bar appears at bottom-right
1
0
1k
1w
M5 Pro external display pipeline width limits and native HiDPI support
Hello Apple Engineering Team, I would like to clarify a technical question regarding the external display architecture of the M5 Pro MacBook Pro. I use a single ultrawide monitor with a native resolution of 3440 × 1440. To achieve true 2× HiDPI rendering at this logical resolution, macOS would need to render a framebuffer of 6880 × 2880. Third-party diagnostic tools and firmware reverse-engineering reports appear to indicate that M5 Pro has display-pipeline source-width limits of 6720 and 7680 pixels. Could you please clarify the following? Are these reported source-width limits accurate for the M5 Pro? Can macOS assign a single external display to the display pipeline that supports a 7680-pixel source width? Is there a supported way to influence or change this pipeline allocation, such as changing the connection port, connection order, or display configuration? Can a single 3440 × 1440 external monitor use native 2× HiDPI rendering (6880 × 2880) on the M5 Pro without virtual-display mirroring? If this configuration is unsupported, is the limitation imposed by hardware, firmware, or macOS display allocation policy? I understand that Apple may not disclose all internal implementation details. Any clarification regarding supported configurations or known limitations would be greatly appreciated. Thank you.
0
0
491
2w
Public API for system-wide SDR luminance control on built-in XDR?
I am investigating whether a macOS display utility can adjust the luminance of normal SDR desktop content system-wide, including other apps, on the built-in Liquid Retina XDR display of a 2021 M1 Max MacBook Pro. Is there a documented public API, or combination of public APIs, for this scope? The research target is SDR white around 1000 cd/m² while retaining HDR highlight capability, where supported by the hardware and OS. This is a feasibility question, not a claim that this output has been achieved or is supported. The approach must preserve OS color management and respect thermal, power and brightness limits, including protective dimming. I am not seeking gamma-table changes, screen capture and HDR re-display, private APIs, or bypasses of system protections. I understand that enabling EDR for an app's own layer is different from controlling ordinary SDR content in other apps. I am specifically asking about the latter. If this is supported, could you point to the API names, primary documentation, applicable macOS versions and hardware limitations? If it is not supported through public APIs, an explicit clarification would also be helpful.
2
0
1.3k
2w
Get Desktop background image
In a WWDC 2019 "Advances in macOS Security" at 18:40 there is the following code func getDesktopWindowIds() -> [CGWindowID] { let windows = CGWindowListCopyWindowInfo([.optionOnScreenOnly], kCGNullWindowID)! as! [[String: AnyObject]] let DesktopWindowLevel = CGWindowLevelForKey(.desktopWindow)-1 let DesktopWindows = windows.filter { let windowLevel = $0[kCGWindowLayer as String] as! CGWindowLevel return windowLevel == desktopWindowLevel } return desktopWindows.map { $0[kCGWindowNumber as String] as! CGWindowID } } to find the CGWindowID of the Desktop background. This works, but when you then try to get the CGImage for that CGWindowID with let cgImage = CGWindowListCreateImage(CGRectNull, [.optionIncludingWindow], cgWin, [.bestResolution]) cgImage does get a reference, however it's just a gray image. Not the Desktop picture. It's clear from the documentation that ScreenCaptureKit should be used. However, if used I get multiple warnings to the user, the most concerning one states: "App" would like to record this computer's screen and audio. This is not true! I do nothing with audio and to say a capture is a recording is also misleading. Is there way to achieve what use to work before macOS 27? Or a way to change/avoid this misleading warning? Is there a reason why this warning is needed for capturing the Desktop background where before it was explicitly allowed?
6
0
3.2k
3w
ScreenCaptureKit is NOT a full replacement for CGWindowListCreateImage
My sandbox app on MAS (Hide Icons) simply toggles the visibility of the Desktop icons and Widgets on or off. It does this by display customized NSWindow on window level given by NSWindow.Level(rawValue: Int(CGWindowLevelForKey(.desktopIconWindow))+1) This custom NSWindow can either have a copy of the Desktop background/wallpaper CGImage or a solid color depending on user preference. Until macOS 27, this worked fine. To find all the Desktop background/wallpaper images (there can be multiple screens and each screen can have multiple Spaces), Apple provided code that avoided any TCC dialog boxes. Namely func getDesktopWindowIds() -> [CGWindowID] { let windows = CGWindowListCopyWindowInfo([.optionAll], kCGNullWindowID)! as! [[String: AnyObject]] let DesktopWindowLevel = CGWindowLevelForKey(.desktopWindow)-1 let DesktopWindows = windows.filter { let windowLevel = $0[kCGWindowLayer as String] as! CGWindowLevel return windowLevel == desktopWindowLevel } return desktopWindows.map { $0[kCGWindowNumber as String] as! CGWindowID } } which returns [CGWindowID] of all the Desktop background/wallpaper windows. Then for any one, say cgID, a simple let cgImage = CGWindowListCreateImage(CGRectNull, [.optionIncludingWindow], cgID, [.bestResolution]) gave an CGImage which then can be applied to my custom NSWindow. No where is TCC triggered. All is great. I followed Apple's ideas about Security and Privacy since I'm only using the data I need (i.e. [CGWindowID]) and the data is only used during execution. Never saved or shared. macOS 27 beta 4 and beyond broke CGWindowListCreateImage(...). It compiles and when called it returns some gray image. Documentation tells me to use ScreenCaptureKit. The newest versions of ScreenCaptureKit introduce SCScreenshotManager.captureImage(contentFilter:, configuration) which can return a CGImage of the CGWindowID. Here is when the problem occurs. To capture that CGWindowID CGImage, one would use SCContentFilter(desktopIndependentWindow: desktopWindow) but to get desktopWindow you first need to find the SCWindow that corresponds to CGWindowID. You can grab a set of SCWindow with SCShareableContent.excludingDesktopWindows(false, onScreenWindowsOnly: false) But when any method of SCShareableContent is called, TCC throws up this warning I do not want this. Too many permissions are being granted. I only want the [CGWindowID] of the Desktop background/wallpaper. This, if the user grants, gives me much more which is bad for Security and Privacy. One way to avoid the TCC in ScreenCaptureKit is to use the new SCContentSharingPicker.shared. This allows the user to pick what they want to share. I first tried var pickerConfiguration = SCContentSharingPickerConfiguration() pickerConfiguration.allowedPickerModes = [.multipleWindows, .singleWindow] but the picker does not allow the user to select the Desktop background/wallpaper. Using var pickerConfiguration = SCContentSharingPickerConfiguration() pickerConfiguration.allowedPickerModes = [.singleDisplay] also doesn't give me Desktop background/wallpaper access. Trying to use [.singleApplication] and limiting the choices to WindowServer (what SCWindow claims is the owner) also doesn't allow picking of the Desktop background/wallpaper. So, is it true to get access to the Desktop background/wallpaper CGWindowID's CGImage, I must have the user give me full access via TCC? Please tell me of a work around. The obvious fix is on Apple's side. The corresponding list of [SCWindow] corresponding to [CGWindowID] should always be included in SCContentFilter.includedWindows. Or simply leave them out of the TCC domain as before.
2
0
561
3w
macOS 27 beta: ProMotion refresh cadence is unstable, causing constant scroll judder
FB24091347 On macOS 27.0 beta (26A5388g), MacBook Pro M4 Pro, the built-in ProMotion display never settles on a stable refresh cadence. Scrolling in SwiftUI judders constantly. The same app binary was smooth on macOS 26, and is smooth on a 120 Hz ProMotion iPad. I captured two 60-second Instruments traces — same app, same scene, same scrolling, no external display — changing only the display's refresh-rate setting. On ProMotion the vsync interval standard deviation is 4.093 ms across six different cadences, mostly flip-flopping between 120 Hz and 60 Hz. Forced to a fixed 60 Hz it drops to 0.391 ms with a single cadence. The app presented an identical 59 fps median in both runs — frame production is perfectly steady, the display just holds each frame for an unpredictable length of time. That's what makes this nasty: it's invisible to every frame-rate metric, so it looks like the app got slow when nothing about the app changed. I spent most of a day profiling my own code before realising the app was never the problem. Workaround: force the built-in display to 60 Hz. Worth noting, because it complicates the picture: attaching a 60 Hz Studio Display makes the built-in smooth, but the Studio itself then judders — despite its own vsync cadence measuring perfectly stable. So refresh rate alone isn't the whole story, and there may be a second mechanism. The clean, reproducible, single-variable result is the ProMotion vs forced-60 Hz comparison on the built-in panel. If you can reproduce this on an M-series MacBook Pro on 27 beta, please file a duplicate referencing FB24091347.
6
2
2.7k
Sep ’26
iMac gpuRestart and then crash
Hi all, This has been bothering me for quite a while. Basically my new iMac (bought for a few months only) started to crash randomly. I went to the genius bar and they couldn't do anything to identify the issue, I tried reinstalling the OS and even reinstalling an older version of Mac OS as well, but still seeing this issue. Today it happened twice and below are the details: Mac specs: Model Name: iMac  Model Identifier: iMac20,1  Processor Name: 10-Core Intel Core i9  Processor Speed: 3.6 GHz  Number of Processors: 1  Total Number of Cores: 10  L2 Cache (per Core): 256 KB  L3 Cache: 20 MB  Hyper-Threading Technology: Enabled  Memory: 16 GB  Boot ROM Version: 1554.100.64.0.0 (iBridge: 18.16.14556.0.0,0)  Serial Number (system): xxx  Hardware UUID: xxx  Activation Lock Status: Enabled The DiagnosticReports around the time it crashed has a lot of files with .gpuRestart, e.g.: Kernel_2021-04-27-213412_Zhuzengs-iMac.gpuRestart and file WindowServer_2021-04-27-213319_Zhuzengs-iMac.userspace_watchdog_timeout.spin in between. The details of the the first gpuRestart file Tue Apr 27 21:32:13 2021 Event: GPU Reset Date/Time: Tue Apr 27 21:32:13 2021 Application: Path: Tailspin: /Library/Logs/DiagnosticReports/gpuRestart2021-04-27-213213.tailspin GPUSubmission Trace ID: 0 OS Version: Mac OS X Version 10.15.7 (Build 19H1030) Graphics Hardware: AMD Radeon Pro 5300 Signature: 2 Report Data: GPU Log Version: 1 Restart Channel: 18 VMPT --THE STATE OF THE DRIVER AMDRadeonX6000_AMDNavi14GraphicsAccelerator state: ENABLED PCIe Device: [3:0:0], DID=0x7340, RID=0x47, SSID=0x219 TotalVideoRAMBytes: 0x00000000ff000000 (4278190080) Uptime 21:50:05.077572 [00] Channel: GFX, last reset at 0:00:00.000000 CompletedTS = 0x005be078, SubmittedTS = 0x005be079 SentTS = 0x005be078, sent at 21:49:00.896511, ScheduledTS = 0x005be079, submitted at 21:50:03.672539 Wait for Channel 18, TS 0xef924 PendingEvent: YES NumberOfPendingCB = 1, FirstPendingTS = 0x005be079, LastPendingTS = 0x005be079 FirstPendingCB: ProcessID = 225, ProcessName = WindowServer, SubmitContext = Unknown (0) GPUAddress = 0x0000000431cef000, Size = 0x000001d3, VMID = 2 ContentValidation = PASS Buffer range 0x0 .. 0x100:c0012800 80000000 80000000 c0026900 00000081 80000000 40004000 c0026900 By searching online this seems to be happening to others as well but I failed to find a common fix for this. Any help would be hugely appreciated!!!
3
1
1.8k
Sep ’26
Times New Roman superscript and Unicode fallback font
I was using Times New Roman and trying to use superscript numbers, but found out that Times New Roman only has superscript numbers 0, 1, 2, 3, ¹ (like so) and since I'm writing out transcriptions of pinyin, I also need superscript 4, 5, 6, 7. When I do that, the font changes to Lucida Grande automatically. I would like to change the default unicode font/alt font from Lucida Grande to EB Garamond (downloaded from Google) since it more closely resembles Times New Roman and unfortunately, I need to keep the font as close to Times New Roman as possible. Is there a way to change the default the computer chooses to when Times New Roman/alt font fails unicode? Alternatively, is there a font that looks exactly like Times New Roman that has the superscript numbers 0-9? 2022 laptop, M2, Tahoe 26.6.1 Move post at will if need be.
5
0
1.4k
Sep ’26
Core Animation Background Thread CATransaction
Hey everyone 👋 I'm trying to initialize a part of a CALayer hierarchy on a background thread and then attach the root of that hierarchy to a CALayer that backs a UIView. The motivation is to keep the main thread responsive when constructing a complex layer hierarchy. This isn't a case where I'm creating two or three layers and then switching back to the main thread. The hierarchy can potentially contain a large number of layers, with animations being created/configured for those layers as well. My first approach was to create and configure the layers entirely on a background thread. While the output might be the expected one (not always), CoreAnimation emits an assertion along the lines of: "Modifications to the layer tree from a background thread may not be committed" (or something like this). This makes sense to me if implicit CATransaction is thread-local. In that case, the implicit transaction opened by the layer modification on the background thread would not be part of the transaction that is already open on the main thread. Therefore, committing the main-thread transaction would not commit the changes made on the background thread. My second approach was to explicitly create and commit a CATransaction on the background thread. This appears to be accepted by Core Animation's threading model, but I'm seeing unreliable results. Sometimes parts of the hierarchy are missing, and in other cases the hierarchy is present but the animations don't appear to run at all. I do understand that this is private behavior of the framework, but I wanted to know if what I am trying to achieve is possible and, if so, what the solution would be (obviously if you can share this information). Besides this, I would also like to know what behavior CATransactions have when they are created on different threads. What I mean by this is that the transactions work as a stack, and the changes are committed when the stack is empty. Does this behavior still apply when having transactions on different threads? Any weird behaviours that might appear between transactions operated on main vs background threads? Thank you! Vlad.
7
0
1.1k
Sep ’26
Lockpicking - Steuerung
Hallo, mein Spiel Lockpicking ist exakt gleich programmiert für Android und Apple. Warum sehen die links rechts Tasten bei beiden Apps verschieden aus ? https://apps.apple.com/us/app/lockpicking/id6793054294
1
0
534
Aug ’26
GCKeyboard reports a phantom “Generic Keyboard” on iOS 27 beta 5
Update: Please disregard this report. The behavior was caused by enabling the hardware keyboard for the device in Xcode 27 beta 5’s Device Hub. This appears to expose a virtual “Generic Keyboard” to the connected physical device, causing GCKeyboardDidConnect to be posted even though no physical keyboard is attached directly to it. Simply disabling the hardware keyboard option was not sufficient. I needed to close Device Hub and restart Xcode for the virtual keyboard to be removed and the expected GCKeyboard behavior to resume. I’m seeing what appears to be a GameController regression on physical iPhone and iPad devices running iOS 27 beta 5. When my app launches with no Bluetooth, USB, or Smart Connector keyboard attached, GCKeyboard.coalesced is initially nil. Shortly afterward, the system posts .GCKeyboardDidConnect for a keyboard named “Generic Keyboard,” and GCKeyboard.coalesced becomes non-nil: === Initial state === GCKeyboard.coalesced: nil cannot add handler to 0 from 0 - dropping === GCKeyboardDidConnect #1 === notification.object: GCKeyboard: 0x10b01cd00 'Generic Keyboard'> GCKeyboard.coalesced: Optional( 0x10b01cd00>) The phantom keyboard then appears to remain connected indefinitely. After this happens: Attaching a real hardware keyboard does not post another .GCKeyboardDidConnect. Detaching the real keyboard does not post .GCKeyboardDidDisconnect. GCKeyboard.coalesced remains non-nil even though no hardware keyboard is attached. This may be interacting with the documented coalescing behavior: the connect notification is posted only for the first keyboard, and the disconnect notification only after the last keyboard disconnects. If the phantom “Generic Keyboard” remains present, a real keyboard is never considered the first or last keyboard. Minimal observer code: print("Initial GCKeyboard.coalesced:", GCKeyboard.coalesced as Any) NotificationCenter.default.addObserver( forName: .GCKeyboardDidConnect, object: nil, queue: .main ) { notification in print("GCKeyboardDidConnect") print("notification.object:", notification.object as Any) print("GCKeyboard.coalesced:", GCKeyboard.coalesced as Any) } NotificationCenter.default.addObserver( forName: .GCKeyboardDidDisconnect, object: nil, queue: .main ) { notification in print("GCKeyboardDidDisconnect") print("notification.object:", notification.object as Any) print("GCKeyboard.coalesced:", GCKeyboard.coalesced as Any) } I can reproduce this on both a physical iPhone and a physical iPad. This is not Simulator keyboard forwarding, and no keyboard is attached when the “Generic Keyboard” appears. Has anyone else observed this behavior on iOS 27 beta 5 or found another API that reliably reports whether a real hardware keyboard is attached? Filed as FB24269002.
0
0
388
Aug ’26
Draw WKWebView into OpenGL Texture
I'm trying to figure out how to display a Web Browser inside my iOS VR app (Obj-c, SceneKit and raw OpenGL), and the part i'm not fully understanding is how to get the WKWebView to draw it's content into a Pixel Buffer of some sort, so I can use the speed of CVOpenGLESTextureCacheCreateTextureFromImage to convert the pixel data into a OpenGl Texture quickly/efficently and display it on a floating surface.I'm already doing something simular with the video portion of my app, but it has a AVPlayerItemVideoOutput, which produced the pixel buffer, but I can't figure out how to massage the CALayer into a Buffer so I can convert it into a texture to then draw in opengl.I know it has something to do with drawLayer:(Layer) ,(Context), but searching online hasn't been very fruitful.And i'm not using SceneKit like you would assume, the app was built before GVR for Scenekit was a thing, so every part of VR is handled manually (scenekit to textures, textures to opengl for Left/Right eye distortion mesh).
3
0
3.1k
Jul ’26
GameSaveSyncedDirectory.openDirectory() crashes in CloudDocs initUIApplicationWillResignActiveNotification
We use the GameSave framework to sync player save data to iCloud. Since iOS 27, our game crashes a few seconds after a cold launch, the first time it calls GameSaveSyncedDirectory.openDirectory(). We call the API only from the main actor, but the crash is on a cooperative thread inside GameSave: EXC_BAD_ACCESS (SIGSEGV) KERN_INVALID_ADDRESS at 0x400000000000bad0 libobjc.A.dylib objc_release CloudDocs initUIApplicationWillResignActiveNotification CloudDocs -[BRQuery _setQueryState:] CloudDocs -[BRQuery _runQuery] CloudDocs -[BRQuery executeWithOptions:] Foundation -[NSMetadataQuery startQuery] GameSave BundleUpdatesWaiter.initMetadataQuery() GameSave BundleUpdatesWaiter.init(bundleURL:) GameSave closure #1 in GameSyncedDirectoryHolder.allowReaders(for:)Other threads are inside the same BRQuery path at the same moment. The crash reproduces without GameSave: starting twoNSMetadataQuery objects at once on background threads in a fresh process crashes 94 times in 100 in the iOS 27.0 Simulator, and never on iOS 26.5, so this seems like a regression. Starting one query on a single thread never crashes. I've submitted a support request (FB25352978) so hopefully this will be looked at fairly soon - if anyone else runs into this it would be good to know!
Replies
3
Boosts
0
Views
566
Activity
3d
CGSetDisplayTransferByTable is broken on macOS Tahoe 26.4 RC (and 26.3.1) with MacBook M5 Pro, Max and Neo
The CGSetDisplayTransferByTable() is not working on the latest round of Mac hardware, namely the MacBook Neo (external display), MacBook M5 Pro (both built-in and external display) and possibly the M5 Max. All tested apps (BetterDisplay, MonitorControl, f.lux, Lunar) exhibit the very issue both in macOS Tahoe 26.3 and macOS Tahoe 26.4 RC. Tested on multiple Macs and installations on the MacBook Neo and MacBook M5 Pro. This issue breaks several display related macOS apps. Way to reproduce the issue using an affected app: Install the app BetterDisplay (https://betterdisplay.pro) Launch the app, open the app menu, choose Image Adjustments and try to adjust colors. Adjustments take no effect Way to reproduce the issue programmatically: Attempt to use the affected macOS API feature: https://developer.apple.com/documentation/coregraphics/cgsetdisplaytransferbytable(::::_:) Here are the FB numbers: FB22273730 (Filed this one as a developer on an unaffected MBP M3 Max) FB22273782 (Filed from an affected MBP M5 Pro running 26.4 RC, with debug info attached)
Replies
18
Boosts
7
Views
8.1k
Activity
3d
EXC_BAD_ACCESS in SkyLight SLSWindowServerClientManagedDisplayGetCurrentSpace called from `-[NSScreen _notchFrame]` during display cycle (macOS 14.7.4, Intel MacBook Pro)
Our macOS app crashes intermittently on the main thread inside system frames only. No frame of our own code is in the crashed thread's stack. I would like to know whether others have seen this, and whether there is a known cause or workaround. Environment macOS 14.7.4 (23H420) MacBookPro16,1 (16-inch, 2019), Intel Core i7-9750H, dual GPU (Intel UHD Graphics 630 + AMD Radeon Pro 5300M, automatic graphics switching) Built-in display only, as far as we can tell. We have no record of an external display being connected. The same machine crashed 3 times in 7 days with this same crash signature. Crash Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x000000010a5f9008 Crashed Thread: 0 Dispatch queue: com.apple.main-thread Time Since Wake: 4798 seconds VM Region Info: 0x10a5f9008 is not in any region. CoreAnimation 10a5f8000-10a5f9000 [4K] rw-/rwx ---> GAP OF 0x2000 BYTES CoreAnimation 10a5fb000-10a5fd000 [8K] r--/r-- Thread 0 Crashed: 0 SkyLight SLSWindowServerClientManagedDisplayGetCurrentSpace + 181 1 AppKit -[NSScreen _notchFrame] + 85 2 AppKit _NSScreenFrameByAdjustingFrameForNotch + 55 3 AppKit -[NSScreen _layoutFrame] + 130 4 AppKit -[NSScreen visibleFrame] + 47 5 AppKit -[NSWindow(NSWindowResizing) _resizableEdgesForGrowing:shrinking:] + 589 6 AppKit -[NSWindow(NSWindowResizing) _getEdgeResizingRects:] + 37 7 AppKit -[NSWindow(NSWindow_Theme) _regionForOpaqueViewsModifiedForResizing:] + 53 8 AppKit -[NSWindow(NSWindow_Theme) _resetDragMargins] + 343 9 AppKit -[NSWindow(NSWindow_Theme) _resetDragMarginsIfNeeded] + 43 10 AppKit __NSWindowGetDisplayCycleObserverForUpdateStructuralRegions_block_invoke + 375 11 AppKit NSDisplayCycleObserverInvoke + 140 12 AppKit NSDisplayCycleFlush + 878 13 QuartzCore CA::Transaction::run_commit_handlers(CATransactionPhase) + 95 14 QuartzCore CA::Transaction::commit() + 377 15 AppKit -[_NSScrollingConcurrentMainThreadSynchronizer _synchronize:preCommitHandler:completionHandler:] + 336 ...What we know The faulting address is just past a mapped 4K CoreAnimation region, which suggests a stale pointer into a dynamically mapped region. Near the faulting instruction there is a loop that advances by 0x14 bytes per iteration, which might be a table walk. This is our reading of the disassembly only, not confirmed. About 1 second before the crash, our app closed a secondary window (a standalone chat window). This is the only UI action we see just before the crash, and it happened once, so we cannot say it is the trigger. The crash is not tied to a specific app feature, and it was not right after wake (about 80 minutes after the last wake). Separately, we see crashes on other Intel Macs inside SkyLight called from NSDisplayTiming, across macOS 13 to 26, with the same kind of "address outside any mapped region" fault. We believe they may share a root cause, but we have not proven it. Questions Has anyone seen _notchFrame / SLSWindowServerClientManagedDisplayGetCurrentSpace crashing like this, especially on a Mac with no physical notch? Is -[NSWindow _resetDragMargins] known to read screen geometry at a time when the display configuration or active space can change? Is there anything an app can do (for example, when and how it closes windows, or where it reads NSScreen.visibleFrame) to avoid this, or is this a system bug that should go to Feedback Assistant? I can share the full crash report if it helps. I'll also file a Feedback and post the FB number here.
Replies
1
Boosts
0
Views
496
Activity
5d
PHASE occluder silences direct sound instead of muffling it
I’m using PHASE for an outdoor soundscape with only .directPathTransmission enabled. A point source and listener are 2 metres apart. Between them is a PHASEOccluder built from a 2 × 2 × 0.02 metre MDLMesh box, with a .cardboard material assigned to every shape element. Without the occluder, the sound is loud. With it, the sound is completely inaudible. Switching to .glass and setting the sampler’s cullOption to .doNotCull makes no audible difference. This happens on both iOS Simulator and a physical iPhone. Adding .lateReverb produces faint audible sound, but room reverb is inappropriate for this outdoor scene and doesn’t establish whether direct transmission works. Is this expected attenuation, or is additional configuration required to hear muffled sound through an occluder? Is there a working sample demonstrating material-dependent transmission with reverb disabled?
Replies
3
Boosts
1
Views
2.0k
Activity
1w
Separate CGBitmapContexts drawn concurrently produce wrong pixels when another thread fills translucent shapes (FB25211753)
Hi, my first post :-) feel free to say hi! I’ve filed this as FB25211753 and am posting in case others hit it. When several threads each draw into their own CGBitmapContext (separate buffers, separate contexts), one context’s output is corrupted if another thread is filling translucent shapes at the same time. QA1238 says drawing to separate Quartz objects on separate threads is supported. With only identical renders running concurrently, 0 of 64 differ from a serial reference. With another thread filling translucent ellipses into an unrelated context, 32 of 32 differ. On macOS 27.0.1, each corrupted render has about 0.3–4.6% of its bytes wrong, by up to 219 of 255 levels. On 26.5.1 it was smaller: 0.2–0.5%, up to 55. It’s triggered by translucent ellipses or paths. Opaque fills and translucent rectangles don’t trigger it, and per-thread colour spaces don’t help. Thread Sanitizer reports no race in the test code. Configuration: MacBook Pro (M4 Pro), macOS 26.5.1 and 27.0.1, Xcode 26.4 / Swift 6.3. Minimal reproduction (Core Graphics only). Run with swiftc -O repro.swift -o repro && ./repro: // Separate CGBitmapContexts drawn on separate threads give wrong pixels while another thread fills translucent // shapes. Seen on macOS 26.5.1 and 27.0.1 (Apple M4 Pro). Core Graphics only. // Run: swiftc -O repro.swift -o repro && ./repro // Minimal repro: separate CGBitmapContexts on separate threads, Core Graphics only. import CoreGraphics import Foundation let sRGB = CGColorSpace(name: CGColorSpace.sRGB)! /// A fixed drawing: black, a few large translucent ellipses and a stroked circle. func victim() -> [UInt8] { let w = 600, h = 400 let ctx = CGContext(data: nil, width: w, height: h, bitsPerComponent: 8, bytesPerRow: w * 4, space: sRGB, bitmapInfo: CGImageAlphaInfo.premultipliedLast.rawValue)! ctx.setFillColor(CGColor(srgbRed: 0, green: 0, blue: 0, alpha: 1)) ctx.fill(CGRect(x: 0, y: 0, width: w, height: h)) for i in 0..<6 { ctx.setFillColor(CGColor(srgbRed: 1, green: Double(i) / 6, blue: 0.3, alpha: 0.5)) ctx.fillEllipse(in: CGRect(x: 40 + i * 80, y: 100, width: 120, height: 120)) } ctx.setStrokeColor(CGColor(srgbRed: 1, green: 1, blue: 1, alpha: 0.3)) ctx.strokeEllipse(in: CGRect(x: 100, y: 50, width: 400, height: 300)) let p = ctx.data!.assumingMemoryBound(to: UInt8.self) return Array(UnsafeBufferPointer(start: p, count: w * h * 4)) // read the context's own memory: no image decoding } /// Unrelated work on another context: many tiny translucent ellipses. func aggressor() { let ctx = CGContext(data: nil, width: 800, height: 500, bitsPerComponent: 8, bytesPerRow: 0, space: sRGB, bitmapInfo: CGImageAlphaInfo.premultipliedLast.rawValue)! for k in 0..<1600 { ctx.setFillColor(CGColor(srgbRed: 1, green: 1, blue: 1, alpha: Double(k % 7) / 7)) ctx.fillEllipse(in: CGRect(x: k % 800, y: k % 500, width: 1, height: 1)) } } let reference = victim() for mode in ["victims only", "victims + aggressors"] { let lock = NSLock() nonisolated(unsafe) var bad = 0, compared = 0 DispatchQueue.concurrentPerform(iterations: 64) { i in if mode != "victims only", i % 2 == 1 { aggressor(); return } let same = victim() == reference lock.lock(); compared += 1; if !same { bad += 1 }; lock.unlock() } print("\(mode): \(bad) of \(compared) renders differ from the serial reference") } Has anyone else seen this, or found a workaround other than drawing on a single thread?
Replies
4
Boosts
0
Views
1.7k
Activity
1w
NSOpenGLView / NSOpenGLContext setView: get no drawable on macOS 15.8.2 RC (24H219), windows render blank (FB25133383)
After updating a MacBook Pro (M1 Pro) from macOS 15.8 to the 15.8.2 release candidate (24H219), every OpenGL context that is attached to a window has no default framebuffer. NSOpenGLView and -[NSOpenGLContext setView:] are both affected, so anything drawn that way shows a blank window. I filed FB25133383 with a minimal sample, kernel log and call trace. Symptoms kCGLCPHasDrawable is 0, glCheckFramebufferStatus(GL_FRAMEBUFFER) returns GL_FRAMEBUFFER_UNDEFINED (0x8219), and glClear raises GL_INVALID_FRAMEBUFFER_OPERATION (0x506). For every attach attempt the kernel logs: (IOGPUFamily) IOGPUGLDrawableUserClient::set_surface(sIOGPUGLDrawableClientSetSurfaceData *): Invalid surface ID = N CGLSetSurface returns kCGLBadDrawable (10005). Stepping through it, CGSBindSurface succeeds and the IOGPU user-client call then fails with kIOReturnBadArgument. What still works Offscreen FBOs in the same context. CAOpenGLLayer and NSOpenGLLayer render correctly in the same process. Only the window-surface path is broken. Minimal sample (public API only) // clang -fobjc-arc -Wno-deprecated-declarations -framework Cocoa -framework OpenGL repro.m -o repro && ./repro #define GL_SILENCE_DEPRECATION 1 #import <Cocoa/Cocoa.h> #import <OpenGL/OpenGL.h> #import <OpenGL/gl.h> #import <OpenGL/glext.h> @interface ReproView : NSOpenGLView @end @implementation ReproView - (void)drawRect:(NSRect)dirtyRect { 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); fflush(stdout); [ctx flushBuffer]; } @end int main(void) { @autoreleasepool { NSApplication *app = [NSApplication sharedApplication]; [app setActivationPolicy:NSApplicationActivationPolicyRegular]; NSWindow *win = [[NSWindow alloc] initWithContentRect:NSMakeRect(200, 300, 240, 240) styleMask:NSWindowStyleMaskTitled | NSWindowStyleMaskClosable backing:NSBackingStoreBuffered defer:NO]; NSOpenGLPixelFormatAttribute attrs[] = { NSOpenGLPFADoubleBuffer, NSOpenGLPFAAccelerated, 0 }; NSOpenGLPixelFormat *pf = [[NSOpenGLPixelFormat alloc] initWithAttributes:attrs]; [win.contentView addSubview:[[ReproView alloc] initWithFrame:NSMakeRect(20, 20, 200, 200) pixelFormat:pf]]; [win makeKeyAndOrderFront:nil]; [app activateIgnoringOtherApps:YES]; dispatch_after(dispatch_time(DISPATCH_TIME_NOW, 5 * NSEC_PER_SEC), dispatch_get_main_queue(), ^{ [app terminate:nil]; }); [app run]; } return 0; } Expected: a green square and hasDrawable=1 status=0x8cd5 glError=0x0. On 24H219: nothing is drawn and it prints hasDrawable=0 status=0x8219 glError=0x506. Scope Same result for arm64 and x86_64 under Rosetta, layer-backed or not, main thread or background thread. Affected on my Mac: Sony Imaging Edge Desktop Viewer (NSOpenGLView), DJI Studio (Qt 6, NSOpenGLContext) and its Quick Look extension. Public reports with the same symptom on 24H219: kitty #10645, Alacritty #9067, Godot #124311, Bambu Studio #12530 (all on GitHub). They cover M1, M4, M4 Pro and M4 Max, and the Alacritty report says 15.8.1 was fine. Questions Is this a known issue in the 15.8.2 RC, and will it be fixed before 15.8.2 ships? Is anyone seeing it on the macOS 26.7.2 RC or the 27.2 beta? Workaround for developers in the meantime: render into an IOSurface-backed FBO and present that surface in a CALayer, or use CAOpenGLLayer.
Replies
8
Boosts
4
Views
22k
Activity
1w
macOS 27.2 RC (26B118) Built-in display canvas cropped with black bar at bottom-right after login
Description: MacBook Air M5, using only built-in display. The login window renders full screen normally. After logging into desktop session, the display canvas gets cropped with a black bar on the bottom-right corner. This issue is reproducible in Safe Mode and with a brand-new admin user account. No third-party display or window management software installed. Suspected WindowServer display coordinate calculation bug within user session. Environment Device: MacBook Air M5 OS: macOS 27.2 RC (26B118) Display: Built-in display only, no external monitor Reproduction steps Boot to login window, display works fine Log into desktop session Display canvas cropped, black bar appears at bottom-right
Replies
1
Boosts
0
Views
1k
Activity
1w
M5 Pro external display pipeline width limits and native HiDPI support
Hello Apple Engineering Team, I would like to clarify a technical question regarding the external display architecture of the M5 Pro MacBook Pro. I use a single ultrawide monitor with a native resolution of 3440 × 1440. To achieve true 2× HiDPI rendering at this logical resolution, macOS would need to render a framebuffer of 6880 × 2880. Third-party diagnostic tools and firmware reverse-engineering reports appear to indicate that M5 Pro has display-pipeline source-width limits of 6720 and 7680 pixels. Could you please clarify the following? Are these reported source-width limits accurate for the M5 Pro? Can macOS assign a single external display to the display pipeline that supports a 7680-pixel source width? Is there a supported way to influence or change this pipeline allocation, such as changing the connection port, connection order, or display configuration? Can a single 3440 × 1440 external monitor use native 2× HiDPI rendering (6880 × 2880) on the M5 Pro without virtual-display mirroring? If this configuration is unsupported, is the limitation imposed by hardware, firmware, or macOS display allocation policy? I understand that Apple may not disclose all internal implementation details. Any clarification regarding supported configurations or known limitations would be greatly appreciated. Thank you.
Replies
0
Boosts
0
Views
491
Activity
2w
Public API for system-wide SDR luminance control on built-in XDR?
I am investigating whether a macOS display utility can adjust the luminance of normal SDR desktop content system-wide, including other apps, on the built-in Liquid Retina XDR display of a 2021 M1 Max MacBook Pro. Is there a documented public API, or combination of public APIs, for this scope? The research target is SDR white around 1000 cd/m² while retaining HDR highlight capability, where supported by the hardware and OS. This is a feasibility question, not a claim that this output has been achieved or is supported. The approach must preserve OS color management and respect thermal, power and brightness limits, including protective dimming. I am not seeking gamma-table changes, screen capture and HDR re-display, private APIs, or bypasses of system protections. I understand that enabling EDR for an app's own layer is different from controlling ordinary SDR content in other apps. I am specifically asking about the latter. If this is supported, could you point to the API names, primary documentation, applicable macOS versions and hardware limitations? If it is not supported through public APIs, an explicit clarification would also be helpful.
Replies
2
Boosts
0
Views
1.3k
Activity
2w
Get Desktop background image
In a WWDC 2019 "Advances in macOS Security" at 18:40 there is the following code func getDesktopWindowIds() -> [CGWindowID] { let windows = CGWindowListCopyWindowInfo([.optionOnScreenOnly], kCGNullWindowID)! as! [[String: AnyObject]] let DesktopWindowLevel = CGWindowLevelForKey(.desktopWindow)-1 let DesktopWindows = windows.filter { let windowLevel = $0[kCGWindowLayer as String] as! CGWindowLevel return windowLevel == desktopWindowLevel } return desktopWindows.map { $0[kCGWindowNumber as String] as! CGWindowID } } to find the CGWindowID of the Desktop background. This works, but when you then try to get the CGImage for that CGWindowID with let cgImage = CGWindowListCreateImage(CGRectNull, [.optionIncludingWindow], cgWin, [.bestResolution]) cgImage does get a reference, however it's just a gray image. Not the Desktop picture. It's clear from the documentation that ScreenCaptureKit should be used. However, if used I get multiple warnings to the user, the most concerning one states: "App" would like to record this computer's screen and audio. This is not true! I do nothing with audio and to say a capture is a recording is also misleading. Is there way to achieve what use to work before macOS 27? Or a way to change/avoid this misleading warning? Is there a reason why this warning is needed for capturing the Desktop background where before it was explicitly allowed?
Replies
6
Boosts
0
Views
3.2k
Activity
3w
ScreenCaptureKit is NOT a full replacement for CGWindowListCreateImage
My sandbox app on MAS (Hide Icons) simply toggles the visibility of the Desktop icons and Widgets on or off. It does this by display customized NSWindow on window level given by NSWindow.Level(rawValue: Int(CGWindowLevelForKey(.desktopIconWindow))+1) This custom NSWindow can either have a copy of the Desktop background/wallpaper CGImage or a solid color depending on user preference. Until macOS 27, this worked fine. To find all the Desktop background/wallpaper images (there can be multiple screens and each screen can have multiple Spaces), Apple provided code that avoided any TCC dialog boxes. Namely func getDesktopWindowIds() -> [CGWindowID] { let windows = CGWindowListCopyWindowInfo([.optionAll], kCGNullWindowID)! as! [[String: AnyObject]] let DesktopWindowLevel = CGWindowLevelForKey(.desktopWindow)-1 let DesktopWindows = windows.filter { let windowLevel = $0[kCGWindowLayer as String] as! CGWindowLevel return windowLevel == desktopWindowLevel } return desktopWindows.map { $0[kCGWindowNumber as String] as! CGWindowID } } which returns [CGWindowID] of all the Desktop background/wallpaper windows. Then for any one, say cgID, a simple let cgImage = CGWindowListCreateImage(CGRectNull, [.optionIncludingWindow], cgID, [.bestResolution]) gave an CGImage which then can be applied to my custom NSWindow. No where is TCC triggered. All is great. I followed Apple's ideas about Security and Privacy since I'm only using the data I need (i.e. [CGWindowID]) and the data is only used during execution. Never saved or shared. macOS 27 beta 4 and beyond broke CGWindowListCreateImage(...). It compiles and when called it returns some gray image. Documentation tells me to use ScreenCaptureKit. The newest versions of ScreenCaptureKit introduce SCScreenshotManager.captureImage(contentFilter:, configuration) which can return a CGImage of the CGWindowID. Here is when the problem occurs. To capture that CGWindowID CGImage, one would use SCContentFilter(desktopIndependentWindow: desktopWindow) but to get desktopWindow you first need to find the SCWindow that corresponds to CGWindowID. You can grab a set of SCWindow with SCShareableContent.excludingDesktopWindows(false, onScreenWindowsOnly: false) But when any method of SCShareableContent is called, TCC throws up this warning I do not want this. Too many permissions are being granted. I only want the [CGWindowID] of the Desktop background/wallpaper. This, if the user grants, gives me much more which is bad for Security and Privacy. One way to avoid the TCC in ScreenCaptureKit is to use the new SCContentSharingPicker.shared. This allows the user to pick what they want to share. I first tried var pickerConfiguration = SCContentSharingPickerConfiguration() pickerConfiguration.allowedPickerModes = [.multipleWindows, .singleWindow] but the picker does not allow the user to select the Desktop background/wallpaper. Using var pickerConfiguration = SCContentSharingPickerConfiguration() pickerConfiguration.allowedPickerModes = [.singleDisplay] also doesn't give me Desktop background/wallpaper access. Trying to use [.singleApplication] and limiting the choices to WindowServer (what SCWindow claims is the owner) also doesn't allow picking of the Desktop background/wallpaper. So, is it true to get access to the Desktop background/wallpaper CGWindowID's CGImage, I must have the user give me full access via TCC? Please tell me of a work around. The obvious fix is on Apple's side. The corresponding list of [SCWindow] corresponding to [CGWindowID] should always be included in SCContentFilter.includedWindows. Or simply leave them out of the TCC domain as before.
Replies
2
Boosts
0
Views
561
Activity
3w
macOS 27 beta: ProMotion refresh cadence is unstable, causing constant scroll judder
FB24091347 On macOS 27.0 beta (26A5388g), MacBook Pro M4 Pro, the built-in ProMotion display never settles on a stable refresh cadence. Scrolling in SwiftUI judders constantly. The same app binary was smooth on macOS 26, and is smooth on a 120 Hz ProMotion iPad. I captured two 60-second Instruments traces — same app, same scene, same scrolling, no external display — changing only the display's refresh-rate setting. On ProMotion the vsync interval standard deviation is 4.093 ms across six different cadences, mostly flip-flopping between 120 Hz and 60 Hz. Forced to a fixed 60 Hz it drops to 0.391 ms with a single cadence. The app presented an identical 59 fps median in both runs — frame production is perfectly steady, the display just holds each frame for an unpredictable length of time. That's what makes this nasty: it's invisible to every frame-rate metric, so it looks like the app got slow when nothing about the app changed. I spent most of a day profiling my own code before realising the app was never the problem. Workaround: force the built-in display to 60 Hz. Worth noting, because it complicates the picture: attaching a 60 Hz Studio Display makes the built-in smooth, but the Studio itself then judders — despite its own vsync cadence measuring perfectly stable. So refresh rate alone isn't the whole story, and there may be a second mechanism. The clean, reproducible, single-variable result is the ProMotion vs forced-60 Hz comparison on the built-in panel. If you can reproduce this on an M-series MacBook Pro on 27 beta, please file a duplicate referencing FB24091347.
Replies
6
Boosts
2
Views
2.7k
Activity
Sep ’26
Game
In duo because of this design, most games like Call of Duty or Minecraft didn’t support this
Replies
0
Boosts
0
Views
702
Activity
Sep ’26
iMac gpuRestart and then crash
Hi all, This has been bothering me for quite a while. Basically my new iMac (bought for a few months only) started to crash randomly. I went to the genius bar and they couldn't do anything to identify the issue, I tried reinstalling the OS and even reinstalling an older version of Mac OS as well, but still seeing this issue. Today it happened twice and below are the details: Mac specs: Model Name: iMac  Model Identifier: iMac20,1  Processor Name: 10-Core Intel Core i9  Processor Speed: 3.6 GHz  Number of Processors: 1  Total Number of Cores: 10  L2 Cache (per Core): 256 KB  L3 Cache: 20 MB  Hyper-Threading Technology: Enabled  Memory: 16 GB  Boot ROM Version: 1554.100.64.0.0 (iBridge: 18.16.14556.0.0,0)  Serial Number (system): xxx  Hardware UUID: xxx  Activation Lock Status: Enabled The DiagnosticReports around the time it crashed has a lot of files with .gpuRestart, e.g.: Kernel_2021-04-27-213412_Zhuzengs-iMac.gpuRestart and file WindowServer_2021-04-27-213319_Zhuzengs-iMac.userspace_watchdog_timeout.spin in between. The details of the the first gpuRestart file Tue Apr 27 21:32:13 2021 Event: GPU Reset Date/Time: Tue Apr 27 21:32:13 2021 Application: Path: Tailspin: /Library/Logs/DiagnosticReports/gpuRestart2021-04-27-213213.tailspin GPUSubmission Trace ID: 0 OS Version: Mac OS X Version 10.15.7 (Build 19H1030) Graphics Hardware: AMD Radeon Pro 5300 Signature: 2 Report Data: GPU Log Version: 1 Restart Channel: 18 VMPT --THE STATE OF THE DRIVER AMDRadeonX6000_AMDNavi14GraphicsAccelerator state: ENABLED PCIe Device: [3:0:0], DID=0x7340, RID=0x47, SSID=0x219 TotalVideoRAMBytes: 0x00000000ff000000 (4278190080) Uptime 21:50:05.077572 [00] Channel: GFX, last reset at 0:00:00.000000 CompletedTS = 0x005be078, SubmittedTS = 0x005be079 SentTS = 0x005be078, sent at 21:49:00.896511, ScheduledTS = 0x005be079, submitted at 21:50:03.672539 Wait for Channel 18, TS 0xef924 PendingEvent: YES NumberOfPendingCB = 1, FirstPendingTS = 0x005be079, LastPendingTS = 0x005be079 FirstPendingCB: ProcessID = 225, ProcessName = WindowServer, SubmitContext = Unknown (0) GPUAddress = 0x0000000431cef000, Size = 0x000001d3, VMID = 2 ContentValidation = PASS Buffer range 0x0 .. 0x100:c0012800 80000000 80000000 c0026900 00000081 80000000 40004000 c0026900 By searching online this seems to be happening to others as well but I failed to find a common fix for this. Any help would be hugely appreciated!!!
Replies
3
Boosts
1
Views
1.8k
Activity
Sep ’26
Times New Roman superscript and Unicode fallback font
I was using Times New Roman and trying to use superscript numbers, but found out that Times New Roman only has superscript numbers 0, 1, 2, 3, ¹ (like so) and since I'm writing out transcriptions of pinyin, I also need superscript 4, 5, 6, 7. When I do that, the font changes to Lucida Grande automatically. I would like to change the default unicode font/alt font from Lucida Grande to EB Garamond (downloaded from Google) since it more closely resembles Times New Roman and unfortunately, I need to keep the font as close to Times New Roman as possible. Is there a way to change the default the computer chooses to when Times New Roman/alt font fails unicode? Alternatively, is there a font that looks exactly like Times New Roman that has the superscript numbers 0-9? 2022 laptop, M2, Tahoe 26.6.1 Move post at will if need be.
Replies
5
Boosts
0
Views
1.4k
Activity
Sep ’26
Efootball mobile
Tengo un iphone 13, estoy con ios 27 ultima beta reciente y juego efootball mobile pero anda horrible. Anda muy pesado.
Replies
0
Boosts
0
Views
1.1k
Activity
Sep ’26
Core Animation Background Thread CATransaction
Hey everyone 👋 I'm trying to initialize a part of a CALayer hierarchy on a background thread and then attach the root of that hierarchy to a CALayer that backs a UIView. The motivation is to keep the main thread responsive when constructing a complex layer hierarchy. This isn't a case where I'm creating two or three layers and then switching back to the main thread. The hierarchy can potentially contain a large number of layers, with animations being created/configured for those layers as well. My first approach was to create and configure the layers entirely on a background thread. While the output might be the expected one (not always), CoreAnimation emits an assertion along the lines of: "Modifications to the layer tree from a background thread may not be committed" (or something like this). This makes sense to me if implicit CATransaction is thread-local. In that case, the implicit transaction opened by the layer modification on the background thread would not be part of the transaction that is already open on the main thread. Therefore, committing the main-thread transaction would not commit the changes made on the background thread. My second approach was to explicitly create and commit a CATransaction on the background thread. This appears to be accepted by Core Animation's threading model, but I'm seeing unreliable results. Sometimes parts of the hierarchy are missing, and in other cases the hierarchy is present but the animations don't appear to run at all. I do understand that this is private behavior of the framework, but I wanted to know if what I am trying to achieve is possible and, if so, what the solution would be (obviously if you can share this information). Besides this, I would also like to know what behavior CATransactions have when they are created on different threads. What I mean by this is that the transactions work as a stack, and the changes are committed when the stack is empty. Does this behavior still apply when having transactions on different threads? Any weird behaviours that might appear between transactions operated on main vs background threads? Thank you! Vlad.
Replies
7
Boosts
0
Views
1.1k
Activity
Sep ’26
Lockpicking - Steuerung
Hallo, mein Spiel Lockpicking ist exakt gleich programmiert für Android und Apple. Warum sehen die links rechts Tasten bei beiden Apps verschieden aus ? https://apps.apple.com/us/app/lockpicking/id6793054294
Replies
1
Boosts
0
Views
534
Activity
Aug ’26
GCKeyboard reports a phantom “Generic Keyboard” on iOS 27 beta 5
Update: Please disregard this report. The behavior was caused by enabling the hardware keyboard for the device in Xcode 27 beta 5’s Device Hub. This appears to expose a virtual “Generic Keyboard” to the connected physical device, causing GCKeyboardDidConnect to be posted even though no physical keyboard is attached directly to it. Simply disabling the hardware keyboard option was not sufficient. I needed to close Device Hub and restart Xcode for the virtual keyboard to be removed and the expected GCKeyboard behavior to resume. I’m seeing what appears to be a GameController regression on physical iPhone and iPad devices running iOS 27 beta 5. When my app launches with no Bluetooth, USB, or Smart Connector keyboard attached, GCKeyboard.coalesced is initially nil. Shortly afterward, the system posts .GCKeyboardDidConnect for a keyboard named “Generic Keyboard,” and GCKeyboard.coalesced becomes non-nil: === Initial state === GCKeyboard.coalesced: nil cannot add handler to 0 from 0 - dropping === GCKeyboardDidConnect #1 === notification.object: GCKeyboard: 0x10b01cd00 'Generic Keyboard'> GCKeyboard.coalesced: Optional( 0x10b01cd00>) The phantom keyboard then appears to remain connected indefinitely. After this happens: Attaching a real hardware keyboard does not post another .GCKeyboardDidConnect. Detaching the real keyboard does not post .GCKeyboardDidDisconnect. GCKeyboard.coalesced remains non-nil even though no hardware keyboard is attached. This may be interacting with the documented coalescing behavior: the connect notification is posted only for the first keyboard, and the disconnect notification only after the last keyboard disconnects. If the phantom “Generic Keyboard” remains present, a real keyboard is never considered the first or last keyboard. Minimal observer code: print("Initial GCKeyboard.coalesced:", GCKeyboard.coalesced as Any) NotificationCenter.default.addObserver( forName: .GCKeyboardDidConnect, object: nil, queue: .main ) { notification in print("GCKeyboardDidConnect") print("notification.object:", notification.object as Any) print("GCKeyboard.coalesced:", GCKeyboard.coalesced as Any) } NotificationCenter.default.addObserver( forName: .GCKeyboardDidDisconnect, object: nil, queue: .main ) { notification in print("GCKeyboardDidDisconnect") print("notification.object:", notification.object as Any) print("GCKeyboard.coalesced:", GCKeyboard.coalesced as Any) } I can reproduce this on both a physical iPhone and a physical iPad. This is not Simulator keyboard forwarding, and no keyboard is attached when the “Generic Keyboard” appears. Has anyone else observed this behavior on iOS 27 beta 5 or found another API that reliably reports whether a real hardware keyboard is attached? Filed as FB24269002.
Replies
0
Boosts
0
Views
388
Activity
Aug ’26
Draw WKWebView into OpenGL Texture
I'm trying to figure out how to display a Web Browser inside my iOS VR app (Obj-c, SceneKit and raw OpenGL), and the part i'm not fully understanding is how to get the WKWebView to draw it's content into a Pixel Buffer of some sort, so I can use the speed of CVOpenGLESTextureCacheCreateTextureFromImage to convert the pixel data into a OpenGl Texture quickly/efficently and display it on a floating surface.I'm already doing something simular with the video portion of my app, but it has a AVPlayerItemVideoOutput, which produced the pixel buffer, but I can't figure out how to massage the CALayer into a Buffer so I can convert it into a texture to then draw in opengl.I know it has something to do with drawLayer:(Layer) ,(Context), but searching online hasn't been very fruitful.And i'm not using SceneKit like you would assume, the app was built before GVR for Scenekit was a thing, so every part of VR is handled manually (scenekit to textures, textures to opengl for Left/Right eye distortion mesh).
Replies
3
Boosts
0
Views
3.1k
Activity
Jul ’26