{ "@context": "https://schema.org", "@id": "https://aggr.aymericbeaumet.com/items/steipete-me/2025-06-17-showing-settings-from-macos-menu-bar-items-a-5-hour-journey/#webpage", "@type": [ "WebPage", "ArchiveComponent" ], "articleBody": "![](https://steipete.me/assets/img/2025/showing-settings-from-macos-menu-bar-items/hero.png)\n\nOpening a settings window from a macOS menu bar app should be trivial. It’s not. After spending hours debugging, I’m documenting the gotchas to save you the same frustration.\n\n## The Problem\n\nSwiftUI provides [`SettingsLink`](https://developer.apple.com/documentation/swiftui/settingslink) for opening settings:\n\n```swift\nMenuBarExtra(\"Test\", systemImage: \"star.fill\") {\n SettingsLink {\n Text(\"Open settings\") \n }\n}\n```\n\nSimple, right? Except it doesn’t work reliably in [`MenuBarExtra`](https://developer.apple.com/documentation/swiftui/menubarextra). The documentation doesn’t mention this limitation.\n\nAccording to Apple’s documentation, `SettingsLink` should “open the app’s settings scene when activated.” However, this assumes your app is already active and has proper window management context - assumptions that don’t hold for menu bar apps.\n\n## Why It Fails\n\nMenu bar apps operate differently from regular macOS apps:\n\n- **No dock icon by default** - They use [`NSApplication.ActivationPolicy.accessory`](https://developer.apple.com/documentation/appkit/nsapplication/activationpolicy/accessory)\n- **Not “active” in the traditional sense** - They don’t appear in the app switcher\n- **Windows may appear behind other apps** - Without proper activation, windows lack focus\n- **No SwiftUI graph loaded** - Settings needs some SwiftUI view initalized and the menu bar uses AppKit under the hood.\n\nThe root issue is that [`NSApplication`](https://developer.apple.com/documentation/appkit/nsapplication) treats menu bar apps as background utilities, not foreground applications. This affects how windows are ordered and receive events.\n\n## The Evolution of Workarounds\n\n### The Old Way\n\nThis is how it used to work. Private API, but widely used and simple:\n\n```swift\nif #available(macOS 13, *) {\n NSApp.sendAction(Selector((\"showSettingsWindow:\")), to: nil, from: nil)\n} else {\n // macOS 12 or earlier\n NSApp.sendAction(Selector((\"showPreferencesWindow:\")), to: nil, from: nil)\n}\n```\n\nThis stopped working in Sonoma (14) with the error: “Please use SettingsLink for opening the Settings scene.” Apple deprecated these selectors in favor of SwiftUI’s scene-based approach, but didn’t account for the unique challenges of menu bar apps.\n\n### The openSettings Environment Action\n\nApple provides an [`openSettings` environment action](https://developer.apple.com/documentation/swiftui/opensettingsaction) for programmatic access (available since macOS 14.0+):\n\n```swift\nstruct MyView: View {\n @Environment(\\.openSettings) private var openSettings\n\n var body: some View {\n Button(\"Open Settings\") {\n openSettings()\n }\n }\n}\n```\n\nThis currently works on macOS 15, but doesn’t work on macOS Tahoe (26). The logic needs an existing SwiftUI render tree, and simply calling the environment variable does nothing if none is found.\n\nThe workaround? As horrible as it sounds, a *hidden window*. Of course, that comes with its own issues, unless you massage the window that it’s really off-screen and ideally also doesn’t react to touches.\n\n## Hide & Seek\n\nNow, this works, however the window will open in the *background*, and no amount of `makeKeyAndOrderFront(nil)` will help. Trust me. I (and [Claude](https://steipete.me/posts/2025/claude-code-is-my-computer/)) tried plenty variations.\n\nThe real reason? macOS doesn’t allow a window to become selected when there’s no Dock icon. And since it’s common to hide the Dock icon for pure Menu Bar apps, that’s a problem.\n\nThe workaround? Show the Dock icon just before calling `openSettings()` and then hiding it again. In a way, this is also convenient for the user as the Icon now represents the “app” - the visible window, and once that closes, we hide the Dock icon again. (via calling `NSApp.setActivationPolicy(.accessory)`). Of course the whole thing requires some delays to really work, so let me present you the final, working solution (I apologize in advance):\n\n## The Working Solution\n\nHere’s the minimal implementation for macOS 14 and higher, using Swift 6:\n\n```swift\n// Hidden window to provide context\nstruct HiddenWindowView: View {\n @Environment(\\.openSettings) private var openSettings\n \n var body: some View {\n Color.clear\n .frame(width: 1, height: 1)\n .onReceive(NotificationCenter.default.publisher(for: .openSettingsRequest)) { _ in\n Task { @MainActor in\n // Show dock icon for window focus\n NSApp.setActivationPolicy(.regular)\n try? await Task.sleep(for: .milliseconds(100))\n \n // Activate and open\n NSApp.activate(ignoringOtherApps: true)\n openSettings()\n \n // 2. No window ordering - After openSettings(), you might need additional window management to ensure\n // it comes to front:\n try? await Task.sleep(for: .milliseconds(200))\n if let settingsWindow = findSettingsWindow() {\n settingsWindow.makeKeyAndOrderFront(nil)\n settingsWindow.orderFrontRegardless()\n }\n }\n }\n .onReceive(NotificationCenter.default.publisher(for: .settingsWindowClosed)) { _ in\n // Restore menu bar app state when settings closes\n NSApp.setActivationPolicy(.accessory)\n }\n }\n}\n\n// Window identifier for settings\nstatic let settingsWindowIdentifier = \"com.apple.SwiftUI.Settings\"\n\n/// Finds the settings window using multiple detection methods\nstatic func findSettingsWindow() -> NSWindow? {\n // Try multiple methods to find the window\n return NSApp.windows.first { window in\n // Check by identifier\n if window.identifier?.rawValue == settingsWindowIdentifier {\n return true\n }\n \n // Check by title\n if window.isVisible && window.styleMask.contains(.titled) &&\n (window.title.localizedCaseInsensitiveContains(\"settings\") ||\n window.title.localizedCaseInsensitiveContains(\"preferences\")) {\n return true\n }\n \n // Check by content view controller type\n if let contentVC = window.contentViewController,\n String(describing: type(of: contentVC)).contains(\"Settings\") {\n return true\n }\n \n return false\n }\n}\n\n// App structure\n@main\nstruct MenuBarApp: App {\n var body: some Scene {\n MenuBarExtra(\"My App\", systemImage: \"star.fill\") {\n Button(\"Settings...\") {\n NotificationCenter.default.post(name: .openSettingsRequest, object: nil)\n }\n .keyboardShortcut(\",\", modifiers: .command)\n }\n \n // Required Settings scene\n Settings {\n SettingsView()\n .onDisappear {\n NotificationCenter.default.post(name: .settingsWindowClosed, object: nil)\n }\n }\n \n // Hidden window for context\n Window(\"Hidden\", id: \"HiddenWindow\") {\n HiddenWindowView()\n }\n .windowResizability(.contentSize)\n .defaultSize(width: 1, height: 1)\n }\n}\n\nextension Notification.Name {\n static let openSettingsRequest = Notification.Name(\"openSettingsRequest\")\n static let settingsWindowClosed = Notification.Name(\"settingsWindowClosed\")\n}\n```\n\nThe [`NotificationCenter`](https://developer.apple.com/documentation/foundation/notificationcenter) approach decouples the menu action from the window context, allowing the hidden window to handle the actual settings opening.\n\nFor a production-ready implementation with all edge cases (yes, there are some more…) handled, see [VibeTunnel’s SettingsOpener.swift](https://github.com/amantus-ai/vibetunnel/blob/2a63599ce0b09d139ddc9954f41f2a5840264f9f/mac/VibeTunnel/Utilities/SettingsOpener.swift#L4).\n\n## Scene Order Matters (Unfortunately)\n\nWhile implementing @steipete’s solution described above, I (@matejkob) discovered another gotcha: **the order of scenes in your App’s body actually affects whether this workaround functions correctly**.\n\nThe working example shown earlier has the scenes in this order:\n\n1. `MenuBarExtra`\n2. `Settings`\n3. `Window` (hidden)\n\nHowever, I found that if you arrange them like this (which seems equally logical):\n\n```swift\nvar body: some Scene {\n MenuBarExtra(\"My App\", systemImage: \"star.fill\") {\n ContentView()\n }\n .menuBarExtraStyle(.menu)\n \n Settings {\n SettingsView()\n .onDisappear {\n NotificationCenter.default.post(name: .settingsWindowClosed, object: nil)\n }\n }\n \n // Hidden window for settings context\n Window(\"Hidden\", id: \"HiddenWindow\") {\n HiddenWindowView()\n }\n .windowResizability(.contentSize)\n .defaultSize(width: 100, height: 100)\n}\n```\n\nThe hidden window won’t be “visible” to the SwiftUI environment system (at least not on macOS Sequoia 15.5), and the `openSettings()` call will fail silently. However, moving the hidden `Window` scene **before** the `Settings` scene makes it work perfectly:\n\n```swift\nvar body: some Scene {\n // Hidden window for settings context - MUST come before Settings\n Window(\"Hidden\", id: \"HiddenWindow\") {\n HiddenWindowView()\n }\n .windowResizability(.contentSize)\n .defaultSize(width: 100, height: 100)\n \n MenuBarExtra(\"My App\", systemImage: \"star.fill\") {\n ContentView()\n }\n .menuBarExtraStyle(.menu)\n \n Settings {\n SettingsView()\n .onDisappear {\n NotificationCenter.default.post(name: .settingsWindowClosed, object: nil)\n }\n }\n}\n```\n\nThis suggests that SwiftUI’s scene resolution and environment propagation happens in declaration order, and the `@Environment(\\.openSettings)` action in the hidden window needs its context established before the `Settings` scene is processed.\n\nWhether this is an Xcode build system quirk, a SwiftUI implementation detail, or intended behavior is unclear from Apple’s documentation. What is clear is that **the hidden window must be declared before the Settings scene** for this workaround to function reliably.\n\nThis adds yet another layer of undocumented complexity to what should be a simple operation - not only do we need a hidden window and activation policy juggling, but we also need to carefully order our scene declarations to avoid mysterious failures.\n\n## Understanding the Workaround\n\nThe hidden window serves multiple purposes:\n\n- Provides a valid window context for the `openSettings` environment action\n- Allows us to temporarily switch activation policies without visual disruption\n- Gives us a place to handle the complex timing orchestration\n\nThe dock icon manipulation (switching between [`.accessory`](https://developer.apple.com/documentation/appkit/nsapplication/activationpolicy/accessory) and [`.regular`](https://developer.apple.com/documentation/appkit/nsapplication/activationpolicy/regular)) is necessary because macOS only brings windows to the front reliably for apps with dock icons.\n\n## Fin\n\nWhat should be a one-liner in other frameworks requires careful orchestration in SwiftUI. The combination of [`MenuBarExtra`](https://developer.apple.com/documentation/swiftui/menubarextra), [`Settings`](https://developer.apple.com/documentation/swiftui/settings) scenes, and [`openSettings`](https://developer.apple.com/documentation/swiftui/opensettingsaction) wasn’t designed with the unique constraints of menu bar apps in mind.\n\nThis shouldn’t be so hard. Opening a settings window is one of the most basic operations any app needs to perform. The fact that it requires hidden windows, activation policy juggling, and precise timing delays in 2025 is a testament to how menu bar apps remain second-class citizens in SwiftUI. Until Apple addresses these fundamental issues, we’re stuck with these workarounds.\n", "authors": [], "captured_at": "2026-09-27T19:29:15.293681927+00:00", "category": "programming", "content_html": "

\"\"

\n

Opening a settings window from a macOS menu bar app should be trivial. It’s not. After spending hours debugging, I’m documenting the gotchas to save you the same frustration.

\n

The Problem

\n

SwiftUI provides SettingsLink for opening settings:

\n
MenuBarExtra("Test", systemImage: "star.fill") {\n    SettingsLink {\n        Text("Open settings") \n    }\n}\n
\n

Simple, right? Except it doesn’t work reliably in MenuBarExtra. The documentation doesn’t mention this limitation.

\n

According to Apple’s documentation, SettingsLink should “open the app’s settings scene when activated.” However, this assumes your app is already active and has proper window management context - assumptions that don’t hold for menu bar apps.

\n

Why It Fails

\n

Menu bar apps operate differently from regular macOS apps:

\n\n

The root issue is that NSApplication treats menu bar apps as background utilities, not foreground applications. This affects how windows are ordered and receive events.

\n

The Evolution of Workarounds

\n

The Old Way

\n

This is how it used to work. Private API, but widely used and simple:

\n
if #available(macOS 13, *) {\n    NSApp.sendAction(Selector(("showSettingsWindow:")), to: nil, from: nil)\n} else {\n    // macOS 12 or earlier\n    NSApp.sendAction(Selector(("showPreferencesWindow:")), to: nil, from: nil)\n}\n
\n

This stopped working in Sonoma (14) with the error: “Please use SettingsLink for opening the Settings scene.” Apple deprecated these selectors in favor of SwiftUI’s scene-based approach, but didn’t account for the unique challenges of menu bar apps.

\n

The openSettings Environment Action

\n

Apple provides an openSettings environment action for programmatic access (available since macOS 14.0+):

\n
struct MyView: View {\n    @Environment(\\.openSettings) private var openSettings\n\n    var body: some View {\n        Button("Open Settings") {\n            openSettings()\n        }\n    }\n}\n
\n

This currently works on macOS 15, but doesn’t work on macOS Tahoe (26). The logic needs an existing SwiftUI render tree, and simply calling the environment variable does nothing if none is found.

\n

The workaround? As horrible as it sounds, a hidden window. Of course, that comes with its own issues, unless you massage the window that it’s really off-screen and ideally also doesn’t react to touches.

\n

Hide & Seek

\n

Now, this works, however the window will open in the background, and no amount of makeKeyAndOrderFront(nil) will help. Trust me. I (and Claude) tried plenty variations.

\n

The real reason? macOS doesn’t allow a window to become selected when there’s no Dock icon. And since it’s common to hide the Dock icon for pure Menu Bar apps, that’s a problem.

\n

The workaround? Show the Dock icon just before calling openSettings() and then hiding it again. In a way, this is also convenient for the user as the Icon now represents the “app” - the visible window, and once that closes, we hide the Dock icon again. (via calling NSApp.setActivationPolicy(.accessory)). Of course the whole thing requires some delays to really work, so let me present you the final, working solution (I apologize in advance):

\n

The Working Solution

\n

Here’s the minimal implementation for macOS 14 and higher, using Swift 6:

\n
// Hidden window to provide context\nstruct HiddenWindowView: View {\n    @Environment(\\.openSettings) private var openSettings\n    \n    var body: some View {\n        Color.clear\n            .frame(width: 1, height: 1)\n            .onReceive(NotificationCenter.default.publisher(for: .openSettingsRequest)) { _ in\n                Task { @MainActor in\n                    // Show dock icon for window focus\n                    NSApp.setActivationPolicy(.regular)\n                    try? await Task.sleep(for: .milliseconds(100))\n                    \n                    // Activate and open\n                    NSApp.activate(ignoringOtherApps: true)\n                    openSettings()\n                    \n                    // 2. No window ordering - After openSettings(), you might need additional window management to ensure\n                    // it comes to front:\n                    try? await Task.sleep(for: .milliseconds(200))\n                    if let settingsWindow = findSettingsWindow() {\n                        settingsWindow.makeKeyAndOrderFront(nil)\n                        settingsWindow.orderFrontRegardless()\n                    }\n                }\n            }\n            .onReceive(NotificationCenter.default.publisher(for: .settingsWindowClosed)) { _ in\n                // Restore menu bar app state when settings closes\n                NSApp.setActivationPolicy(.accessory)\n            }\n    }\n}\n\n// Window identifier for settings\nstatic let settingsWindowIdentifier = "com.apple.SwiftUI.Settings"\n\n/// Finds the settings window using multiple detection methods\nstatic func findSettingsWindow() -> NSWindow? {\n    // Try multiple methods to find the window\n    return NSApp.windows.first { window in\n        // Check by identifier\n        if window.identifier?.rawValue == settingsWindowIdentifier {\n            return true\n        }\n        \n        // Check by title\n        if window.isVisible && window.styleMask.contains(.titled) &&\n           (window.title.localizedCaseInsensitiveContains("settings") ||\n            window.title.localizedCaseInsensitiveContains("preferences")) {\n            return true\n        }\n        \n        // Check by content view controller type\n        if let contentVC = window.contentViewController,\n           String(describing: type(of: contentVC)).contains("Settings") {\n            return true\n        }\n        \n        return false\n    }\n}\n\n// App structure\n@main\nstruct MenuBarApp: App {\n    var body: some Scene {\n        MenuBarExtra("My App", systemImage: "star.fill") {\n            Button("Settings...") {\n                NotificationCenter.default.post(name: .openSettingsRequest, object: nil)\n            }\n            .keyboardShortcut(",", modifiers: .command)\n        }\n        \n        // Required Settings scene\n        Settings {\n            SettingsView()\n                .onDisappear {\n                    NotificationCenter.default.post(name: .settingsWindowClosed, object: nil)\n                }\n        }\n        \n        // Hidden window for context\n        Window("Hidden", id: "HiddenWindow") {\n            HiddenWindowView()\n        }\n        .windowResizability(.contentSize)\n        .defaultSize(width: 1, height: 1)\n    }\n}\n\nextension Notification.Name {\n    static let openSettingsRequest = Notification.Name("openSettingsRequest")\n    static let settingsWindowClosed = Notification.Name("settingsWindowClosed")\n}\n
\n

The NotificationCenter approach decouples the menu action from the window context, allowing the hidden window to handle the actual settings opening.

\n

For a production-ready implementation with all edge cases (yes, there are some more…) handled, see VibeTunnel’s SettingsOpener.swift.

\n

Scene Order Matters (Unfortunately)

\n

While implementing @steipete’s solution described above, I (@matejkob) discovered another gotcha: the order of scenes in your App’s body actually affects whether this workaround functions correctly.

\n

The working example shown earlier has the scenes in this order:

\n
    \n
  1. MenuBarExtra
    2. \n
  2. Settings
    3. \n
  3. Window (hidden)
    4. \n
\n

However, I found that if you arrange them like this (which seems equally logical):

\n
var body: some Scene {\n    MenuBarExtra("My App", systemImage: "star.fill") {\n        ContentView()\n    }\n    .menuBarExtraStyle(.menu)\n    \n    Settings {\n        SettingsView()\n            .onDisappear {\n                NotificationCenter.default.post(name: .settingsWindowClosed, object: nil)\n            }\n    }\n    \n    // Hidden window for settings context\n    Window("Hidden", id: "HiddenWindow") {\n        HiddenWindowView()\n    }\n    .windowResizability(.contentSize)\n    .defaultSize(width: 100, height: 100)\n}\n
\n

The hidden window won’t be “visible” to the SwiftUI environment system (at least not on macOS Sequoia 15.5), and the openSettings() call will fail silently. However, moving the hidden Window scene before the Settings scene makes it work perfectly:

\n
var body: some Scene {\n    // Hidden window for settings context - MUST come before Settings\n    Window("Hidden", id: "HiddenWindow") {\n        HiddenWindowView()\n    }\n    .windowResizability(.contentSize)\n    .defaultSize(width: 100, height: 100)\n    \n    MenuBarExtra("My App", systemImage: "star.fill") {\n        ContentView()\n    }\n    .menuBarExtraStyle(.menu)\n    \n    Settings {\n        SettingsView()\n            .onDisappear {\n                NotificationCenter.default.post(name: .settingsWindowClosed, object: nil)\n            }\n    }\n}\n
\n

This suggests that SwiftUI’s scene resolution and environment propagation happens in declaration order, and the @Environment(\\.openSettings) action in the hidden window needs its context established before the Settings scene is processed.

\n

Whether this is an Xcode build system quirk, a SwiftUI implementation detail, or intended behavior is unclear from Apple’s documentation. What is clear is that the hidden window must be declared before the Settings scene for this workaround to function reliably.

\n

This adds yet another layer of undocumented complexity to what should be a simple operation - not only do we need a hidden window and activation policy juggling, but we also need to carefully order our scene declarations to avoid mysterious failures.

\n

Understanding the Workaround

\n

The hidden window serves multiple purposes:

\n\n

The dock icon manipulation (switching between .accessory and .regular) is necessary because macOS only brings windows to the front reliably for apps with dock icons.

\n

Fin

\n

What should be a one-liner in other frameworks requires careful orchestration in SwiftUI. The combination of MenuBarExtra, Settings scenes, and openSettings wasn’t designed with the unique constraints of menu bar apps in mind.

\n

This shouldn’t be so hard. Opening a settings window is one of the most basic operations any app needs to perform. The fact that it requires hidden windows, activation policy juggling, and precise timing delays in 2025 is a testament to how menu bar apps remain second-class citizens in SwiftUI. Until Apple addresses these fundamental issues, we’re stuck with these workarounds.

\n", "content_markdown": "![](https://steipete.me/assets/img/2025/showing-settings-from-macos-menu-bar-items/hero.png)\n\nOpening a settings window from a macOS menu bar app should be trivial. It’s not. After spending hours debugging, I’m documenting the gotchas to save you the same frustration.\n\n## The Problem\n\nSwiftUI provides [`SettingsLink`](https://developer.apple.com/documentation/swiftui/settingslink) for opening settings:\n\n```swift\nMenuBarExtra(\"Test\", systemImage: \"star.fill\") {\n SettingsLink {\n Text(\"Open settings\") \n }\n}\n```\n\nSimple, right? Except it doesn’t work reliably in [`MenuBarExtra`](https://developer.apple.com/documentation/swiftui/menubarextra). The documentation doesn’t mention this limitation.\n\nAccording to Apple’s documentation, `SettingsLink` should “open the app’s settings scene when activated.” However, this assumes your app is already active and has proper window management context - assumptions that don’t hold for menu bar apps.\n\n## Why It Fails\n\nMenu bar apps operate differently from regular macOS apps:\n\n- **No dock icon by default** - They use [`NSApplication.ActivationPolicy.accessory`](https://developer.apple.com/documentation/appkit/nsapplication/activationpolicy/accessory)\n- **Not “active” in the traditional sense** - They don’t appear in the app switcher\n- **Windows may appear behind other apps** - Without proper activation, windows lack focus\n- **No SwiftUI graph loaded** - Settings needs some SwiftUI view initalized and the menu bar uses AppKit under the hood.\n\nThe root issue is that [`NSApplication`](https://developer.apple.com/documentation/appkit/nsapplication) treats menu bar apps as background utilities, not foreground applications. This affects how windows are ordered and receive events.\n\n## The Evolution of Workarounds\n\n### The Old Way\n\nThis is how it used to work. Private API, but widely used and simple:\n\n```swift\nif #available(macOS 13, *) {\n NSApp.sendAction(Selector((\"showSettingsWindow:\")), to: nil, from: nil)\n} else {\n // macOS 12 or earlier\n NSApp.sendAction(Selector((\"showPreferencesWindow:\")), to: nil, from: nil)\n}\n```\n\nThis stopped working in Sonoma (14) with the error: “Please use SettingsLink for opening the Settings scene.” Apple deprecated these selectors in favor of SwiftUI’s scene-based approach, but didn’t account for the unique challenges of menu bar apps.\n\n### The openSettings Environment Action\n\nApple provides an [`openSettings` environment action](https://developer.apple.com/documentation/swiftui/opensettingsaction) for programmatic access (available since macOS 14.0+):\n\n```swift\nstruct MyView: View {\n @Environment(\\.openSettings) private var openSettings\n\n var body: some View {\n Button(\"Open Settings\") {\n openSettings()\n }\n }\n}\n```\n\nThis currently works on macOS 15, but doesn’t work on macOS Tahoe (26). The logic needs an existing SwiftUI render tree, and simply calling the environment variable does nothing if none is found.\n\nThe workaround? As horrible as it sounds, a *hidden window*. Of course, that comes with its own issues, unless you massage the window that it’s really off-screen and ideally also doesn’t react to touches.\n\n## Hide & Seek\n\nNow, this works, however the window will open in the *background*, and no amount of `makeKeyAndOrderFront(nil)` will help. Trust me. I (and [Claude](https://steipete.me/posts/2025/claude-code-is-my-computer/)) tried plenty variations.\n\nThe real reason? macOS doesn’t allow a window to become selected when there’s no Dock icon. And since it’s common to hide the Dock icon for pure Menu Bar apps, that’s a problem.\n\nThe workaround? Show the Dock icon just before calling `openSettings()` and then hiding it again. In a way, this is also convenient for the user as the Icon now represents the “app” - the visible window, and once that closes, we hide the Dock icon again. (via calling `NSApp.setActivationPolicy(.accessory)`). Of course the whole thing requires some delays to really work, so let me present you the final, working solution (I apologize in advance):\n\n## The Working Solution\n\nHere’s the minimal implementation for macOS 14 and higher, using Swift 6:\n\n```swift\n// Hidden window to provide context\nstruct HiddenWindowView: View {\n @Environment(\\.openSettings) private var openSettings\n \n var body: some View {\n Color.clear\n .frame(width: 1, height: 1)\n .onReceive(NotificationCenter.default.publisher(for: .openSettingsRequest)) { _ in\n Task { @MainActor in\n // Show dock icon for window focus\n NSApp.setActivationPolicy(.regular)\n try? await Task.sleep(for: .milliseconds(100))\n \n // Activate and open\n NSApp.activate(ignoringOtherApps: true)\n openSettings()\n \n // 2. No window ordering - After openSettings(), you might need additional window management to ensure\n // it comes to front:\n try? await Task.sleep(for: .milliseconds(200))\n if let settingsWindow = findSettingsWindow() {\n settingsWindow.makeKeyAndOrderFront(nil)\n settingsWindow.orderFrontRegardless()\n }\n }\n }\n .onReceive(NotificationCenter.default.publisher(for: .settingsWindowClosed)) { _ in\n // Restore menu bar app state when settings closes\n NSApp.setActivationPolicy(.accessory)\n }\n }\n}\n\n// Window identifier for settings\nstatic let settingsWindowIdentifier = \"com.apple.SwiftUI.Settings\"\n\n/// Finds the settings window using multiple detection methods\nstatic func findSettingsWindow() -> NSWindow? {\n // Try multiple methods to find the window\n return NSApp.windows.first { window in\n // Check by identifier\n if window.identifier?.rawValue == settingsWindowIdentifier {\n return true\n }\n \n // Check by title\n if window.isVisible && window.styleMask.contains(.titled) &&\n (window.title.localizedCaseInsensitiveContains(\"settings\") ||\n window.title.localizedCaseInsensitiveContains(\"preferences\")) {\n return true\n }\n \n // Check by content view controller type\n if let contentVC = window.contentViewController,\n String(describing: type(of: contentVC)).contains(\"Settings\") {\n return true\n }\n \n return false\n }\n}\n\n// App structure\n@main\nstruct MenuBarApp: App {\n var body: some Scene {\n MenuBarExtra(\"My App\", systemImage: \"star.fill\") {\n Button(\"Settings...\") {\n NotificationCenter.default.post(name: .openSettingsRequest, object: nil)\n }\n .keyboardShortcut(\",\", modifiers: .command)\n }\n \n // Required Settings scene\n Settings {\n SettingsView()\n .onDisappear {\n NotificationCenter.default.post(name: .settingsWindowClosed, object: nil)\n }\n }\n \n // Hidden window for context\n Window(\"Hidden\", id: \"HiddenWindow\") {\n HiddenWindowView()\n }\n .windowResizability(.contentSize)\n .defaultSize(width: 1, height: 1)\n }\n}\n\nextension Notification.Name {\n static let openSettingsRequest = Notification.Name(\"openSettingsRequest\")\n static let settingsWindowClosed = Notification.Name(\"settingsWindowClosed\")\n}\n```\n\nThe [`NotificationCenter`](https://developer.apple.com/documentation/foundation/notificationcenter) approach decouples the menu action from the window context, allowing the hidden window to handle the actual settings opening.\n\nFor a production-ready implementation with all edge cases (yes, there are some more…) handled, see [VibeTunnel’s SettingsOpener.swift](https://github.com/amantus-ai/vibetunnel/blob/2a63599ce0b09d139ddc9954f41f2a5840264f9f/mac/VibeTunnel/Utilities/SettingsOpener.swift#L4).\n\n## Scene Order Matters (Unfortunately)\n\nWhile implementing @steipete’s solution described above, I (@matejkob) discovered another gotcha: **the order of scenes in your App’s body actually affects whether this workaround functions correctly**.\n\nThe working example shown earlier has the scenes in this order:\n\n1. `MenuBarExtra`\n2. `Settings`\n3. `Window` (hidden)\n\nHowever, I found that if you arrange them like this (which seems equally logical):\n\n```swift\nvar body: some Scene {\n MenuBarExtra(\"My App\", systemImage: \"star.fill\") {\n ContentView()\n }\n .menuBarExtraStyle(.menu)\n \n Settings {\n SettingsView()\n .onDisappear {\n NotificationCenter.default.post(name: .settingsWindowClosed, object: nil)\n }\n }\n \n // Hidden window for settings context\n Window(\"Hidden\", id: \"HiddenWindow\") {\n HiddenWindowView()\n }\n .windowResizability(.contentSize)\n .defaultSize(width: 100, height: 100)\n}\n```\n\nThe hidden window won’t be “visible” to the SwiftUI environment system (at least not on macOS Sequoia 15.5), and the `openSettings()` call will fail silently. However, moving the hidden `Window` scene **before** the `Settings` scene makes it work perfectly:\n\n```swift\nvar body: some Scene {\n // Hidden window for settings context - MUST come before Settings\n Window(\"Hidden\", id: \"HiddenWindow\") {\n HiddenWindowView()\n }\n .windowResizability(.contentSize)\n .defaultSize(width: 100, height: 100)\n \n MenuBarExtra(\"My App\", systemImage: \"star.fill\") {\n ContentView()\n }\n .menuBarExtraStyle(.menu)\n \n Settings {\n SettingsView()\n .onDisappear {\n NotificationCenter.default.post(name: .settingsWindowClosed, object: nil)\n }\n }\n}\n```\n\nThis suggests that SwiftUI’s scene resolution and environment propagation happens in declaration order, and the `@Environment(\\.openSettings)` action in the hidden window needs its context established before the `Settings` scene is processed.\n\nWhether this is an Xcode build system quirk, a SwiftUI implementation detail, or intended behavior is unclear from Apple’s documentation. What is clear is that **the hidden window must be declared before the Settings scene** for this workaround to function reliably.\n\nThis adds yet another layer of undocumented complexity to what should be a simple operation - not only do we need a hidden window and activation policy juggling, but we also need to carefully order our scene declarations to avoid mysterious failures.\n\n## Understanding the Workaround\n\nThe hidden window serves multiple purposes:\n\n- Provides a valid window context for the `openSettings` environment action\n- Allows us to temporarily switch activation policies without visual disruption\n- Gives us a place to handle the complex timing orchestration\n\nThe dock icon manipulation (switching between [`.accessory`](https://developer.apple.com/documentation/appkit/nsapplication/activationpolicy/accessory) and [`.regular`](https://developer.apple.com/documentation/appkit/nsapplication/activationpolicy/regular)) is necessary because macOS only brings windows to the front reliably for apps with dock icons.\n\n## Fin\n\nWhat should be a one-liner in other frameworks requires careful orchestration in SwiftUI. The combination of [`MenuBarExtra`](https://developer.apple.com/documentation/swiftui/menubarextra), [`Settings`](https://developer.apple.com/documentation/swiftui/settings) scenes, and [`openSettings`](https://developer.apple.com/documentation/swiftui/opensettingsaction) wasn’t designed with the unique constraints of menu bar apps in mind.\n\nThis shouldn’t be so hard. Opening a settings window is one of the most basic operations any app needs to perform. The fact that it requires hidden windows, activation policy juggling, and precise timing delays in 2025 is a testament to how menu bar apps remain second-class citizens in SwiftUI. Until Apple addresses these fundamental issues, we’re stuck with these workarounds.\n", "dateCreated": "2026-09-27T19:29:15.293681927+00:00", "date_created": "2025-06-17T11:00:00+00:00", "date_modified": "2025-06-17T11:00:00+00:00", "date_published": "2025-06-17T11:00:00+00:00", "description": "Why something as simple as showing a settings dialog from a macOS menu bar app took me 5 hours to figure out, and requires 50 lines of code for what should be a one-liner.", "external_url": "https://steipete.me/posts/2025/showing-settings-from-macos-menu-bar-items/", "git": { "commit": "ebb0941c5c06a2ab2377342d607535262a3e969e", "path": "items/steipete-me/2025/06/2025-06-17-showing-settings-from-macos-menu-bar-items-a-5-hour-journey.md", "permalink": "https://github.com/aymericbeaumet/aggr-instance/blob/ebb0941c5c06a2ab2377342d607535262a3e969e/items/steipete-me/2025/06/2025-06-17-showing-settings-from-macos-menu-bar-items-a-5-hour-journey.md" }, "id": "urn:aggr:item:88a65b1236a96ab039b1e9155a3ba0a7e927ad2a", "isBasedOn": { "@id": "https://steipete.me/posts/2025/showing-settings-from-macos-menu-bar-items/" }, "mainEntity": { "@id": "https://steipete.me/posts/2025/showing-settings-from-macos-menu-bar-items/", "@type": "CreativeWork", "archivedAt": { "@id": "https://aggr.aymericbeaumet.com/items/steipete-me/2025-06-17-showing-settings-from-macos-menu-bar-items-a-5-hour-journey/#webpage" }, "dateModified": "2025-06-17T11:00:00+00:00", "datePublished": "2025-06-17T11:00:00+00:00", "headline": "Showing Settings from macOS Menu Bar Items: A 5-Hour Journey", "timeRequired": "PT6M", "url": "https://steipete.me/posts/2025/showing-settings-from-macos-menu-bar-items/", "wordCount": 1244 }, "name": "Archived snapshot: Showing Settings from macOS Menu Bar Items: A 5-Hour Journey", "preview": null, "reading_minutes": 6, "replicated_at": null, "source": "steipete-me", "source_name": "Peter Steinberger", "summary": "Why something as simple as showing a settings dialog from a macOS menu bar app took me 5 hours to figure out, and requires 50 lines of code for what should be a one-liner.", "tags": [], "temporalCoverage": "2026-09-27T19:29:15.293681927+00:00", "title": "Showing Settings from macOS Menu Bar Items: A 5-Hour Journey", "url": "https://aggr.aymericbeaumet.com/items/steipete-me/2025-06-17-showing-settings-from-macos-menu-bar-items-a-5-hour-journey/", "word_count": 1244 }