AppKit Q&A

Just like NSScrollView lets us programmatically set the contentInset in parallel to automaticallyAdjustsContentInsets, I think there should be similar functionality for blurring effect caused by scroll edge effect. I should be able programmatically set it. If the user is manually setting the contentInset then they can simply set a boolean, which when enabled will show edge effect when the scroll document goes outside the area of inset. Eg: scrollView.contentInsets = NSEdgeInsets(top: 100, left: 0, bottom: 0, right: 0) For contentInset like above set by user, they could set edge effect in two ways Automatically: scrollView.enableEdgeEffectOutsideInsets = true // This will apply edge effect based on frame size of contentInsets Programmatically: scrollView.edgeInsetEffectFrame = NSRect...

Hey Team, Using NSWorkspace.icon(forFile:) and pointing to an app bundle, the system returns an NSImage with the icon of the app, but in the current style. For example, if the user selected tinted icons in Appearance in System Settings, then any icon I receive back from the API will be tinted using the current accent color. Is there a way to override this and get the original icon? Thanks, Ari

Hey Team, I'm developing an app that normally resides in the menu bar and has no Dock icon (activation policy set to accessory. When the user clicks the status icon, and selects 'Settings' in the menu, I change the activation policy to regular, show the window, and activate the app. Since cooperative activation was introduced, the option to ignore all apps when activating was deprecated, so I activate the app without the option. The result is that in 20% of the times, the window doesn't come to the front, or the app is not activated. The user obviously wants this behavior, so what is the proper way to achieve it? Thanks, Ari

We have a status item which works fine on macOS 26 and earlier, which has the following properties: Supports left-click to open main UI (a popover) Supports left-click (while open) to toggle (close) the main UI Supports right-click to show "app" menu (e.g. About, Quit) Supports a drop destination to accept files and folders, which then triggers the main UI for more interaction In macOS 27: left-click seems ok if we use expanded interface session, but otherwise broken left-click while open no longer toggles (event is missing?) right click is no longer operational, to the point that it seems the Menu Bar doesn't forward the event at all. Other (Apple-provided) items work fine, and expose new context menus Dragging now triggers Mission Control, which seems wrong given the destination was in the Menu Bar (FB23018381). Are these interactions now forbidden, and are there lists or documentation of the new rules? As an additional bug, it looks like popovers don't pick up appearance changes. The child scroll view claims to be in light appearance in the View Debugger, but is clearly showing the wrong background color, this is a new (as-yet unreported) issue. One last bug: expanded interface session seems to suppress the popover's animation when shown.

Do you have any ideas on how to make the background color of a NSTextView the same as the background of a NSComboBox when both are on a sidebar? The closest I could get is using a NSVisualEffectView, but it's still not optimal (the text view is slightly darker) override init(frame: NSRect) { self.scrollView = NSTextView.scrollableTextView() if #available(macOS 26.0, *) { scrollView.borderType = .lineBorder let backgroundView = NSVisualEffectView() backgroundView.material = .contentBackground backgroundView.blendingMode = .withinWindow backgroundView.state = .followsWindowActiveState backgroundView.translatesAutoresizingMaskIntoConstraints = false self.materialBackgroundView = backgroundView } else { self.materialBackgroundView = nil } ...

I would like to provide alternate IconComposer-designed icons (that support light, dark, mono) for my macOS app. The DockTile approach only works when app is running, but also only with NSImage. And there doesn't seem to be a way to load an NSImage from a .icon file that matches the current appearance option. Thank you.

At WWDC22, it was stated that TextKit 2 did not support tables and printing and possibly other attributes and NSTextView would revert back to TextKit 1. At what point can we be sure that TextKit 2 supports everything TextKit 1 did and NSTextView will no longer revert back. My app makes use of a subclass of NSTextView and custom layoutManager and migrating to support both versions seems incredibly complex. Thank you.

