{"id":53121,"date":"2026-09-08T16:12:55","date_gmt":"2026-09-08T20:12:55","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=53121"},"modified":"2026-09-08T16:13:48","modified_gmt":"2026-09-08T20:13:48","slug":"swiftui-toolbars","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2026\/09\/08\/swiftui-toolbars\/","title":{"rendered":"SwiftUI Toolbars"},"content":{"rendered":"

Natalia Panferova<\/a>:<\/p>\n

\n

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.<\/p>\n<\/blockquote>\n\n

Phil Zakharchenko<\/a>:<\/p>\n

\n

The toolbar id<\/code> creates a stable customization domain, and each item id<\/code> gives 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 to NSToolbar<\/code>, these identifiers will be directly translated to the NSToolbarItem<\/code>’s itemIdentifier<\/code>s.<\/p>\n

As we continue the migration to a customizable toolbar, we are likely to encounter a few surprises related to this model.<\/p>\n

[…]<\/p>\n

After a closer inspection, and perhaps a few minutes of digging through the documentation, we come to the bleak realization: there is no customizable ToolbarItemGroup<\/code> API.<\/strong><\/p>\n

[…]<\/p>\n

The regular toolbar model and the customizable toolbar model overlap, but they are not interchangeable. You cannot give a ToolbarItemGroup<\/code> an id<\/code>, and you cannot place one directly inside toolbar(id:content:)<\/code>.<\/p>\n<\/blockquote>\n\n

Majid Jabrayilov<\/a>:<\/p>\n

\n

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.<\/p>\n

[…]<\/p>\n

The final addition to the Toolbar API is the toolbarMinimizeBehavior<\/em> view modifier allowing us to minimize toolbars while scrolling up or down. You can minimize tab, bottom, window and navigation bars with it.<\/p>\n

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.<\/p>\n<\/blockquote>\n\n

Natalia Panferova<\/a>:<\/p>\n

\n

iOS 27 includes a few smaller additions that make toolbar content easier to configure.<\/p>\n

We can remove the default padding around an item whose content should extend to its edges with contentMarginsRemoved(_:)<\/a>[…]<\/p>\n

[…]<\/p>\n

The status bar is now represented by ToolbarPlacement.statusBar<\/a>, so its visibility can be controlled through the same toolbar API as other bars[…]<\/p>\n

[…]<\/p>\n

ForEach now conforms to ToolbarContent, which means we can generate toolbar items directly from a collection[…]<\/p>\n<\/blockquote>\n\n

Natascha Fadeeva<\/a>:<\/p>\n

\n

Together, the toolbar APIs let us express the importance of each action while SwiftUI continues to handle the toolbar’s layout across different sizes.<\/p>\n<\/blockquote>\n\n

Previously:<\/p>\n