I recently redesigned an ISP management app where the Home screen is intentionally designed around a single iPhone display: connection status, billing, support, promotions, and navigation are arranged in a compact vertical hierarchy. On iPhone Duo, simply expanding this layout would introduce a lot of empty space and make some of the cards unnecessarily large. But completely redesigning the Home screen for Duo could also make the experience inconsistent. What would you recommend as the design approach here? Should we recompose the Home screen for the additional space, or is it sometimes better to intentionally keep a phone-optimized content width even when more space is available?

Hi,I'm trying to implement undo and redo, in a Custom keyboard extension. However, calling undo() on the UndoManager from UIInputViewController, doesn't seems to work. Is there any other way of getting the UndoManager from the app the keyboard is connected to?Or do I need create my own logic to store what a user has written?

If the Duo goes from a closed to open and vise versa does the ScenePhase get called?

Our adaptive split layout currently pins the posture to .flat because we could not find the supported way to read the device's fold state. What is the recommended SwiftUI API for observing fold posture and hinge geometry on iPhone Duo, and does it report correctly in the simulator as well as on device? We also want to know whether the hinge region is exposed so we can keep content out of it.

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?

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?