So I'm in the middle of an asynchronous file operation. I publish an NSProgress and it displays wonderfully in Finder. But it is a folder and while the operation is in progress the user should not be allowed to enter it, modify it, etc, while the work is being done. I want to do this to protect the user from doing something silly. But Finder does not prevent the selection with the published progress. And while it would be kind of dumb to do - the user can just go about adding/removing contents to the folder while it has progress. If I remember correctly publishing an NSProgress did use to prevent the file from being selectable in Finder until either the progress finished or my app is quit (or maybe not)? But now the user is free to select, edit, modify during progress which could cause problems if the user does something unexpectedly silly. Is there a way to mark the file 'unselectable' with the published progress? Thanks in advance.

I'm building a macOS app with two separate NSPanel windows, both using the new liquid glass material (NSVisualEffectView / macOS 26). The UI intentionally has two separate floating panels visible at the same time. The problem: only the key window displays the active liquid glass appearance. The non-key panel always renders with the inactive/foggy appearance, even with: NSWindowStyleMaskNonactivatingPanel canBecomeKeyWindow = false orderFrontRegardless() addChildWindow(_:ordered:) Is there any way — documented or otherwise — to force the active liquid glass appearance on a non-key NSPanel? Or is this fundamentally a compositor-level restriction? If it's impossible with two separate windows, is there an alternative approach to achieve two visually separate liquid glass boxes that both appear active simultaneously?

On macOS 26, how do you support the Preferred Text Size value as defined in the Accessibility Settings? Historically, "Dynamic Type" has not been available on macOS. However, the user has some control over text size through the Accessibility Settings. On macOS 26, a small subset of applications are honouring changes to that value include Finder, Mail, and sidebars in many applications. Dynamic sizing in table views has been available on macOS for awhile. But Mail.app, in particular, is also adjusting the font sizes used in the message's body pane while the Finder is adjusting font sizes used for Desktop icons. I can't find an NSNotification that is fired when the user adjusts the Accessibility Text Size slider, nor can I find an API to read the current value. NSFont.preferredFont(forTextStyle:options:) looks promising but the fonts returned do not appear to take the user's Accessibility setting into account. (Nor do they update dynamically.) SwiftUI's Text("Apple").font(.body) performs similarly to NSFont in that it does respect the style, but it does not honour dynamic sizing. NSFontDescriptor has a bunch of interesting methods, but none that seem to apply to Accessibility Text Size. Given an AppKit label: let label = NSTextField(labelWithString: "AppKit") label.font = NSFont.preferredFont(forTextStyle: .body) Or a SwiftUI label: Text("SwiftUI").font(.body) How do I make either of them responsive to the user's Text Size setting under Accessibility? Note this is on macOS 26 / Xcode 26. I realize there have been some previous forum posts related to this issue but hoping that things might have improved since then.

This example application crashes when entering any text to the token field with FAULT: NSGenericException: The window has been marked as needing another Update Constraints in Window pass, but it has already had more Update Constraints in Window passes than there are views in the window. The app uses controlTextDidChange to update a live preview where it accesses the objectValue of the token field. If one character is entered, it also looks like the NSTokenFieldDelegate methods tokenField(_:styleForRepresentedObject:) tokenField(_:editingStringForRepresentedObject:) tokenField(_:representedObjectForEditing:) are called more than 10000 times until the example app crashes on macOS Tahoe 26 beta 6. I've reported this issue with beta 1 as FB18088608, but haven't heard back so far. I have multiple occurrences of this issue in my app, which is working fine on previous versions of macOS. I haven't found a workaround yet, and I’m getting anxious of this issue persisting into the official release.

I’m developing a text editor that provides a line number view. This view is placed next to the NSScrollView that contains the main text view, rather than inside the scroll view. The line number view updates its drawing in sync with the NSScrollView’s scrolling and text editing in the NSTextView, so it can display the correct line numbers. This approach worked fine through macOS 15, but on macOS 26 with Liquid Glass, the line numbers end up being drawn without the expected blur/soft edge effect under the window toolbar area. In AppKit, some view controllers provide APIs to switch edge effects between soft/hard, but I can’t find any API to control this for the window toolbar region. I considered simply not drawing the numbers outside the content area, but if possible I’d like to apply the Tahoe-style soft edge effect instead. Does anyone have ideas? Is this currently impossible, meaning the only option is to file a feedback/API request? Also, for various reasons, the traditional approach of implementing line numbers by subclassing NSRulerView is difficult for my app.

