I noticed that in Xcode 27 Beta 1 on macOS 27 Beta 1, changing the selection of the segmented control used to switch between the Sidebar and Inspector tabs is animated. However, the standard segmented controls used by NSTabView/NSTabViewController, as well as a regular NSSegmentedControl, do not appear to have any such animation on macOS 27. I also tried using the animator proxy: segmentedControl.animator().selectedSegment = index but this did not change the behavior. How can I implement the same kind of segmented control selection animation that Xcode uses? Is there a public API for this, or is it achieved through a different mechanism?

When working on a multi-window AppKit app, how do you identify which window instance is associated with the current breakpoint? The same question applies when using LLDB. If execution stops inside an object that can exist in more than one window, such as a shared NSViewController subclass, how do you know which window’s object you are currently inspecting? Does Xcode provide a mechanism for showing the NSWindow associated with the current view, view controller or responder while debugging? My current approach is to print object identities and compare them manually. For example, if several identical windows are open, I might print the current object and its window: print(self, #function) Then I interact with one window, make a note of the printed memory addresses in the console, switch to another window and compare the output. This works, but it feels manual. I am not dealing with different window subclasses. The windows may be instances of the same class and may contain instances of the same view controller classes. I simply want an easier way to distinguish which window instance I am debugging. Is there a recommended Xcode, LLDB or AppKit workflow for this?

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?

How do I permanently hide the standard window buttons(Buttons on top left; close, minimize and zoom) In my app, I hide the standard buttons and put my own custom buttons. Some users have reported that the standard buttons appear again making the app look buggy and confuses the users At present I use following code to remove the buttons standardWindowButton(.closeButton)?.removeFromSuperview() standardWindowButton(.miniaturizeButton)?.removeFromSuperview() standardWindowButton(.zoomButton)?.removeFromSuperview() } I have to call this code from multiple places like on window initialization, when appearance changes and when the window size changes. I tried creating window without the titled stylemask, but it has other down sides like the standard window decoration is entirely skipped by the system. The resizing also is unpredictable. My question is, what is the right way to remove/hide the standard window buttons?

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'm trying to use NSTokenField for the first time. So my custom 'representedObject' for a token has additional model data tied to it (not just the editing/display string). I noticed when I edit an existing token, type text, and hit the enter key I get the following delegate callback: - (nullable id)tokenField:(NSTokenField *)tokenField representedObjectForEditingString:(NSString *)editingString; This same delegate method is called when I type a brand new token. Is there a way to distinguish if I'm editing a token vs. creating a new one? My expectation is to be able to do something like this (made up enhancement): - (nullable id)tokenField:(NSTokenField *)tokenField representedObjectForEditingString:(NSString *)editingString atIndex:(NSUInteger)existingTokenIndex { if (existingTokenIndex == NSNotFound) { // Token is new, create a new instance MyTokenObject *newToken = //create and configure. return newToken; } else { // This would update the editing string but wouldn't discard existing data held by the token. MyTokenObject *tokenObj = [self existingTokenAtIndex:existingTokenIndex]; tokenObj.editingString = editingString; return tokenObj; } }

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

Is it possible to remove the ugly sidebar and inspector chrome with AppKit? I don't care if it's a hack or a swizzle or something, but I need to get rid of this. I want to convert this: Into this (photoshopped): Thanks for your help!

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.

Putting: let statusItem = NSStatusBar.system.statusItem(withLength: NSStatusItem.variableLength) at the top of AppDelegate.swift and no other code at all generates the warning below in the console when the app runs. Looks benign but it sure would be great to not have that happen. Anyone figure out how to stop this other than muting the warning? I tried all kinds of exotic deferring but that just makes the code brittle and unreadable. Here's the warning: It's not legal to call -layoutSubtreeIfNeeded on a view which is already being laid out. If you are implementing the view's -layout method, you can call -[super layout] instead. Break on void _NSDetectedLayoutRecursion(void) to debug. This will be logged only once. This may break in the future. Xcode 26.5, 26.4 - macOS 26.5.1

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