SwiftUI Toolbars
I thought it would be useful to have a single reference for the different ways we can style the toolbar in SwiftUI on macOS 26.
The toolbar
idcreates a stable customization domain, and each itemidgives the framework something stable to persist when the user adds, removes, or reorders controls. This identifiability of toolbar items is a requirement for customization. Under the hood, when SwiftUI inevitably bridges your toolbar contents toNSToolbar, these identifiers will be directly translated to theNSToolbarItem’sitemIdentifiers.As we continue the migration to a customizable toolbar, we are likely to encounter a few surprises related to this model.
[…]
After a closer inspection, and perhaps a few minutes of digging through the documentation, we come to the bleak realization: there is no customizable
ToolbarItemGroupAPI.[…]
The regular toolbar model and the customizable toolbar model overlap, but they are not interchangeable. You cannot give a
ToolbarItemGroupanid, and you cannot place one directly insidetoolbar(id:content:).
Let’s take a look at another example. This one is a bit tricky, because on macOS, you will get Action 1 in the top trailing position and the whole group of actions centered in the navigation bar. On iOS, you will get Action 1 pinned to trailing and all other items collapsed.
[…]
The final addition to the Toolbar API is the toolbarMinimizeBehavior view modifier allowing us to minimize toolbars while scrolling up or down. You can minimize tab, bottom, window and navigation bars with it.
With new modifiers SwiftUI gives us a much better balance between system-driven adaptation and explicit control. We can now decide which actions are more important, which items should always stay visible, which groups should intentionally live in the overflow menu, and how toolbars should react to scrolling.
iOS 27 includes a few smaller additions that make toolbar content easier to configure.
We can remove the default padding around an item whose content should extend to its edges with contentMarginsRemoved(_:)[…]
[…]
The status bar is now represented by ToolbarPlacement.statusBar, so its visibility can be controlled through the same toolbar API as other bars[…]
[…]
ForEach now conforms to ToolbarContent, which means we can generate toolbar items directly from a collection[…]
Together, the toolbar APIs let us express the importance of each action while SwiftUI continues to handle the toolbar’s layout across different sizes.
Previously:
- NSToolbar in Golden Gate
- SwiftUI in appleOS 27
- Golden Gate Window Corners
- Golden Gate Sidebars and Toolbars
- Where Did SwiftUI Leave You Hanging?
- Liquid Glass: Content vs. Controls
1 Comment RSS · Twitter · Mastodon
Apple’s attitude with SwiftUI needs to be more along the lines of: “port every existing feature/API to SwiftUI”, and not as much “whenever we feel like it, as YEARS go by, we add random stuff that sort of fill in some things people need (and we will just randomly break it from time to time)”.
In my view it will not be a serious framework until this happens.
Every bug is a step back, every random API is a step forward *if* it is something you need, otherwise it means nothing. So the formula for multi-year releases is like X steps forward, Y steps sideways, Z steps back, where Z is never 0 and X is never big enough.