I’m developing a text editor. In the main pane of a window managed by NSSplitViewController, I place an NSTextView enclosed in an NSScrollView alongside a custom NSView subclass that displays line numbers. The issue is that the line number view sits outside the scroll view, so it does not participate in the visual effects applied by the title bar or by an NSSplitViewItemAccessoryViewController attached to the parent view controller. This problem has existed since around macOS 26, but it appears to be more noticeable in macOS 27 Beta 1. Due to various implementation requirements, my line number view cannot be implemented as a subclass of NSRulerView. In this situation, is there any supported way to ensure that accessory view and toolbar effects are also properly applied to views that are outside the scroll view? The attached screenshot demonstrates a case where the edge effect is not applied correctly. The line number view on the left side does not participate in the effect and instead appears to visually break through it.

Hey Team, System-provided quick actions in Finder sport a template image that adapts correctly to light and dark modes. However when I add a quick action extension in my app, the icon I refer to in the Info.plist renders in full color, even if it is defined in the asset catalog as a template image. This forces me to either use my app icon or a gray icon that will work in either appearance. How can I get the system-provided quick actions treatment? Thanks, Ari

In macOS 27, document-based applications appear to gain a new feature where, when Autosave in Place is enabled, draft document titles are automatically suggested based on the document’s content. I was surprised to see this, but I think it is a great feature. (Interestingly, I have received similar feature requests from users of my own application in the past, but I declined them because I felt they would add unnecessary complexity.) My question is mostly out of curiosity: how is this feature implemented? My assumption is that the system may be reusing the new Spotlight indexing infrastructure to extract document content, perhaps by combining the Data returned from NSDocument.data(ofType:) during autosave with the document’s fileType. Is that understanding correct, or is a different mechanism involved? Are there any articles, WWDC sessions, or other documentation that explain this new draft title suggestion feature? I have not been able to find any information about it. Also, is there currently any way to disable this behavior? I am not personally looking to turn it off, but I suspect some users of my application may eventually ask for that option.

First of all, thank you for updating the sidebar visuals in macOS 27! However, in macOS 27, an NSSearchField subclass placed in a sidebar or inspector appears with the same Liquid Glass button-like styling as toolbar items and other buttons. This behavior seems specific to NSSearchField; for example, a plain NSTextField does not exhibit the same appearance. While this styling may be appropriate in a toolbar, it feels out of place for a search field embedded in a sidebar or inspector. This appearance makes the search field visually indistinguishable from adjacent buttons and reduces its affordance as a text input control. Is there a supported way to control or override the appearance of an NSSearchField placed in a sidebar or inspector in macOS 27, so that it uses a more traditional search field style instead of the Liquid Glass button-like appearance? As a point of reference, Xcode 27 Beta 1 on macOS 27 Beta 1 does not appear to apply the Liquid Glass–style appearance to search fields in its sidebar. This may be because those fields are not implemented as direct subclasses of NSSearchField; however, I believe it also suggests that the Liquid Glass style is not well suited to search fields in this context.

Is it a bug that when I return toolbarSelectableItemIdentifiers in the NSToolbar delegate, the toolbar title no longer displays and the Liquid Glass effect also appears distorted? *This code worked fine up to macOS 26.

Received a response from Quinn @ DTS on FB23017010 regarding the com.apple.spaces plist restructure in Golden Gate. He confirmed no public Spaces API exists and suggested the plist change may be treated as a compatibility bug. He recommended filing an Enhancement Request for a proper API. Two follow-up questions for AppKit engineers: (1) Which Feedback component gets an ER for a public Spaces management API in front of the right team — AppKit, CoreOS, or Mission Control? (2) Is there any timeline visibility on the compatibility bug determination for the Monitors key removal?"

Is there any documentation on the NSText* features supported by the various document types NSAttributedString can encode in AppKit? For example if I create an NSTextTable (which works fine in RTF), how can I can know if it's supported in the following types: DocFormat WordML OfficeOpenXML OpenDocument They mostly are not, and if I use merged cells (row/col spans) the support is even lower. Similarly, if I wanted to use Markdown decoding support to encode to the HTML type, does AppKit provide translation from PresentationIntent to the NSText* implementations?

