iPhone Duo UIKit Q&A

Configuration: Xcode 27.1 (27A9269) iOS 27.1 Simulator (24A94401), iPhone Duo macOS 27.2 (26B5086k) On iOS 27.1, when the vertical bar is on the leading edge, UINavigationController adds a leading safe area inset for the vertical bar (84 pt on iPhone Duo outer display) that the window itself does not have. Bar layout guides (UIView.layoutGuide(for: .bar(onEdge:extent:))) requested from any view inside the navigation controller are then resolved against that inset instead of the actual bar strip: Left-edge bar guides are pinned to x = 84 (the inner edge of the inset) instead of being centered in the vertical bar strip. Top/bottom bar guides start at x = 84. This part matches the mirrored trailing-edge behavior. The same guides requested from a view outside the navigation controller (the window's root view) put the left-edge guides correctly inside the strip, centered at x = 48. They are exact mirrors of the trailing-edge results. With the vertical bar on the trailing edge, everything is consistent: the window itself carries the 84 pt trailing inset and an active occlusion reserved region for the vertical status bar, and guides are identical whether requested from inside or outside the navigation controller. So the leading and trailing configurations are asymmetric. With a trailing bar, the vertical-bar inset lives on the window. With a leading bar, it exists only on UINavigationController's content, and the bar layout region math appears to treat it as an ordinary safe-area inset to avoid rather than as the bar strip. This happens with the navigation bar hidden via setNavigationBarHidden(true, animated: false). (Hiding it by setting navigationBar.isHidden = true additionally shifts the top guides down, which we assume is expected since the controller still considers the bar visible.) Steps to reproduce: Build and run the attached sample on the iPhone Duo simulator (iOS 27.1), outer display, portrait. Put the app in the configuration where traitCollection.verticalBarEdge == .leading. With "Plain root" selected, note the yellow (left-edge) bar guides: 22/44/88 pt bands share one center line inside the leading strip. Tap the center button and select "UINavigationController" (the navigation bar is hidden with setNavigationBarHidden(true, animated: false)). Observe the yellow bands and check the console output (lines prefixed with [BarLayoutGuidePlayground]). Repeat steps 3–5 with verticalBarEdge == .trailing and compare the green (right-edge) bands. Expected results: Bar layout guides resolve the same way for leading and trailing vertical bars, and the same way whether the requesting view is the window root or a child of UINavigationController. With a leading bar, the left-edge guides should be centered in the vertical bar strip (x = 37 / 26 / 4 for extents 22 / 44 / 88 in a 469 pt wide window), mirroring the trailing results (x = 410 / 399 / 377). Actual results: With a leading bar, inside UINavigationController: view.safeAreaInsets = (top: 0, left: 84, bottom: 34, right: 0) window.safeAreaInsets = (top: 0, left: 0, bottom: 34, right: 0) left 22: (84, 16, 22, 619) left 44: (84, 16, 44, 619) left 88: (84, 16, 88, 619) top 22: (84, 37, 376.33, 22) Same guides requested from the window's root view: left 22: (37, 16, 22, 619) left 44: (26, 16, 44, 619) left 88: (4, 16, 88, 619) top 22: (16, 37, 444.33, 22) With a trailing bar (identical from both views): view.safeAreaInsets = (top: 0, left: 0, bottom: 34, right: 84) window.safeAreaInsets = (top: 0, left: 0, bottom: 34, right: 84) occlusion reserved region (active): (385, 0, 84, 120) right 22: (410, 120, 22, 515) right 44: (399, 120, 44, 515) right 88: (377, 120, 88, 515) top 22: (8.67, 37, 376.33, 22) With a leading bar there is no active occlusion region for the status bar, and the window has no leading inset, yet UINavigationController adds one. Sample project

Hi I want to open a modal sheet so it's centered when the iPhone Duo is opened, but on the right side of the screen (trailing) when it's half-closed. But it seems like the "placement" property of the sheetPresentationController applies in all configurations. Is there a way to set a placement "order" (centered if possible, then trailing, then leading) ?

With the default mode of .automatic, the inner display shows a sidebar instead of a bottom tab bar. The sidebar draws UIKit’s dimming view over the selected view controller, which hides our map. We force mode = .tabBar on iOS 18. Is a bottom tab bar on the Duo inner display supported, or is the sidebar the intended phone-unfolded layout?

UITabBar measures titles on the first layout pass. After unfolding, the bar is much wider but labels stay truncated with an ellipsis until the user switches tabs. Reapplying standardAppearance does not rebuild the buttons. Is there a public API to invalidate tab-item title measurement when the bar’s width changes?

On unfolding, our app's horizontalSizeClass becomes .regular, and UITabBarController automatically promotes to the iPadOS-style sidebar. We suppress this with mode = .tabBar (iOS 18+) and sidebar.preferredPlacement = .tabBar / sidebar.preferredLayout = .tile (iOS 27+) to keep a bottom tab bar. Is this the correct/recommended approach for a foldable iPhone's inner display, or is there a foldable-specific tab bar mode we should be using instead?

Our app declares TARGETED_DEVICE_FAMILY = 1 (iPhone only), yet the unfolded inner display presents a .regular horizontal size class identical to iPad's, and our project also carries a leftover INFOPLIST_KEY_UISupportedInterfaceOrientations_iPad override. Does Apple recommend/require declaring iPad as a supported family for apps that want to support this device properly, or is "iPhone-only + regular size class" the intended long-term model?

I have a floating bottom right button in my app (similar to twitter/x's blue compose button). I have no tab bar. When moving to the duo, this floating button now appears to the left of an empty tabbar/toolbar area on the right of the device. Ideally I want it to be inside the new tabbar/toolbar area when on the duo, as otherwise its wasted space. Is there anything new/inbuilt that I can leverage to manage this? Can I put my button into some container somewhere so that its the bottom right of the screen on an iPhone and automatically move to the toolbar area on duo? Something like a single item, right aligned, tabbar would be a great option. But the new liquid glass tabbar comes with too many restrictions on colors/styling I'm trying to find a way to avoid having logic like this in the app, as device specific logic becomes a maintenance issue int he future: if device == duo { // create toolbar button } else { // create button button and appen } d to window

What is the recommended way if you have a UITableView and you want to move the first cell (complex chart) on the inner display to the left side of the layout and all the other cells on the right side. There are many ways to do that, but what would you recommend?

Hi, For iPhone Duo, is there updated guidance about using container view controllers inside other container view controllers? For example, using UISplitViewController as the root view controller inside a UITabBarController tab (and doing this for multiple tabs)?

It seems that UITabAccessory creates its own constraints. What are the dos and don’ts in terms of constraints within the accessory view for iPhone Duo ?

For it to work correctly on iPhone Duo in all poses, is the best practice to size the contentView of UITabAccessory to override intrinsicContentSize with width set at UIView.no IntrinsicMetric and height set to a relevant value ?

For the preferredVerticalBarBehavior, docs say to "treat it as a stable choice: avoid changing it frequently as the user navigates, and don’t toggle it for a single view controller as a function of that view’s state. To hide the bars and status bar on a given screen rather than change the layout, use the visibility APIs instead." I'm wondering if that's supposed to apply to size class changes as well. On the simulator, Safari displays the vertical bar in compact widths but seems to set it to .disabled when in regular width (ie, the bar is in horizontal position when the app is displaying fullscreen on the inner screens). Is it OK to follow that example in our own apps?

During a fold, UIScreen.main.bounds stays at the outer-display size while window.windowScene?.screen.bounds updates. Layout that still reads UIScreen.main (sheet heights, map padding, title widths) is wrong on the inner display. Should apps stop using UIScreen.main entirely and always read the window scene’s screen?

What's the recommended way to detect that the app is running on an iPhone Duo?

If i'm going to implement a custom vertical bar – how do i arrange for that? Any good doc / instruction?

Hello UIKit team, When building custom multi-column layouts with UICollectionViewCompositionalLayout that must dynamically span or split across the iPhone Duo's .division reserved region during continuous hinge motion: What is the recommended strategy for handling UICollectionViewLayoutInvalidationContext during live fold/unfold gestures? Specifically, does the system coalesce intermediate trait changes (registerForTraitChanges) to allow smooth orthogonal scrolling without constantly purging cached layout attributes or triggering full cell rebinds? When adapting custom container view controllers using viewWillTransition(to:with:), should we coordinate layout updates through the UIViewControllerTransitionCoordinator's animate(alongsideTransition:), or does UIKit provide a dedicated layout guide / accessory pipeline that guarantees zero hitch when the trailing/leading safe area insets flip dynamically around the physical crease? Thanks!

If we have create a custom Navigation back item, while running on iPhone Duo simulator, we see it at normal position i.e. on screen's top left side. How can we move it to the safe area like when we use default back button?

I use an icons-only UISegmentedControl in the toolbar. For iPhone Duo, I’d like to place this segmented control in a vertical layout in the righthand control area. How can I achieve that?

I’m using a UITabBarController with fixed UITabs and sidebarOnly UITabs, on an iPhone Duo I’m seeing the sidebarOnly tabs show up regardless of sidebar.preferredPlacement. Is this expected? I’m trying to achieve the same behavior as the Health app as shown in the developer videos. I have a feeling that I might need to check for the horizontal size class, but I feel like the API should be doing the work of hiding the sidebarOnly tabs, no? Also, when setting tabBarController.sidebar.preferredPlacement = .sidebar and collapse it I don’t see the sidebar when I collapse on the inner display using Xcode 27.1. I think this is a bug?

We ship a large production app that mixes UIKit and SwiftUI. We're planning our iPhone Duo support, but until we adopt the latest SDK, we want to understand how compatibility mode applies to our current builds. Is there a canonical way to preview our app in compatibility mode across all iPhone Duo poses? We can build with Xcode 26.6 and run on the iPhone Duo simulator, but we can't switch poses and it's unclear whether that matches the real compatibility mode on device. We'd like to see how the app responds to each pose so we're confident in the experience users will get at launch.