iPhone Duo SwiftUI Q&A

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?

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?

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.

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

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?

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?

I’m building a real-time game where the iPhone Duo hinge angle will drive a continuous in-game “reality shift” effect as the device opens and closes. For an interactive game, what update frequency and latency should developers expect from the hinge-angle APIs? Is it appropriate to use continuous hinge updates to drive visual state frame-by-frame, or should apps sample/debounce the values? Also, if the main renderer is not SwiftUI, for example Metal or Unreal Engine through a small native bridge, is there a recommended pattern for observing hinge changes and synchronizing them with the game render loop? I’m especially interested in any guidance around avoiding jitter, delayed updates, or excessive work during rapid folding/unfolding.

For an interactive game effect driven by hinge angle, should the value from DeviceHingeContext generally be consumed directly, or is it expected that an app will apply its own interpolation/smoothing before using the value for animation? Are there recommended practices for handling rapid direction reversals, very small angle changes, or transitions between partially-open and fully-open states without introducing visible jitter?

How often is onHingeChange delivered: every frame, or smoothed and throttled? Is it called with the initial context when the view appears, or only on change? Is there a guaranteed angle range and precision?