Hi AppKit team, I'm trying to use an NSTextField in an NSTableView where the visible text wraps up to 3 lines, truncates after that, and then shows the full text in an expansion tooltip on hover. The behavior I want is: visible cell: wrapped text, capped at 3 lines hover expansion tooltip: full wrapped text I can get expansion tooltips to appear for non-wrapping text, but I haven't been able to get them to work for wrapped text capped with maximumNumberOfLines. What is the recommended way to implement expansion tooltips for a wrapping, line-capped NSTextField? Here is a minimal repro: import AppKit final class ViewController: NSViewController, NSTableViewDataSource, NSTableViewDelegate { let tableView = NSTableView() let text = String(repeating: "Very long wrapped text ", count: 40) override func viewDidLoad() { view = tableView tableView.addTableColumn(NSTableColumn()) tableView.usesAutomaticRowHeights = true tableView.dataSource = self tableView.delegate = self } func numberOfRows(in tableView: NSTableView) -> Int { 1 } func tableView(_ tableView: NSTableView, viewFor tableColumn: NSTableColumn?, row: Int) -> NSView? { let tf = NSTextField(wrappingLabelWithString: text) tf.maximumNumberOfLines = 3 tf.allowsExpansionToolTips = true tf.cell?.truncatesLastVisibleLine = true return tf } } Thank you.

Hey Team, In the Finder, the segmented control in the toolbar where the user can choose to display the files as icons, list, columns, or gallery, indicates its selection using a gray background. Is that done via custom drawing or is it a semantic option in AppKit? When I adopt Liquid Glass in my app by removing UIDesignRequiresCompatibility, my segmented control indicates the selections with a strong accent color. This could be distracting to my users and I'd like to duplicate the Finder behavior. Thanks, Ari

I added images to all NSMenuItems in my app on macOS 26. Now, with macOS 27 beta 1, most of them are no longer displayed, which seems to be the behavior of NSMenuItem.ImageVisibility.automatic. However, this only happens for images initialized with NSImage(systemSymbolName:accessibilityDescription:). Images initialized with NSImage(named:) are still shown, despite the visibility setting being .automatic. What would be an approach that is consistent for all app-contributed NSMenuItems while still respecting the system default? Even more, how would one set image visibility to also address possible future system settings that decide on menu-item image visibility? As a side note, the documentation for NSMenuItem.ImageVisibility has no description for .automatic, and the documentation for .hidden and .visible seems wrong or misleading (or I'm misunderstanding): .hidden: The item image should always be visible. Note that in some cases, AppKit may still hide the image, overriding this preference. .visible: AppKit should choose whether the item’s image is visible, considering the system configuration.

macOS Tahoe fails to close NSWindows after display sleep, causing window accumulation and performance degradation We have a feedback open for this problem on Tahoe (FB21391882) as well as a DTS track. Our QA team has verified that this is still occurring with the Golden Gate Beta 1. I am wondering if this is going to be prioritized as an issue in Golden Gate, or if this is not going to be looked into any further. Honestly I am not sure this is the forum for this, but I was not sure where else to ask at WWDC this year due to the lack of 1-1 appointments.

Hi. macOS 26.5 introduced a bug involving menu item keyboard shortcuts without modifier keys. For example, it affects a menu item with the keyboard shortcut J, but not the keyboard shortcut ⌘J. This bug is also present in the first beta of macOS 27. When a menu item is invoked with a keyboard shortcut that has no modifiers and its validateMenuItem(_:) method returns false, the system beeps and refuses to perform the operation. This is expected. But then even after validateMenuItem(_:) is returning true again, the app will continue refusing to perform that keyboard shortcut until the app is quit and relaunched. It will also do the same with all other keyboard shortcuts that have no modifiers and are attached to menu items. I filed this with a sample project as FB22762541. I also wrote about it in more detail at: https://virtualsanity.com/202605/bug-involving-keyboard-shortcuts-for-menu-items-that-have-no-modifier-keys-on-macos-265/ I would love to see this issue addressed. Thank you for your work.

Hey Team, In my app there are bordered toolbar buttons with a button type of toggle. Before Liquid Glass, such a button with an on state would paint its template image in accent color. After removing UIDesignRequiresCompatibility, these buttons no longer show their state. What is the best practice to migrate these buttons to Liquid Glass? Thank, Ari