“swiftui”

Hello @Moretheus, You have a good start! While I can't confirm exactly how Apple achieved a certain goal, I can show you how you can get the same result in your starting project. What you are noticing is that NSOutlineView.style = .sourceList displays the selection highlight using the system accent color. To set your own color, first disable the built-selection highlight by setting outline.selectionHighlightStyle = .none in makeNSView. Then create a separate view for the row that you can style to your liking. I used drawBackground to paint the selection and interiorBackgroundStyle to disable the SF symbol inverting to white when selected. final class SidebarRowView: NSTableRowView { override var isSelected: Bool { didSet { needsDisplay = true } } override func drawBackground(in dirtyRect: NSRect) { if isSelected { NSColor.systemGray .withAlphaComponent(0.2) .setFill() NSBezierPath(roundedRect: bounds.insetBy(dx: 8, dy: 1), xRadius: 5, yRadius: 5).fill() } } override var interiorBackgroundStyle: NSView.Backgro

@Etresoft In my case, changing the activation policy doesn't work. See the video below. I even added extra DispatchQueue.main.async and switched the window from SwiftUI to AppKit - in both cases the same result. https://github.com/user-attachments/assets/6734c215-8129-4402-9f0a-b777d27195ad Nevertheless, showing a dock icon is too disruptive for menu bar apps in most cases. If we must use a workaround, I've found a better one - calling a deeplink activates the app. It just requires registering URL scheme and calling something like: NSWorkspace.shared.open(URL(string: menubar://main)!)

Don't use the comments. They hide your replies. I didn't test your app. It's SwiftUI. I had looked at this recently and wanted to see if there was different behaviour in AppKit. I did not test it incorrectly. I wrote a menubar app with LSUIElement set. It behaves as you describe. But if I temporarily set the activation policy to be regular, before displaying the window, then the window appears normally. When closing the window, I could set the activation policy back to accessory. That would definitively fix the problem, at the cost of having the app temporarily appear in the dock.

Here's what I've just tried: Create a new project via File > New > Project and select App as the type. Add a new asset catalog to the project using File > New > File From Template, and select Asset Catalog. Add a new ColorSet and rename it to AccentColor Reference Color.accentColor in a SwiftUI .foregroundStyle view modifier. The color in the asset catalog appears correctly. If you could provide a sample project in a feedback, that would help the investigation. Thanks!

@DTS Engineer We used to routinely present dialogs modally before sheets were introduced around 10.6 I believe. The introduction of sheets provided a more refined user experience and were quickly adopted by both document-based applications and shoebox-based applications. As far as I know (the HIG no longer explicitly calls this out), using sheets for open and save dialogs remains the recommended user experience. panel.runModal() has its use-cases, like when selecting a document to open after the application has launched, but it doesn't seem like the right fit for many macOS use cases. If a SwiftUI-native way to request a save destination would fit your app better, that is a good thing to send through Feedback Assistant Fair enough. Given SwiftUI already has considerable APIs for fileImporter, fileExporter, fileMover and fileDialog, I assumed I was overlooking an existing API for this common macOS use case. Thanks for the discussion.

Hi, thank you for the quick reply! I wanted to call out a specific user experience issue with this approach regarding menu bar apps. Currently, if a user clicks an item in the menu bar expecting a window to open, that window appears behind the currently active window. Because it's hidden from view, the user might assume the app is broken or didn't respond. It's hard to imagine that this is the intended behavior. Bringing the newly opened window to the foreground would be the expected behavior in this case. It seems like the new NSApp.activate() was designed for regular apps and did not take menu bar apps into account. This behavior is the same when using NSApp.activate() and SwiftUI openWindow. For now, all menu bar apps still rely on the deprecated NSApp.activate(ignoringOtherApps:), but removing this function would result in breaking thousands of apps. That's why I think there should be an alternative to NSApp.activate(ignoringOtherApps:) or the behavior of NSApp.activate() should be changed when t

Thank you for the post. Very interesting post. The strictness of the new window activation model is intended, I believe the goal was to stop apps from aggressively stealing focus from the user while they are typing or working in another app. Because of this, NSApp.activate(ignoringOtherApps:) was deprecated. https://developer.apple.com/documentation/appkit/nsapplication/activate(ignoringotherapps:) You should use https://developer.apple.com/documentation/appkit/nsapplication/activate() If you are using SwiftUI lifecycle with MenuBarExtra and WindowGroup, relying on the environment's openWindow to handles the underlying activation better than bridging to AppKit: @Environment(.openWindow) var openWindow // Inside your MenuBarExtra... Button(Open) { openWindow(id: my-main-window) } My code is for reference only as I don't validate it with Xcode. If the behavior deviates from your expectations, the bug filed as an enhancement will be forwarded to the relevant team for evaluation of your requirements. The

Thanks for writing back. You may already be doing this, in which case take it as confirmation rather than news: NSSavePanel does not need an NSWindow to present at all. Calling panel.runModal() from your SwiftUI action presents the panel app-modally and returns the chosen URL, with no window reference involved. That keeps you entirely within the SwiftUI app lifecycle, and it avoids the window question entirely. The tradeoff is that the panel appears as a standalone modal dialog rather than as a sheet attached to your window. The window only matters if you specifically want that document-modal sheet, through beginSheetModal(for:). That path does need the hosting NSWindow, and as of macOS 26 SwiftUI does not expose a first-class accessor for it. If your app has a single window, NSApp.keyWindow is a perfectly good way to get it. The ambiguity only arises once more than one window can be key; for that case, a small NSViewRepresentable that reads its view's window is the more robust idio

@DTS Engineer Thanks for the quick follow-up. I'm pretty familiar with what you've presented. The problem with invoking NSSavePanel from within a SwiftUI macOS application is that you don't necessarily have access to the underlying NSWindow to properly present the NSSavePanel as a sheet, which would be the expected user experience. I'm aware of the following ways to work around this, all of which feel awkward in a pure SwiftUI environment: Assume the application's current key window is the one to use. Use an NSViewRepresentable as a window accessor Abandon the full SwiftUI app lifecycle and just using a traditional AppKit lifecycle for window management. Are there other ways I've overlooked that are more idiomatic SwiftUI? The ability to ask the user for a URL to save content to is such a fundamental macOS feature that it's omission genuinely perplexes me. Are you able to elaborate at all as to what the general rational and thinking is behind this?