In the attached screenshot, we have an NSSplitViewController with three split view items. The first two are viewController split view items, while the third is an inspector split view item. The NSWindow is configured for full screen content so that the inspector split view items is full height itself. However, when we enable full height content view, AppKit is automatically adding a tracking separator into the toolbar when we don't want one. (Neither of the two split views are sidebars.) This tracking separator is out of place, cannot be dragged itself, and is drawn under the center aligned segmented control. We've tried a multitude of permutations to configure the NSWindow, NSToolbar and NSSplitViewItem but to no avail. Surely we're just missing the magic combo but a lot of the properties appear to be no-ops in macOS 26. How do we use an NSSplitViewController, in a full screen content window, such that we get a full height inspector but we don't get tracking separators for the main split view divider?

Is anyone else getting new warning about menu items with submenus when running on Tahoe? I'm getting big performance problems using my menu as well as seeing these messages and I'm wondering if there's a connection. My app is faceless with a NSStatusItem with an NSMenu. Specifically it's my own subclass of NSMenu where I have a lot of code to manage the menu's dynamic behavior. This code is directly in the menu subclass instead of in a controller because the app I forked had it this way, a little wacky but I don't see it being a problem. A nib defines the contents of the menu, and it's instantiated manually with code like: var nibObjects: NSArray? = [] guard let nib = NSNib(nibNamed: "AppMenu", bundle: nil) else { ... } guard nib.instantiate(withOwner: owner, topLevelObjects: &nibObjects) else { ... } guard let menu = nibObjects?.compactMap({ $0 as? Self }).first else { ... } Within that nib.instantiate call I see a warning logged that seems new to Tahoe, before the menu's awakeFromNib is called, that says (edited): Internal inconsistency in menus - menu <NSMenu: 0x6000034e5340> believes it has <My_StatusItem_App.AppMenu: 0x7f9570c1a440> as a supermenu, but the supermenu does not seem to have any item with that submenu My_StatusItem_App.AppMenu: 0x7f9570c1a440 is my menu belonging to the NSStatusItem, NSMenu: 0x6000034e5340 is the submenu of one of its menu items. At a breakpoint in the NSMenu subclass's awakeFromNib I print self and see clear evidence of the warning's incorrectness. Below is a snippet of the console including the full warning, only edited for clarity and brevity. It shows on line 32 menu item with placeholder title "prototype batch item" that indeed has that submenu. Internal inconsistency in menus - menu <NSMenu: 0x6000034e5340> Title: Supermenu: 0x7f9570c1a440 (My StatusItem App), autoenable: YES Previous menu: 0x0 (None) Next menu: 0x0 (None) Items: ( "<NSMenuItem: 0x6000010e4fa0 Do The Thing Again, ke mask='<none>'>", "<NSMenuItem: 0x6000010e5040 Customize\U2026, ke mask='<none>'>", "<NSMenuItem: 0x6000010e50e0, ke mask='<none>'>" ) believes it has <My_StatusItem_App.AppMenu: 0x7f9570c1a440> Title: My StatusItem App Supermenu: 0x0 (None), autoenable: YES Previous menu: 0x0 (None) Next menu: 0x0 (None) Items: ( ) as a supermenu, but the supermenu does not seem to have any item with that submenu (lldb) po self <My_StatusItem_App.AppMenu: 0x7f9570c1a440> Title: My StatusItem App Supermenu: 0x0 (None), autoenable: YES Previous menu: 0x0 (None) Next menu: 0x0 (None) Items: ( "<NSMenuItem: 0x6000010fd7c0 About My StatusItem App\U2026, ke mask='<none>', action: showAbout:, action image: info.circle>", "<NSMenuItem: 0x6000010fd860 Show Onboarding Window\U2026, ke mask='Shift', action: showIntro:>", "<NSMenuItem: 0x6000010fd900 Update Available\U2026, ke mask='<none>', action: installUpdate:, standard image: icloud.and.arrow.down, hidden>", "<NSMenuItem: 0x6000010e46e0, ke mask='<none>'>", "<NSMenuItem: 0x6000010e4780 Start The Thing, ke mask='<none>', action: startTheThing:>", "<NSMenuItem: 0x6000010e4dc0 \U2318-\U232b key detector item, ke mask='<none>', view: <My_StatusItem_App.KeyDetectorView: 0x7f9570c1a010>>", "<NSMenuItem: 0x6000010e4e60, ke mask='<none>'>", "<NSMenuItem: 0x6000010e4f00 saved batches heading item, ke mask='<none>', view: <NSView: 0x7f9570b4be10>, hidden>", "<My_StatusItem_App.BatchMenuItem: 0x6000016e02c0 prototype batch item, ke mask='<none>', action: replaySavedBatch:, submenu: 0x6000034e5340 ()>", "<NSMenuItem: 0x6000010f7d40, ke mask='<none>'>", "<My_StatusItem_App.ClipMenuItem: 0x7f956ef14fd0 prototype copy clip item, ke mask='<none>', action: copyClip:>", "<NSMenuItem: 0x6000010fa620 Settings\U2026, ke='Command-,', action: showSettings:>", "<NSMenuItem: 0x6000010fa6c0, ke mask='<none>'>", "<NSMenuItem: 0x6000010fa760 Quit My StatusItem App, ke='Command-Q', action: quit:>" ) Is this seemingly incorrect inconsistency message harmless? Am I only grasping at straws to think it has some connection to the performance issues with this menu?

