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

I currently have an iPhone tab view application without iPad views, and I am aiming to add a left-hand bar that summarises content and keeps what is normally a sheet permanently visible. What pattern would work best for this? At present, I pass the view to another view with a navigation stack containing an arrangement view with the previous view and then the sidebar as a secondary view; would that be the appropriate approach?

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?

I know this isn't a developers question per-se, but can you answer the phone when the device is closed?

What’s the best way to make a Grid or LazyVGrid adapt around the fold in book mode? Is there a built-in way to keep grid items from crossing the .division region, or would you normally handle that layout manually?

We use a custom animated tab selector inside the content (matched geometry, per-tab animations) rather than a TabView. On iPhone Duo, is the recommended path to migrate to TabView, or can a custom control like this join the vertical bar via a ToolbarItem with .axisBehavior(.verticalPreferred)? Does such an item get enough height for five or six segments?

I have an iPhone tab view application that has not been designed for iPad, and I am aiming to add a left-hand bar that summarises some content and keeps visible what is normally a sheet. What pattern would work best for this? At present, I pass the view to another view with a navigation stack containing an arrangement view with the previous view and then the sidebar as a secondary view within it—would that be the appropriate approach?

How should an ArrangementView be designed to adapt across the different iPhone Duo display modes, such as closed, opened, and book mode? In some configurations, a horizontally or vertically split ArrangementView appears to display only one of its two child views. The sessions compare ArrangementView to HStack and VStack, but those containers always display all of their child views. Is this behavior expected? If so, how should developers structure an ArrangementView so that its content adapts correctly across the different iPhone Duo display modes?

When using ArrangementView, is it possible to determine which screens are being displayed? Specifically, whether both the primary and secondary screens are being displayed or only one of them?

Our app is a tool, which fits perfectly on one half of an iPhone Duo, and the user can put another app on the other half. We don't have enough content for an iPad or both halves of the Duo. It just doesn't make sense for us. But since we're a tool, the user might want to use our app in conjunction with other apps, and seeing two apps side-by-side is a good usage. We do support device rotation (landscape mode), but mainly for users with bad eyesight who need text to be extraordinarily big and don't want torn apart words. With normal to big font sizes, portrait mode is more useful, otherwise you have lots of unused space but still need to scroll. But the user should be able to use our app in landscape mode, and we should then occupy the upper or lower half of a Duo screen, again leaving space for another app on the other half. "Apps built against a pre-iOS 27 SDK get a compatibility mode" - that's exactly what we want, but we want this also when building with Xcode 27 (and 28...). Or asked the other way: Can we limit our app to being half-width on a Duo even when building against iOS 27.1 SDK?

For a guided flow on iPhone Duo, should the navigation state be modeled independently from how the flow is presented across the two displays? For example, if a flow can move from Screen 13 back to Screen 8, how should we think about the navigation path when the user changes between different Duo arrangements?

Will the App Store surface apps that are optimised for iPhone Duo, for example a badge, a filter or editorial placement? And is "optimised" decided just by building against 27.1, or by something else? Will App Store Connect require dedicated iPhone Duo screenshots for the outer and inner displays?

Is there any API to customise how navigations bars hide on scroll on a iPhone Duo when the device is folded?

The iPhone Duo provides varying space for toolbar items based on screen orientation. One approach uses .visibilityPriority(_) to keep higher-priority items visible longer as the window shrinks and items go to the overflow menu. For instance: .toolbar { ToolbarItem { SecondaryControl() } ToolbarItem { PrimaryControl() } .visibilityPriority(.high) } The problem is that .visibilityPriority(_) requires iOS 27 or later, while typical apps aim for older systems such as iOS 26. What is your solution to keep the code simple?

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?

We have a fairly complex app that needs to support iOS versions all the way back to iOS 15. For the Duo, it makes sense to host the app's UI in a UISplitViewController. However, given the compressed timeframe and not wanting to cause regressions for those not running on an iPhone Duo, we would like to keep our existing UINavigationController hosted UI for those devices. Eventually, we will move everything over to UISplitViewController, but with only a month to do this, having two separate paths makes sense for now. The hosted views themselves are already resizable and have been since day one as we also support iPad and Mac, though those use a 3-pane split view (the Duo version will only use a two-pane split view). So far the only way I've been able to work out if we're running on the iPhone Duo is to create and show an instance of our launch screen in scene(_, willConnectTo:, options:) in our scene delegate, then dispatch a validation method on main to see if one of the side safe area insets becomes non-zero. After that, I can stand up the correct host view controller. This seems like a risky approach, so I'm hoping someone has come up with something better or there is an API that I overlooked. Any guidance on this would be much appreciated.