Hi, I’m Anna, and I’m an engineer on the UI Frameworks team. And I’m Maria, a Human Interface Designer working on Apple’s design system. Wait, why am I here? Every designer is an engineer, and every engineer is a designer. You need to understand both to build a great app.

Today, Anna and I are going to teach you how to raise the bar for your bars on iPhone Duo. iPhone Duo is Apple’s first multi-display iPhone, giving people the freedom to use it in the way that feels right for the moment. And you’ll notice right away, it’s different, introducing a new, distinct silhouette. And that shape matters. The wider aspect ratio gives your apps more horizontal space to work with.

To make the most out of that width and preserve vertical space for content, controls that normally sit at the top and bottom, move to the side, where they’re also easier to reach. This new design maximizes space for vertical content on the outer display. And their position remains consistent when you open iPhone Duo to the inner display and landscape. But as you open the device in portrait, the larger display returns to a familiar iPhone layout with horizontal bars.

And remember, these are the same components, just adapted to a different layout. Now that you understand the principles behind it, here’s a few things to keep in mind when designing and implementing great bar experiences on iPhone Duo. First, we’ll help you orient to a new axis and take your bars vertical on iPhone Duo. Next, we’ll discuss item ordering and how it interacts with different containers. After that, we’ll share how you can tailor toolbar content for a vertical axis. Finally, we’ll highlight how to manage the overflow menu.

But Anna, before we get into that, Can I show you the app that I’ve been working on? Totally. So I’ve already done the work to make it resizable. However, my bars are still horizontal. Am I missing something? I got you, Maria. To opt your app into the new bar behavior, there are a few things you’ll need to do.

First, rebuild your app against the latest SDKs. Now Maria’s app is ready for iPhone Duo. For more details on what other behaviors are enabled when you rebuild, check out “Prepare Your App for iPhone Duo”. Next, make sure you’re using the bars provided by navigation containers like tab view or navigation stack. In SwiftUI, pair the toolbar modifier with containers like NavigationStack or NavigationSplitView.

In UIKit, prefer using UINavigationController and UITabBarController which manage their own bars. For example, set toolbar items on a view controller and place it into a navigation controller rather than creating a custom UI toolbar. When used to build custom bars, content from sub-components like UIToolbar, UINavigationBar, or UITabBar won’t be considered.

Now that you know how to allow bars to move vertically in your app, I’m going to dive deeper into how its content is placed. iPhone Duo allows navigation, toolbar, and tab bar controls to coexist within a shared region. A helpful way to think about it is to imagine rotating 90 degrees into a vertical stack.

Depending on your layout, it may contain different combinations of these items. Here in Notes, the layout uses a toolbar, while in Clock, the layout includes a tab bar. And in Fitness, the layout uses both a toolbar and a tab bar. In more complex layouts, toolbar items can only move vertically when their container is positioned along the display edge. In split views, only the detail column participates. Items from other columns remain horizontal. And since detail columns already have a vertical bar, inspectors don’t receive their own when expanded to avoid confusion.

On the outer display, if your sheets already have a toolbar, it’s displayed vertically. On the inner display, they’re centered by default, and items remain horizontal. When you use the PreferredPlacement API to change their position, sheets placed on the left remain without a vertical bar, while sheets placed on the right receive one. And because the bar is aligned with the hardware, it stays on the same side of the device and right to left languages. The content adapts around it while the bar itself remains fixed.

In summary, while it might be tempting to change the axis for all your controls, keep them associated with their container. When displayed vertically, items retain a clear top to bottom hierarchy. Start by auditing your existing toolbar configuration, making sure that controls follow the recommended order. Reserve the top for primary navigation controls, like back or close, followed by prominent actions, such as done.

If you’re using a navigation controller, the back button is added automatically. For custom back or close buttons, use the cancellation action placement in SwiftUI. And in UIKit, use a leading item and make sure leftItemSupplementsBackButton is set to false, which is the default. leftItemSupplementsBackButton? Who named that API? Wasn’t me. For prominent actions, place them using the topBarPinnedTrailing placement in SwiftUI or pinnedTrailingGroup in UIKit. Remaining items preserve their original grouping with a vertical spacer visually separating top and bottom placements even when unified into a single bar.

And remember, not every pose lays out bars vertically. Keep control placement consistent so people don’t have to relearn where actions live as they use iPhone Duo. Now that you know where items are placed, let’s make sure your toolbar content is ready. You may be familiar with bars that lay out your items horizontally. Now, iPhone Duo turns that on its side.

Unlike horizontal bars, where items have a fixed height and allow flexible item width, vertical ones allow flexible item height and have a fixed width. This makes vertical bars better suited for symbol-only item representations. Typically, your app specifies two pieces of data on your toolbar content, an icon and a title.

Depending on the context and what’s specified on the item, the system then chooses what representation to show. When items are visible in the existing top and bottom bars, they prefer showing the icon, like the share button here. If there’s no icon, like the edit button, they show the text. When items move into the overflow menu, they show both the title and the icon.

None of this is changing with vertical bars. You still specify the same content and place the same items into a horizontal bar. The difference is the system now also considers whether your content is better suited to be on a vertical or horizontal axis. Items with an icon, like the back and share buttons in this example, change their axis to be vertical.

And text-only items, like the edit button, continue to stay on the horizontal axis. If you’re already setting the title and image by using a SwiftUI label or the properties on UIBarButtonItem, you’re well on your way to getting ready for vertical bars. In general, you want to provide all the information about your items up front and let the system pick the right representation for the context.

