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.

We're using IKPictureTaker to let users pick a room avatar image. The flow worked correctly on macOS 13–15, but breaks on macOS 26 (Tahoe). Symptoms popUpRecentsMenu(for:withDelegate:didEnd:contextInfo:) — no UI appears at all, and the didEnd selector is never called runModal() — a window appears but its content is completely blank (empty gray rectangle). The app freezes until the user force-quits Minimal reproduction import Quartz let pictureTaker = IKPictureTaker.pictureTaker() pictureTaker?.setCommonValuesForKeys(allowsVideoCapture: true) // Attempt 1 — silent fail, no UI, no callback pictureTaker?.popUpRecentsMenu(for: someButton, withDelegate: self, didEnd: #selector(pictureTakerDidEnd), contextInfo: nil) // Attempt 2 — window appears but content is blank let result = pictureTaker?.runModal() // result is never returned while window is visible; app is frozen Environment macOS 26.0 (Tahoe) — reproducible by QA on multiple machines Xcode 16, Swift 5, deployment target macOS 10.14 Camera permission granted (AVAuthorizationStatus.authorized) App is sandboxed What I've ruled out Camera permission is authorized before the call The view passed to popUpRecentsMenu has a valid, visible, key window Same code works on macOS 13, 14, 15 Question Is this a known regression in macOS 26? Is IKPictureTaker expected to stop working, or is there a required entitlement / initialization step that changed? If the API is effectively unsupported, is NSOpenPanel with allowedContentTypes: [.image] the recommended migration path?