iPhone Duo UIKit Q&A

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?

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, 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?

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) ?

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.

It would be great if Apple could provide a sample app covering all the cases for iPhone Duo, an app that follows best practices when it comes to handling UI and works on normal iPhones, iPhone Duo and iPad. Also if I remember correctly it's been a long time since we got a UIKit sample app.

When the inner camera is in use and the reserved region becomes active, what is the recommended way for apps to adapt their UI? Should content move out of the reserved region where possible, or is it generally acceptable to leave content behind it? More specifically, how should apps handle content that can’t easily move aside, such as a long navigation title directly behind the reserved region? Should it be truncated, moved below the region, or handled another way?

We have built our existing app with Xcode 27.1 and when running it on iPad it does not resize - it seems to run in iPhone mode as usual, in a fixed portrait mode. However the same build will resize to a wider aspect ratio in iPhone mirroring (and on Duo, obviously) But, the app when built with Xcode 27 does resize on an iPad. So is the 27.1 iPad behaviour expected or is this just something temporary in the 27.1 beta?

When the user transitions from an open to a partially folded state, the system detects this is the final state after some delay and un-blurs the left side. The UI should now adapt to this state. For example, split view controller enlarges the sidebar to occupy the full width of the left side. What’s the best trigger to use for a custom view controller that wants to achieve a similar result? Is it the folding region becoming active?