So if I create an Alias of a folder in Finder and hand the alias to my app (I also moved the alias file to a new folder, but I did not move the original folder)...so then my app resolves the alias using: NSURL +URLByResolvingAliasFileAtURL: What happens? The resolved URL points to a completely different folder. Well not completely different. It resolves to a folder that happens to share same last path component as the original folder...but this folder is inside the same parent folder the alias file is in. It does not resolve to the original folder I created the alias of. So then once my app touches the alias with +URLByResolvingAliasFileAtURL: the alias now resolves to this new (wrong) location (even in Finder). Couple details: My app is not sandboxed. I have permission to access the original folder in my app (but even if I didn't the alias shouldn't be mutated just by merely resolving it). Only seems to happen if the folder I move the alias to happens to contain a sibling folder that has the same title as the original folder. Like it's just deleting the last path component of the alias and then appending the last path component of the original filename and just going with that. I hope that makes sense. I tried creating the alias myself using -bookmarkDataWithOptions: and going the other way (to Finder) but Finder must be resolving the alias using a different API because it resolves to the original location as expected.

When I end editing pressing the escape key, the system sometimes plays NSBeep(). I noticed this with NSBrowser. Every time I press escape to end editing the system beeps. At first I thought it was somewhere in my app but I set a symbolic breakpoint and discovered it was not coming from my code. I filed FB22127038. Since then I discovered that NSBeep playing at inappropriate times is not exclusive to NSBrowser. It appears if there is a NSTableView in the window and you just press the escape key (even if you aren't editing anything) AppKit beeps. It can be traced to: #0 0x0000000199e3184c in NSBeep () #1 0x000000019aa03fac in -[NSWindow doCommandBySelector:] () #2 0x000000019ac1d01c in -[NSTableView(NSTableViewViewBased) cancelOperation:] ()

I get warnings like this on each project I build while debugging.. Internal inconsistency in menus - menu <NSMenu: 0x8b4b49ec0> Title: Help Supermenu: 0x8b4b49f80 (Main Menu), autoenable: YES Previous menu: 0x0 (None) Next menu: 0x0 (None) Items: ( "<NSMenuItem: 0x8b5771720 Metal4C Help, ke='Command-?'>" ) believes it has <NSMenu: 0x8b4b49f80> Title: Main Menu Supermenu: 0x0 (None), autoenable: YES Previous menu: 0x0 (None) Next menu: 0x0 (None) Items: ( ) as a supermenu, but the supermenu does not seem to have any item with that submenu What am I doing wrong? I get these errors even if I create a default app with no code?

I have received a few crash reports for my app "Find Any File" with an assertion failure as follows: assertion failure: "displayTiming != ((void *)0)" -&gt; %lld Googling this turns up nothing, though. I wonder if someone has some insight into why this might happen, and how to prevent it. One reporting user suggests that it happens when my app shows a very long list of items in an NSTableView (&gt;10000 elements). I have 4 reports from 3 users, and the main thread is doing something related to the table view each time, though not the same (the few other threads are all idle): Crash 1, in macOS 14.0 (23A344: Thread 0:: Dispatch queue: com.apple.main-thread 0 libobjc.A.dylib 0x182c69400 objc_msgSend + 0 1 AppKit 0x186f15400 -[CALayer(NSViewVisibleRect) NS_viewVisibleRectDidChange] + 40 2 AppKit 0x186900e10 NSViewHierarchyInvalidateVisibleRect + 276 3 AppKit 0x186900db0 NSViewHierarchyInvalidateVisibleRect + 180 4 AppKit 0x186900db0 NSViewHierarchyInvalidateVisibleRect + 180 5 AppKit 0x186900db0 NSViewHierarchyInvalidateVisibleRect + 180 6 AppKit 0x186900db0 NSViewHierarchyInvalidateVisibleRect + 180 7 AppKit 0x186900db0 NSViewHierarchyInvalidateVisibleRect + 180 8 AppKit 0x1869990e0 -[NSView translateOriginToPoint:] + 164 9 AppKit 0x186984108 -[NSClipView _immediateScrollToPoint:] + 420 10 AppKit 0x186983eb8 -[NSClipView scrollToPoint:] + 184 11 AppKit 0x186998d80 -[NSScrollView scrollClipView:toPoint:] + 84 12 AppKit 0x1869448dc -[NSClipView _scrollTo:animateScroll:flashScrollerKnobs:] + 480 13 AppKit 0x186b65b24 __62-[NSScrollingBehaviorConcurrentVBL _stopGestureScrollTracking]_block_invoke + 192 14 AppKit 0x186e6a6e8 ___NSMainRunLoopPerformBlockInModes_block_invoke + 44 15 CoreFoundation 0x18310b8c0 __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 28 Crash 2, in macOS 14.1.1 (23B81): Thread 0:: Dispatch queue: com.apple.main-thread 0 CoreFoundation 0x18ba401f4 DYLD-STUB$$_Block_object_assign + 0 1 libsystem_blocks.dylib 0x18b506118 _call_copy_helpers_excp + 80 2 libsystem_blocks.dylib 0x18b505c68 _Block_copy + 376 3 libdispatch.dylib 0x18b641c7c _dispatch_Block_copy + 32 4 libdispatch.dylib 0x18b658df0 _dispatch_source_set_handler + 92 5 CoreFoundation 0x18b99e1e4 __CFRunLoopCopyMode + 540 6 CoreFoundation 0x18b8b7458 CFRunLoopAddObserver + 220 7 AppKit 0x18f0a687c _PerfAddRunLoopObserver + 192 8 AppKit 0x18f87cd60 -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 368 9 AppKit 0x18f323318 -[_NSScrollingConcurrentEventMonitor startMonitoring] + 380 10 AppKit 0x18f321df8 -[NSScrollingBehaviorConcurrentVBL _scrollView:trackGestureScrollWithEvent:] + 884 11 AppKit 0x18f2e67f8 -[NSScrollingBehaviorConcurrentVBL scrollView:scrollWheelWithEvent:] + 512 12 AppKit 0x18f241770 forwardMethod + 252 13 AppKit 0x18f2e62a0 -[NSView scrollWheel:] + 408 14 AppKit 0x18f241770 forwardMethod + 252 15 AppKit 0x18f2e62a0 -[NSView scrollWheel:] + 408 16 AppKit 0x18f241770 forwardMethod + 252 17 AppKit 0x18f2e62a0 -[NSView scrollWheel:] + 408 18 AppKit 0x18f241770 forwardMethod + 252 19 AppKit 0x18f2e62a0 -[NSView scrollWheel:] + 408 20 AppKit 0x18fc45880 -[NSCollectionView scrollWheel:] + 180 21 AppKit 0x18f241770 forwardMethod + 252 22 AppKit 0x18f241770 forwardMethod + 252 23 AppKit 0x18f2e62a0 -[NSView scrollWheel:] + 408 24 AppKit 0x18f241770 forwardMethod + 252 25 AppKit 0x18f2e62a0 -[NSView scrollWheel:] + 408 26 AppKit 0x18f241770 forwardMethod + 252 27 AppKit 0x18f2e62a0 -[NSView scrollWheel:] + 408 28 AppKit 0x18f1d27b0 -[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] + 652 As you can see, there's no code of mine involved at the time of crash. The other (and older) reports are similar, in macOS 13.6.1 and macOS 13.1. All four happened on ARM architecture (which may not be significant due to small number of samples). Memory use of app was not critical (in one case it was about 9 GB total, in others below 4 GB). The "Binary Images" section only lists Apple libs, apart from my app's. So, there seems to be no 3rd party ext involved. I've attached a full report as well. Full report of Crash 1

When you have multiple Apps on the Mac which all provide Quicklook extensions for the same file type, then I would assume that if I activate one of these Quicklook extensions in the system settings, this one would be used. But this doesn't seem to be the case. It looks like the macOS just looks the very first extension it can find for a certain file type, and if this Quicklook extension is switched off, the file can not be previewed anymore. The macOS just doesn't bother to look for the other existing quicklook extension for this file, even if this other is enabled. The only option right now to get this other extension to be used by the system would be to completely delete the first App, so its extension is deleted as well. Is this really the way how it is supposed to work? How can this be fixed? Can I tell my users something else than "just delete the other App"?

I'd like to create a Quick Look extension for a file type for which a location or region on a Map should be shown as preview. However the MapView would only show a grid without any map. From within the MapKit delegate I can see from the "Error" parameter (a server with this domain can not be found) that this seems to be a network issue. The Quick Look extension seems to have no access to the internet and therefore the MapView can not load any map data. I've then also done some other tests via URLSession, which also only fails with connection errors. I haven't seen any limitations or restrictions mentioned in the API documentation. Is this the expected behavior? Is this a bug? Or am I missing something?

Hello Using a MacBook Pro Intel with macOS 12.7.6 Monterey, I test in Objective-C an event for the option key but it is not working - (void)keyDown:(NSEvent *)event { printf("%s %p\n", __FUNCTION__, self); BOOL altFlag = [event modifierFlags] & NSEventModifierFlagOption; if (altFlag) { // UpdateClass printf("option pressed\n"); } else { printf("option not pressed\n"); } } The same in Swift works fine override func keyDown(with event: NSEvent) { if event.modifierFlags.contains(.option) { print("option pressed") } else { print("option NOT pressed") } } The Obj-C code works fine on a MacBook Air Tahoe 26.3 Any idea why it does not work on the macOS 12.7.6 Intel? Many Thanks Jean

We are currently testing our application under macOS 26 in Liquid Glass mode and noticed an issue with NSSegmentedCell. Our app makes extensive use of NSCell-based drawing. Since macOS 26, when running in Liquid Glass mode, NSSegmentedCell does not render at the expected location. The control itself appears visually correct, but it is clearly drawn offset from the rect it is supposed to occupy. In compatibility mode, everything renders exactly as expected (same code, same layout). To illustrate the issue, here are two screenshots of the same view: Liquid Glass mode 👉 (screenshot 1 – segmented control visibly shifted) Compatibility mode 👉 (screenshot 2 – correct rendering) The regression is obvious when switching between the two modes. This behavior has been present since the first macOS 26 release and is still reproducible with Xcode 26.2 (17C52). I have already filed a report via Feedback Assistant (FB reference available if useful), but I’m posting here to see whether others are experiencing the same issue or have found a workaround. Thanks.

In this Mac App, I have an IBOutlet (which is defined as instance of a subclass of NSView). When I connect the IBOutlet to the code, referencing as file's owner, it works OK. But if I reference to the class, it crashes, when I access a specific IBOutlet (but other IBOutlets are accessed just before it without crashing).. The IBOutlet turnPageControl is defined as instance of subclass of NSView. Note: I have implemented several init methods: override init(window: NSWindow!) { } required init?(coder: (NSCoder?)) { } // Yes, (NSCoder?) convenience init(parameters) { // loading from nib } override func windowDidLoad() { super.windowDidLoad() // Access turnpageControl I get those calls before crash: init(window:) init(parameters:) init(window:) windowDidLoad() -> crash inside on accessing the IBOutlet for turnPageControl.isHidden = true Is there any reason to this ?

I reported Korean IME bug to QT Bug report. Please refer to below link. https://bugreports.qt.io/browse/QTBUG-136128?jql=text%20~%20korean%20ORDER%20BY%20created%20DESC But, QT reponsed me like follwing. Thank you for reporting. However, this issue seems like a known issue with apple's Korean IME. There are many threads in Korean community about the same problem with Non-Qt apps. If this issue is a really Qt issue, feel free to open it again. Is there any workaround to fix this IME bug ? Thanks, Ted

My application provides a unique feature for MacOS 26+ users, while keeping legacy for other versions (12.4+). So I aim to provide two help books localized package, depending on MacOS' version of the running computer. I designed two help bundles, with their own Info.plist files (identifiers, default filename…) and I've made multiple checks to verify that all their settings are correct and different when needed. As an app's info.plist can deal only with one Help Book, my application delegate registers both in applicationDidFinishLaunching: using: [[NSHelpManager sharedHelpManager] registerBooksInBundle:[NSBundle mainBundle]]; In Interface Builder, the help menu item is connected to the application delegate's "showHelp:" method to set the correct help package. The code in this method is: if (@available(macOS 26.0,*)){ helpbook = @"fr.myapp.updated.help"; } else { helpbook = @"fr.myapp.legacy.help"; } [[NSHelpManager sharedHelpManager] openHelpAnchor:@"index" inBook:helpbook]; The problem is that despite the MacOS version of the user's Mac, (either 15.1 or 26.2) , the «legacy» helpbook is always used. All default index.html (for each lproj) have a tag immediately after the I spent dozen of hours to understand the problem, forum parsing, including hours long dialogs with ChatGPT and Claude AIs (not mentioning MacOS' help system cache problems I could solve) I noticed also, to be complete, that when parsing the application package, opening the legacy .help with "Tips.app" always works, but with the "updated" one the help system opens with an "unavailable content" message. Both help bundles are fully included in the built application. Tested whether the app is installed in the debug directory, moved to in the Applications one, reboot, emptying/deleting cache files. So Houston, I have a problem… Any idea?

I'm building a macOS app that uses WKWebView for text editing (not NSTextView). I need to provide grammar checking by calling NSSpellChecker programmatically and sending results back to the web editor. The problem: TextEdit (which uses NSTextView) catches grammar errors like "Can I has pie?" and "These are have" — but when I call NSSpellChecker's APIs directly, those same errors are never flagged. I've tried both APIs: 1. The unified check() API: let results = checker.check( text, range: range, types: NSTextCheckingAllTypes, options: [:], inSpellDocumentWithTag: tag, orthography: &orthography, wordCount: &wordCount) This returns only .orthography results (language detection). No .spelling, no .grammar — just orthography. 2. The dedicated checkGrammar(of:startingAt:...) API: let sentenceRange = checker.checkGrammar( of: text, startingAt: offset, language: nil, wrap: false, inSpellDocumentWithTag: tag, details: &details) This catches sentence fragments ("The.", "No.") and some agreement errors ("The is anyone.") but misses "Can I has pie?", "These are have", "This will be happened", and other subject-verb agreement errors that TextEdit highlights. What I've confirmed: "Check Grammar With Spelling" is enabled in System Settings TextEdit reliably catches all these errors with green underlines Both APIs are called with a valid spellDocumentTag from uniqueSpellDocumentTag() The text is passed as plain strings (no attributed string context) My question: How does NSTextView's grammar checking work internally? It must be using something beyond these two public APIs. Possibilities I'm considering: Does NSTextView use the NSTextCheckingClient protocol / requestChecking(of:range:types:options:) for asynchronous checking that produces different results? Does NSTextView provide additional context (attributed string, layout info) that improves grammar detection? Is there a private/undocumented API or framework that NSTextView uses for deeper grammar analysis? Any insight from anyone who has implemented programmatic grammar checking on macOS would be appreciated. NOTE: This post was composed with the help of Claude Code, which I am using to help write a word-processing application, but I am frustrated because Claude Code wants to give up and switch to a 3rd party grammar checker, like LanguageTool, and it seems to me that it should be possible to use native Apple tools to achieve this goal without requiring the user to send their data elsewhere for checking. I've spent a lot of time searching the web for answers and have found surprisingly little on this. Any pointers people might have would be very much appreciated! Thanks.

When disabling the opacity slider of color panels, my app crashes with unsatisfiable layout constraints. Feel free reproduce with a minimal test project: A macOS app based on the Xcode 26.0 template with only one line added to the ViewController's viewDidLoad() function: NSColorPanel.shared.showsAlpha = false The issue doesn't occur if this property is set to "true" or not set at all. I just filed a corresponding bug report (FB20269686), although I don't expect any feedback from Apple ... as numerous issues I reported were never updated or commented at all (after migrating from RADARs).