Apple has filled in some of the holes that make SwiftUI awkward for polished Mac apps, according to developer Paulo Andrade, but the framework still leaves developers stitching together behavior that AppKit has handled for years.
Andrade published an update after WWDC 27 following a widely shared critique of building what he called a “Mac-assed” app in SwiftUI. He said an Apple engineer contacted him after that earlier post, the two exchanged emails, and Andrade filed several feedback reports with Apple.
The first correction is one Andrade said he missed: SwiftUI already exposes an environment value called backgroundProminence. Apple’s documentation says views such as List and Table, along with standard styles such as selection, update that value automatically as selection emphasis changes.
That gives developers something close to the custom “is emphasized” state Andrade had proposed for selected rows. His caveat is the predictable one: developers building heavily customized interfaces often are not using SwiftUI’s List or Table in the first place. In those cases, Andrade said apps still need to track focus themselves and pass that state through the environment. Reusing Apple’s existing environment value, he argued, should make custom rows behave better if they later end up inside List or Table.
Andrade also filed FB23095823, asking Apple to expose more List behavior for custom rows. He framed the request as an attempt to bring SwiftUI closer to the flexibility developers get from AppKit and UIKit cells.
Drag and drop gets a missing hook
The largest concrete change Andrade highlighted is a new SwiftUI API, onDragSessionUpdated, introduced for Apple’s 27 operating-system releases and, according to him, apparently already present on macOS 26.
Andrade said he has not tested the API yet, so treat this as a reading of the documentation rather than a field report. On paper, he said, it gives SwiftUI developers visibility into a drag session from the beginning. That should let an app update its interface when dragging starts and clean up when dragging ends, including cases where the user drops outside the original view.
That sounds dull until you have built drag and drop on the Mac. AppKit has long exposed enough session state for this kind of cleanup. SwiftUI, by Andrade’s account, has been missing the practical hook that lets an interface avoid getting stuck in a half-drag visual state.
He also pointed to a new reorderable modifier in the 27 releases for developers who only need item reordering. Andrade said his own apps usually support the two most recent major operating-system versions, so he expects to wait about two years before relying on the new drag API.
Keyboard and menu gaps remain
SwiftUI’s keyboard story still has a platform wrinkle. Andrade said onMoveCommand, an API that expresses movement intent rather than raw key presses, remains unavailable on iOS. Developers can use onKeyPress instead, including on macOS, but Andrade argued that this is the wrong level of abstraction for arrow-key navigation.
He initially suspected the iOS omission reflected missing UIResponder selectors, then noticed that onMoveCommand exists on tvOS. Andrade filed FB23095985, arguing that the same API should exist on iPadOS, where hardware keyboards are common.
Two other complaints are still open. Andrade filed FB23097100 asking for a way to know when a context menu is open, and FB23102836 seeking improvements to SwiftUI’s toolbar API.
For context menus, Andrade said macOS apps need enough state to draw their own target indication during the interaction, unlike iOS, where the system can visually lift the item. WWDC 27 also brought a toolbar visibilityPriority modifier to control which toolbar items move to overflow first, but Andrade said that does not address the toolbar problem he filed with Apple.
This story draws on original reporting from Daring Fireball.