iPhone Duo SwiftUI Q&A

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?

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?

The Duo simulator boots showing only the outer display: the window is fixed at 382×644 pt and our layout classifier always reports the compact stack mode. We measured this on two separate clean boots (shutdown, erase, boot). xcrun simctl help lists no subcommand for folding, posture, or selecting the inner display — we read the full list. xcrun simctl io screenshot does reveal a second display (LCD-1, 2007×2853 px, aspect 0.70, close to the 669×951 inner portrait size). Unfolding manually in the Simulator UI works and the app then renders the two-column layout correctly, but we could not find a programmatic equivalent. Is there a supported way to unfold a Duo simulator from the command line or from XCTest?

Is it necessary to replace GeometryReader and containerRelativeFrame in preparation for iPhone Duo support? If so, could you let me know the best way to do it.

When using safeAreaBar, what’s the best way to keep its content on just one side of the fold in book mode? Would you recommend using the .division reserved region to adjust the layout manually, or is there a more built-in SwiftUI approach?

We exercise four layout modes in our SwiftUI app and need to drive them in UI tests. While a scene is resized live via xcrun devicectl device appResize, XCUITest's accessibility snapshot appears to carry a stale scale. With 951×669 requested, app.windows.firstMatch.frame comes back as {317, 223}, which is inconsistent with the app's own reading of its window (951×629 from our debug readout). Individual element frames are similarly tiny (a text label reports 2.9×0.9 pt). As a result .tap() appears to target the right element but the sheet never opens. We verified this with debugDescription dumps across two separate attempts, on clean boots. Is this a known limitation of XCUITest during live scene resizing, and is there a supported way to force the accessibility snapshot to refresh after a resize?

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?

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.

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?

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?

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?

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

Our app performs security checks (compromised-device detection, certificate pinning setup) once per app launch inside SceneDelegate's willConnectTo:options: and on scene-becomes-active. Given developer coverage states every app participates in iPhone Duo's multi-window support whether it opts in or not, and each window is presumably backed by its own scene/SceneDelegate instance: does opening a second window on the inner display spawn an independent scene that would re-run (or fail to run) this per-scene setup? For an app with security checks tied to scene lifecycle rather than app-level AppDelegate lifecycle, is there existing guidance on whether such checks should run per-scene, be coordinated across scenes via a shared app-level state, or whether Apple recommends opting out of multi-window support entirely for apps where per-window security state doesn't make sense (e.g. a single authenticated session shouldn't have divergent security state across two windows of itself)?

I have a destructive action exposed as a toolbar item, which might be collapsed into a ToolbarOverflowMenu. I'd present the delete confirmation as a confirmation dialog anchored to the button that triggered it. But when the action is inside the overflow menu, the menu item isn't a view I can anchor it to. What's the recommended pattern for the delete confirmation in that case? Is an alert the intended fallback, is there a supported way to anchor a confirmation dialog to a toolbar overflow item, or would you recommend a different approach altogether?