Archive for June 18, 2025

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:

SwiftUI at WWDC 2025

What’s new in SwiftUI:

Learn what’s new in SwiftUI to build great apps for any Apple platform. We’ll explore how to give your app a brand new look and feel with Liquid Glass. Discover how to boost performance with framework enhancements and new instruments, and integrate advanced capabilities like web content and rich text editing. We’ll also show you how SwiftUI is expanding to more places, including laying out views in three dimensions.

Is list/table performance actually fixed? The quoted 6x (loading) and 16x (updating) improvements sound good but don’t seem like enough to match NSTableView. The session cites improved scheduling and lazy loading rather than an architectural change. Maybe that’s not possible without changing the API.

Optimize SwiftUI performance with Instruments:

Discover the new SwiftUI instrument. We’ll cover how SwiftUI updates views, how changes in your app’s data affect those updates, and how the new instrument helps you visualize those causes and effects. To get the most out of this session, we recommend being familiar with writing apps in SwiftUI.

Explore concurrency in SwiftUI:

Discover how SwiftUI leverages Swift concurrency to build safe and responsive apps. Explore how SwiftUI uses the main actor by default and offloads work to other actors. Learn how to interpret concurrency annotations and manage async tasks with SwiftUI’s event loop for smooth animations and UI updates. You’ll leave knowing how to avoid data races and write code fearlessly.

Build a SwiftUI app with the new design:

Explore the ways Liquid Glass transforms the look and feel of your app. Discover how this stunning new material enhances toolbars, controls, and app structures across platforms, providing delightful interactions and seamlessly integrating your app with the system. Learn how to adopt new APIs that can help you make the most of Liquid Glass.

Meet WebKit for SwiftUI:

Discover how you can use WebKit to effortlessly integrate web content into your SwiftUI apps. Learn how to load and display web content, communicate with webpages, and more.

Bruno Rocha:

SwiftUI’s performance does seem to be pretty good on iOS 26, at least on the simulator. Seems that all of the table view issues I had with BurnoutBuddy are now gone!

JD Gadina:

So AppKit controls are now just wrappers on some custom/private SwiftUI views on macOS 26 Tahoe?

Daniel Saidi:

After the 6 years that has passed since SwiftUI was first announced, we finally get a native WebView, with some additional web-related tools.

Mario Guzmán:

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.

SwiftUI has a modifier for resizing the window based on the content of the view for the selected tab!

Steve Troughton-Smith:

WWDC25 seems like the least pushy re SwiftUI so far. It seems much more like ‘just another technology’ that you can use in your apps, as it should be, rather than the only way you should be making things.

All of the new UI across the platforms is built with and available to UIKit & AppKit (even if there may be sprinklings of SwiftUI under the hood), and a number of barriers that pushed you to SwiftUI before (like on visionOS) are now open to UIKit.

Seems much healthier!

I don’t know if this is just a temporary pause in messaging, or if the practical realities of SwiftUI have set in now that we’re six years in. It’s great for some things, but it’s not great for everything, and you will always be served well by having a bigger, better, more-powerful framework underneath — whatever that may be in the future

Sarah Reichelt:

I always used to say SwiftUI unless your app needed long form text editing or a list/table with lots of data. With this year’s updates, I’m not sure about either of those limitations, so SwiftUI gets my vote.

Thomas Ricouard:

Remember when SwiftUI launched and we all pretended it was production-ready, and it was. And now it’s been 26 years (but more like five) of SwiftUI and it’s better than ever.

Majid Jabrayilov:

While navigation stacks API didn’t change, the tab navigation provides us with a few new APIs allowing us to improve user experience respecting the new design language. If you still use old TabView APIs, it is a perfect time to refactor your tab navigation. While old APIs also get glassy transformations, the new ones allow us to craft them much better.

Paul Hudson:

Now that you’ve seen everything from SwiftUI 26, what is still missing? What are the key pain points you hit?

Tomas Kafka:

Interaction of drag gestures and scroll view (that I need for scroll/long press and drag to scrub charts in @weathergraph - see below) is still bugridden and requires ugly hacks, some of them even OS version specific.

Previously:

Automatic Observation Tracking in UIKit and AppKit

Peter Steinberger:

Remember when SwiftUI came out and we all marveled at how views automatically updated when @Published properties changed? Well, Apple has been quietly working on bringing that same magic to UIKit and AppKit. The best part? It shipped in iOS 18/macOS 15, but hardly anyone knows about it. You don’t even need Xcode 26, it’s just one simple plist entry away.

[…]

The automatic observation tracking is supported in a variety of UIKit and AppKit methods. For most cases, viewWillLayoutSubviews() in UIKit view controllers, layoutSubviews() in UIKit views, and their AppKit equivalents (viewWillLayout() and layout()) are the go-to choices.

[…]

If you’ve used SwiftUI, you know the joy of @EnvironmentObject - drop an object at the root, access it anywhere. UIKit developers have been jealous of this pattern for years. Well, jealous no more. (Mac devs miss out tho - there’s no equivalent on AppKit yet)

The keys are UIObservationTrackingEnabled and NSObservationTrackingEnabled.

It tracks which object properties are accessed when updating the view and then observes future changes to then to trigger view updates automatically. This sounds great, but it looks like it only handles a view displaying a fixed set of objects. How do you handle changes that affect which objects are eligible to be displayed in the view? I guess it will be like KVO where you need some other way of observing changes so that you know to mutate the array of matching objects, and then that last part can be observed automatically.

Previously:

Copyright © 2000–2025 Michael Tsai.