I have a question about NSSplitViewItemAccessoryViewController, introduced with the new design since macOS 26, and how it interacts with NSScrollView content insets. My app has a typical three-pane window whose content view controller is an NSSplitViewController subclass. The sidebar contains a tab view with a segmented control, similar to Xcode, for switching between different sidebar panes. Each pane contains an NSScrollView whose content can be scrolled. Before macOS 26, I placed the segmented control directly inside the sidebar view. To adopt the new scroll-edge effect and allow the sidebar content to extend visually into the window title bar, I moved the segmented control into an NSSplitViewItemAccessoryViewController. However, with this layout, the scroll view starts immediately below the segmented control, which feels visually cramped. I'd like to add a few points of top inset before the document view begins. Previously, I achieved this by setting: scrollView.additionalSafeAreaInsets.top However, this now causes the accessory view's scroll-edge effect to extend into the additional safe-area inset, producing an awkward blurred region underneath the segmented control. Ideally, I'd like the scroll view to begin directly below the segmented control while still having a small inset before the document content, with the scroll-edge effect ending exactly at the bottom of the accessory view. In addition to additionalSafeAreaInsets, I tried the following approaches, but neither produced the desired result: Set scrollView.automaticallyAdjustsContentInsets to false and specify scrollView.contentInsets.top. This disables the automatic safe-area adjustment, causing the entire scroll view to move upward underneath the accessory view. Set scrollView.contentView.automaticallyAdjustsContentInsets to false and specify scrollView.contentView..contentInsets.top. This produces the same result as above. Set the accessory view's preferredScrollEdgeEffectStyle to .soft. The segmented control becomes too transparent, making its unselected labels difficult to read. Xcode's sidebar appears to achieve the behavior I'm looking for. What is the recommended way to implement this layout on macOS 26 and 27? Xcode's sidebar (macOS 26) My app's sidebar (macOS 26, work in develop) with additionalSafeAreaInsets

I'm dragging existing files from a SwiftUI List (a search result list in a sandboxed, document-based Mac app), and I want drop targets to receive the actual file URL — the same behavior as AppKit's NSOutlineView with outlineView(_:pasteboardWriterForItem:) returning an NSURL: the Finder copies the file, browsers load it, and text views insert its path. My current implementation is Transferable-based: FileRepresentation(exportedContentType: .data) { item in SentTransferredFile(item.fileURL, allowAccessingOriginalFile: true) } .suggestedFileName(\.fileURL.lastPathComponent) With this, what receivers get is a temporary copy in the app's own container (Caches/com.apple.SwiftUI.Drag-<UUID>/), not the actual file URL — despite allowAccessingOriginalFile: true. Dropping on the Finder or onto an application icon works through the copy, but receivers that interpret the URL itself — a browser window, or a text view that inserts the dropped file's path — see the temporary container path. Note that the dragged files live inside a folder the user has opened as a document (the app is NSDocument-based), so the app already holds security-scoped access to them. Alternatives don't help either: DataRepresentation(exportedContentType: .fileURL) returning the URL bytes of the actual file: the pasteboard data is likewise replaced with the copy's URL, and moreover, drops onto application icons (e.g. Safari in the Dock) are no longer accepted at all. onDrag with NSItemProvider(object: url as NSURL): same substitution. I've already filed this as FB23578716, with detailed reproduction steps and drag-pasteboard dumps. My questions: Is there any way in current SwiftUI (macOS 26/27 SDK) to put the real file URL of an existing file on the drag pasteboard? Is the rewriting to a temporary copy intended behavior (for sandbox safety), or a bug? If it's intended, is embedding an AppKit view that calls beginDraggingSession(with:event:source:) with an NSURL pasteboard writer the recommended workaround for now? It does write the real URL, but making it coexist with List's selection and click handling has proven fragile. Environment: macOS: macOS 27 Beta 2 / Version 26.5.2 Xcode: Version 27.0 Beta 2 App Sandbox enabled

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.