Wednesday, June 18, 2025

Showing Settings From macOS Menu Bar Items

Peter Steinberger (Mastodon):

SwiftUI provides SettingsLink for opening settings[…] Simple, right? Except it doesn’t work reliably in MenuBarExtra. The documentation doesn’t mention this limitation.

[…]

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.

[…]

Apple provides an openSettings environment action for programmatic access (available since macOS 14.0+)[…] 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.

[…]

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.

Brian Webster:

Anyone who’s done any amount of SwiftUI on the Mac would not be at all surprised at the amount of hoops required to jump through for things that seem like they should be quite simple.

Previously:

Update (2025-06-19): See also: Rosyna Keller.

2 Comments RSS · Twitter · Mastodon


> Anyone who’s done any amount of SwiftUI on the Mac would not be at all surprised at the amount of hoops required to jump through for things that seem like they should be quite simple.

SwiftUI people will put up with so much crap like this and celebrate nothing features at the same time as huge wins. Just read this quote “So this is new in #SwiftUI! In AppKit, it was a paaaaaain to have your Settings window animate from tab to tab based on the view’s content. Some developers (even Apple) wouldn’t bother to do it in some apps.” in https://mjtsai.com/blog/2025/06/18/swiftui-at-wwdc-2025/

I don’t get it.

.


What is there to get? When you never bother to learn a framework, it seems "paaaaaain". And when you only have a single hammer, everything looks like a nail. So they think SwiftUI is amazing, and any issue they come up with, they don't know any better, so they think every other framework has the same issues. Same with "full" "stack" web devs that only know JS, who think every ecosystem is as broken as npm and node.

No idea why Peter decided to go all in on SwiftUI, on macOS no less, but I suspect this is the only framework popular enough to give him AI slop options. This is how he prefers to code these days. 🤷‍♂️ At least he has the depth and knowledge to reach for other solutions if/when push comes to shove. But for a generation of SwiftUI "purists", they are just lost.

Leave a Comment