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?

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.

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.

I have been pleased to see SwiftUI’s List performance improve over the years. However, when using a List that contains DisclosureGroup views, expanding and collapsing items becomes significantly slower as the amount of data grows. In my case, I need to control the initial expanded/collapsed state of each disclosure item, so I cannot use the recursive List(_:children:) API. Is there a recommended way to improve the performance of a List containing DisclosureGroup views, or is falling back to AppKit’s NSOutlineView currently the only practical solution? (Yes, for context, my app is for macOS.) The following code shows the relevant portion of my implementation: List(self.summary.files, selection: $selection) { file in DisclosureGroup(isExpanded: $expandedFileURLs.contains(file.id)) { ForEach(file.matches) { match in FolderFindMatchView(match: match) .tag(FolderFind.ResultID.match(fileID: file.id, matchID: match.id)) } } label: { FolderFindFileResultView(file: file) .draggable(item: FolderFindDraggedFile(id: .file(file.id), fileURL: file.fileURL)) } .listRowSeparator(.hidden) .tag(FolderFind.ResultID.file(file.id)) }

I am using NSSearchField for a non-incremental search UI. The field is configured as follows: let searchField = NSSearchField() searchField.sendsSearchStringImmediately = false searchField.sendsWholeSearchString = true searchField.target = target searchField.action = #selector(submit(_:)) My expectation is that the action is sent only when the user explicitly commits the search, such as by pressing Return or clicking the search button. I understand that clicking the cancel button inside the NSSearchField clears the text and sends the action with an empty string. That behavior is documented and makes sense. However, I am also seeing the action sent when the user edits the text normally and deletes the last character, causing the search field’s stringValue to become empty. In other words, while the user is just editing the field with the Delete key, the action is sent even though the user did not press Return or explicitly commit the search. Is this expected behavior for NSSearchField, or is it a bug? If it is expected, is there a recommended public API to distinguish these cases? User pressed Return with a non-empty string User clicked the search/cancel button User simply edited the text and the string became empty I would like to keep using NSSearchField’s built-in recent searches behavior, so intercepting Return with control(_:textView:doCommandBy:) is not ideal. If this is not expected behavior, I will file Feedback with a sample project. Environment: macOS 26.5 (25F71) Xcode 26.5 (17F42)

I recently turned on the enhanced security options for my macOS app in Xcode 26.0.1 by adding the Enhanced Security capability in the Signing and Capabilities tab. Then, Xcode adds the following key-value sets (with some other key-values) to my app's entitlements file. <key>com.apple.security.hardened-process.enhanced-security-version</key> <integer>1</integer> <key>com.apple.security.hardened-process.platform-restrictions</key> <integer>2</integer> These values appear following the documentation about the enhanced security feature (Enabling enhanced security for your app) and the app works without any issues. However, when I submitted a new version to the Mac App Store, my submission was rejected, and I received the following message from the App Review team via the App Store Connect. Guideline 2.4.5(i) - Performance Your app incorrectly implements sandboxing, or it contains one or more entitlements with invalid values. Please review the included entitlements and sandboxing documentation and resolve this issue before resubmitting a new binary. Entitlement "com.apple.security.hardened-process.enhanced-security-version" value must be boolean and true. Entitlement "com.apple.security.hardened-process.platform-restrictions" value must be boolean and true. When I changed those values directly in the entitlements file based on this message, the app appears to still work. However, these settings are against the description in the documentation I mentioned above and against the settings Xcode inserted after changing the GUI setting view. So, my question is, which settings are actually correct to enable the Enhanced Security and the Additional Runtime Platform Restrictions?

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.

