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.

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.

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.

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?

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:] ()

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"?

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

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'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.

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?

Since we started building our application on Tahoe, all NSPopupButtons in the UI stop truncating when the window they're in is moved to a different screen. Even though their frame is correct, if the selected item string is longer than what can fit, they just draw outside of their bounds, overlapping other neighbouring controls. This is reproducible only in our app target even though they are not subclassed or overridden in any way. The same window copied to a test app doesn't have the issue. Initially good After dragging to another screen Frame is correct in the View Hierarchy debugger, but the contents are incorrect. Very simple constraint setup, with content compression resistance set lower to allow resizing below the intrinsic content size. This is what happens on this simple test window. The rest of the popups in more complex windows are all bad right away, without requiring you to move them to a different screen. When built on Sequoia, all is well regardless of which OS the app is run on. Looking for ideas on how to troubleshoot this and figure out what's triggering it.

I have a mac app using AppKit. I have a view that extends under the toolbar. It is very slightly blurred but still disturbs the readability of the toolbar items. In another window, I have a view that sits inside a NSScrollView and there the content is much more blurred and a bit dimmed under the toolbar. Is there a way to make the not scrolled view behave like the one in the NSScrollView?

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 an NSTableView (Appkit), I need to colour a cell background when it is selected. That works OK, except that the colour does not span the full cell width, nor even the text itself: The tableView structure is very basic: I see there is a TextCell at the end that cannot be deleted. What is this ? And the colouring as well: func tableView(_ tableView: NSTableView, viewFor tableColumn: NSTableColumn?, row: Int) -> NSView? { let p = someDataSource[row] if let cellView = tableView.makeView(withIdentifier: NSUserInterfaceItemIdentifier(rawValue: "Cell"), owner: self) { (cellView as! NSTableCellView).textField?.stringValue = p if selected[row] { (cellView as! NSTableCellView).backgroundColor = theLightBlueColor } else { (cellView as! NSTableCellView).backgroundColor = .clear } return cellView } } I've tried to change size constraints in many ways, to no avail. For instance, I changed Layout to Autoresising : I tried to change TableCellView size to 170 vs 144: Or increase tableColum Width. I have looked at what other object in the NSTableView hierarchy should be coloured without success. Nothing works. What am I missing ?

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?

When building in Xcode on MacOS Tahoe, it seems it is no longer possible to dynamically specify a "small" size toolbar for NSToolbar/NSToolbarItem. It works in MacOS code compiled and linked on earlier systems. I don't want to use "SFSymbol", or "templates". I have over 60 custom-made .png toolbars, in individual Image Set files, at the previous requisite sizes of 24x24 / 48x48, and 32x32 / 64x64. Sure -- I can configure an NSToolbar with whatever size .png assets I want. I just can't dynamically switch between the two groups of sizes. According to the Apple Coding Assistant, the only solution is to change the image names of each of the NSToolbarItems at runtime. OK -- but even when attempting that, the NSToolbarItems refuse to take on their smaller size... ...unless: they are attached to a custom view NSToolbarItem with an NSButton of style "Bevel". I have about 10 of those, and YES -- I CAN change those to a "small" size. Is this REALLY what I'm forced to do?! The Apple Coding Assistant just runs me around in circles, making coding suggestions that include properties that don't exists. I've gone around and around on these issues for over a week -- it can't be this hard, right? Is there no way to make multiple NSToolbar objects, one for "large" and one for "small"?

This is a very basic macOS Finder-style test app using AppKit. I am experiencing a "jump" in the vertical scroll position of my NSTableView (inside an NSScrollView) specifically when the window is resized horizontally. This happens when columns are visually added or removed. Framework: AppKit (Cocoa) Xcode/macOS: 26.2 Code: https://github.com/MorusPatre/Binder/blob/main/ContentView%20-%20Scroll%20Jump%20during%20Resize.swift

Context: Xcode 16.4, Appkit In a windowController, I need to create and send a mouseDown event (newMouseDownEvent). I create the event with: let newMouseDownEvent = NSEvent.mouseEvent( with: .leftMouseDown, location: clickPoint, // all other fields I also need to make window key and front, otherwise the event is not handled.   func simulateMouseDown() { self.window?.makeFirstResponder(self.window) self.calepinFullView.perform(#selector(NSResponder.self.mouseDown(with:)), with: newMouseDownEvent!) }   As I have to delay the call( 0.5 s), I use asyncAfter: DispatchQueue.main.asyncAfter(deadline: .now() + 0.5, qos: .userInteractive) { self.simulateMouseDown() }   It works as intended, but that generates the following (purple) warning at runtime: [Internal] Thread running at User-interactive quality-of-service class waiting on a lower QoS thread running at Default quality-of-service class. Investigate ways to avoid priority inversions I have tried several solutions, change qos in await: DispatchQueue.main.asyncAfter(deadline: .now() + 0.5, qos: ..default) call from a DispatchQueue let interactiveQueue = DispatchQueue.global(qos: .userInteractive) interactiveQueue.async { self.window?.makeFirstResponder(self.window) self.calepinFullView.perform(#selector(NSResponder.self.mouseDown(with:)), with: newMouseDownEvent!) } But that's worse, it crashes with the following error: FAULT: NSInternalInconsistencyException: -[HIRunLoopSemaphore wait:] has been invoked on a secondary thread; the problem is likely in a much shallower frame in the backtrace; { NSAssertFile = "HIRunLoop.mm"; NSAssertLine = 709; }   How to eliminate the priority inversion risk (not just silencing the warning) ?