This means that even if your content is an image, it’s still important to provide a title. Just like for horizontal bars, the system uses it whenever an item moves into an overflow menu or an expanded form. By default, SwiftUI and UIKit infer where to place the item based on its content, like if it’s an item that’s text only or a symbol in text. If you need to adjust this default behavior, there’s a new AxisBehavior API.

You use it in a few different situations. Related items should stay on the same axis. One common instance is an item that transitions between a symbol and a text, like this edit button in Clock. That item shouldn’t be placed in a vertical bar, even though the symbol could theoretically be displayed vertically.

If you’re using the system edit button, you’re all set. It stays in the horizontal bar automatically. If you’re creating a custom item that transitions between symbol and a text, use the horizontal only axis behavior like this custom select button does. On the other hand, if your view is a custom view in UIKit or a more complex view in SwiftUI, the system keeps it horizontal. If your custom view does support a vertical representation, like the compass view in the top right, set the vertical preferred axis behavior to allow it to go into a vertical bar.

Minimize title-only items or custom views that show both text and an image so more content can go vertical. In most situations, these are good candidates to use their symbol representation. For example, rather than keeping the count in line, I can use a badge on the inbox to turn an item that displays both text and a symbol into a symbol-only item that feels at home in a vertical bar.

If you aren’t already using the badge API that was added in iOS 26, adopt it to get a system standard badge appearance on all devices. A helpful way to evaluate whether the custom view needs the text is to ask: is it simply reinforcing the symbol, or does it carry standalone information? If the text is just supplementary, the symbol alone will usually clearly communicate the action. However, if the text does contain meaningful information, like a cart button displaying a total dollar amount, it’s better to keep the control in the horizontal bar.

Lastly, accessory bars should remain attached to the keyboard rather than moving to the vertical axis. Custom views require a bit more work to get them ready to be laid out vertically. When you opt items in, make sure they either fit the bars fixed width or have a vertically adapted layout. Consider if any metric should be adjusted for the vertical representation. For example, this custom action panel hides its titles and becomes slightly shorter when vertical to allow more room for other content.

For custom views in particular, you might want to make changes when a vertical bar is present. To know that, read the toolbarVerticalEdge, environment property, or trait. You can read it both within the content view or inside your item’s custom view. The value is populated when items can be on the vertical axis, and nil or unspecified when and they can’t.

Just like horizontal bars, a vertical bar doesn’t have a scroll edge effect by default. However, it does have a background when the reduced transparency accessibility setting is enabled. Make sure your custom view content stays legible regardless. By default, flexible spacers are zero size in the vertical axis. But fixed spacers continue to respect their minimum size. Your app shouldn’t be creating additional spacing, regardless of if a bar is horizontal or vertical.

Maria, didn’t you talk about this in your video for WW25? Yes, I did. Thanks for watching. If your app hasn’t already updated its bars to the new design or grouped individual items along the leading and trailing edges yet, now’s the perfect time. Lastly, let’s talk about managing overflow.

On the outer display in landscape, items overflow more often simply because there’s less vertical space. The bar may also need to overflow as other competing UI appears, like the keyboard or when using picture-in-picture in open portrait. The first decision is which should stay visible longer, your toolbar items or your tab bar.

In navigation-focused experiences, like this Podcasts view, the toolbar compresses first, so primary destinations remain accessible. This is the default behavior. In task-oriented experiences, like this view from the Games app, the tab bar compresses first to preserve frequently accessed actions. Use the toolbar compression behavior API to configure your app’s preference for each view.

From there, toolbars need a little more consideration. With more items to manage, you’ll also need to prioritize what stays visible. If your app already has its own overflow, consolidate its actions into a single system-managed menu. You can do that using the ToolbarOverflowMenu in SwiftUI or the additionalOverflowItems in UIKit.

And not every existing menu should become an overflow. The ellipses is the standard overflow symbol on iPhone. Reserve it for that purpose rather than introducing symbols from other platforms and give other menus a distinct symbol. To keep the right content visible for longer, make sure to express your preferences to the system. If you’ve prioritized the tab bar or your toolbar exceeds the available space, items will begin moving into the overflow menu. Toolbar visibility priority gives you fine-grained control over which ones remain visible.

By default, items overflow from bottom to the top, but you can also assign each item a high, low, or even a custom visibility priority to control the order in which they collapse. Within your items, start giving priority by groups. Then prioritize items within each one if you need to. Use the visibilityPriority APIs in SwiftUI and UIKit to configure this priority. And check out what’s new in SwiftUI from WWDC 26 to learn more.

When assigning visibility priorities, think about what items people need to access most often. Frequently used actions like Compose in Mail or New Note in Notes should be amongst the last to move into overflow. Likewise, controls that convey important status, such as items with badges, should remain visible for longer to preserve glanceability.

Maria, I get why bars are laid out vertically now, but should they be vertical everywhere? Most apps are good candidates. However, there are a few cases where your app may want to disable this behavior. If your app is a single page app with a bottom heavy layout like calculator, consider if a horizontal layout might allow the content to fully expand. Similarly, if a sheet is control heavy only one item, like the close button here, consider disabling a vertical bar so it doesn’t reduce available space. Use the toolbarVerticalBehavior and preferredVerticalBar behavior APIs to disable this.

It started with a pretty simple question. What if bars didn’t have to be at the top and the bottom? Spoiler, they moved. To the side. Not that far. It keeps the content feeling spacious while keeping controls accessible. The same familiar experience made for an entirely new iPhone. To get your app ready, the first step is building your app with the latest SDKs. Audit the bars in your app and ensure that they’re ready for the new design. Update any custom items so they’re ready to be placed vertically. And make sure to assign overflow priorities so the system can adapt. Anything else? It’s in the overflow menu. See you soon!