On macOS Tahoe 26 activating GUI apps from command-line often fails. It launches the app but not brings to the foreground as expected. For example, running the following commands in Terminal is expected to launch Pages and bring it to the foreground. open /Applications/Pages.app or osascript -e `tell application "Pages" to activate` Moreover, they sometimes not return in Terminal. These commands worked as expected until macOS 15 but no more in macOS 26. The tricky part is that this failure doesn't happen 100% of the time; it occurs randomly. However, since multiple users of my app have reported the same symptoms, and I can reproduce it not only with my app but also with apps bundled to macOS, I don't believe this is an issue specific to my environment alone. I’ve already filed this issue: FB21087054 Open version: https://github.com/1024jp/AppleFeedback/issues/87 However, I’d like to know if any workaround exists or my understanding is wrong, especially for case with osascript.

I want to check whether a sandboxed application already has access permission to a specific URL. Based on my investigation, the following FileManager method seems to be able to determine it: FileManager.default.isReadableFile(atPath: fileURL.path) However, the method name and description don't explicitly mention this use case, so I'm not confident there aren't any oversights. Also, since this method takes a String path rather than a URL, I'd like to know if there's a more modern API available. I want to use this information to decide whether to prompt the user about the Sandbox restriction in my AppKit-based app.

SwiftUI’s Menu is used also to display view controls like pop-up buttons. However, in such cases, its content is evaluated at the moment the button itself appears, although it’s not required until the menu is actually opened. Additionally, since the menu content isn’t re-evaluated when opened, if the content is dynamically generated, there could be a discrepancy between the actual state and the displayed state depending on the timing. Considering these points, I’d like to delay generating the menu content until the moment it’s actually opened. Is there a way to delay the evaluation and generation of the Menu’s content until the moment its contents are displayed? Note: I'd like to know about using it within a macOS app.

NSHostingSceneRepresentation, introduced in macOS 26, allows calling SwiftUI’s windows and other elements set in a Scene from AppKit. However, while Settings and WindowGroup set in the Scene can be invoked as expected using environment.openSettings() and environment.openWindow(id:) respectively, calling Window or WindowUtility doesn’t work. That is, the app just fails to open the desired window with the provided ID, and no error message or other feedback/crash/freeze appears. I expect that executing the openUtilityWindow(_:)action in the following code will display the UtilityWindow set in the scene. However, the window does not actually open. @main final class AppDelegate: NSObject, NSApplicationDelegate { private let scene = NSHostingSceneRepresentation { UtilityWindow("Utility Window", id: "UtilityWindow") { Text("Utility Window") .scenePadding() } } func applicationWillFinishLaunching(_ notification: Notification) { NSApp.addSceneRepresentation(self.scene) } @IBAction func openUtilityWindow(_ sender: Any?) { self.scene.environment.openWindow(id: "UtilityWindow") } } Is there something wrong with my implementation and expectation? Or is this a bug in NSHostingSceneRepresentation? Just in case, I’ve already filed this issue withFeedback Assistant: FB20310722 This feedback also includes a sample project reproducing this issue.

On macOS Tahoe 26, NSSplitViewController introduced the NSSplitViewItemAccessoryViewController and related-APIs in NSSplitViewController, such as addBottomAlignedAccessoryViewController(_:). Those APIs allow you to place accessory views at the top and bottom of a split view with a nice edge effect. I understand how to use them with AppKit. However, I’m not sure how to achieve the same functionality with SwiftUI.

In SwiftUI on macOS, A menu-style Picker is drawn as a pop-up button. It generally looks and behaves the same as an NSPopUpButton in AppKit. SwiftUI introduced iOS-like looking UI for settings in macOS, and consequently, the Picker also has its own style when placed inside a Form. A Form-style Picker displays only up/down chevrons and draws the background only when the mouse hovers over it. It also changes its width dynamically based on the selected item. Form { Picker("Animal:", selection: $selection) { ForEach(["Dog", "Cow"], id: \.self) { Text($0) } .pickerStyle(.menu) } You can find it, for instance, in the Print dialog. My question is: I couldn't find a way to draw an NSPopUpButton in AppKit with this style. Does anyone know how to achieve this in AppKit? Some might say I should just use SwiftUI straightforwardly, but I would like to use it in a print panel accessory that currently still avoids using SwiftUI but its dialog has SwiftUI.Form-looking.