We have a guided, multi-step setup flow where the user must complete each step in order. One step is an approval gate: after submitting information, the user waits for an approval result before they can continue. They can't navigate back from this screen. On iPhone Duo, what would be the recommended approach when the device is unfolded? Should the approval status remain the primary content on one display while the submitted information or other contextual content is shown on the other, or is this a case where the flow should remain focused on a single display?

Cold launch from a shortcut, universal link, or push is handled in scene(_:willConnectTo:options:). Diiferent functionalities also start Live Activities and reload widgets. If the device is folded, does that scene connect for the outer display, and can the geometry still change before the first frame if the user unfolds? When folded, do Live Activities and widgets appear on the outer display, and is there a separate presentation the app must support?

Only Home updates layout when the size class changes. Various screens are pushed and set their table and scroll heights once from the screen size. Does every controller in a navigation stack, including ones that are not visible, receive viewWillTransition(to:with:)? For forms and lists on the inner display, is readableContentGuide the width we should use, and does it update during the fold?

On the unfolded inner display our root view controller’s horizontalSizeClass becomes .regular, the same as iPad. Folded, it is .compact. Is that the supported way to tell the two displays apart, or is there a Duo-specific trait, screen idiom, or UIWindowScene property we should use instead of size class?

We resume location and refresh Home from sceneDidBecomeActive, and we ignore that callback while Apple Pay is up because dismissing PKPaymentAuthorizationController also makes the scene active. Does a fold or unfold call sceneWillResignActive, sceneDidEnterBackground, or sceneDidBecomeActive? If the user folds during Apple Pay, does the payment sheet dismiss and complete, or stay up on the other display?

Hi everyone, I’m developing an iOS application and I’m wondering whether it is possible to position the app on either the left or right side of the screen when running in a dual-window/multitasking configuration. If the app does not occupy the entire screen, can I customize the remaining empty space by assigning a background color or displaying an image? Additionally, if I place a visual element or background in the central/remaining area, could this cause any issues with touch interaction or hit-testing? In particular, I’d like to understand whether the system would still correctly route touch events to the active application, or whether the additional area could interfere with the app’s clickable elements.

The QR scanner uses AVCaptureSession and an AVCaptureVideoPreviewLayer framed to the view bounds. Different screens present UIImagePickerController with source type .camera. If the user folds or unfolds while either is visible, which camera stays active, does the preview orientation and frame update, and is the picker dismissed or left at the old display size?

In our app we have situations where the user may be blocked for security reasons and we currently present a full screen modal - can we fill the screen with a modal in such a situation on Duo if the app is full screen on the inner display?

Camera, gallery, and PDF choices use UIAlertController style .actionSheet with no popover source. Receipt sharing uses UIActivityViewController, and uploads use UIDocumentPickerViewController; only some set sourceView, and almost none set a real sourceRect. On iPad those presentations need an anchor. On the unfolded Duo display, where the size class is regular, does UIKit still present them as phone sheets, or must every one set sourceView and sourceRect?

We use a PreferenceKey-based pattern to measure real per-row content height in a List (via an invisible .background(GeometryReader { ... }) per row), caching the result in @State keyed by row index, since a fixed height estimate wasn't reliable. This is a common SwiftUI technique, not iPhone-Duo-specific. Apple's guidance on GeometryProxy.reservedRegion covers fold-aware layout for regions affected by the hinge, but I haven't found guidance on whether a live pose change (open → folded, or vice versa, without a relaunch) automatically invalidates cached measurements taken via a PreferenceKey at first layout, or whether SwiftUI's dependency tracking doesn't propagate that kind of external geometry change and the cache needs to be explicitly cleared on a pose-change notification. Is there a specific environment value or notification to observe for "the window's available geometry changed due to a fold event," separate from the standard horizontal/vertical size-class change?

Given the size-class behavior mirrors iPad in the unfolded state, does UIDevice.current.userInterfaceIdiom (and UITraitCollection.userInterfaceIdiom) still report .phone in both postures, or does it change to .pad-like when unfolded? This affects any idiom-based branching in our codebase.

Which parameters are exactly used to decide which controls are moving to the vertical bar? What are they (which priorities, other properties are used for that decision?)

The cover and inner displays have different aspect ratios and (presumably) different safe area insets/notch or camera cutout geometry. Is there guidance on how safe area layout guides should behave across the fold transition — do they update automatically as part of the same trait-change/relayout pass, or do we need to explicitly recompute cached safe-area-derived constants (we currently cache statusBarHeight off the "foreground active" window scene)?

What exactly is the UIWindowScene.ActivationAction and if I have multiple scenes when would ever a point be that a new window would be triggered on the front screen (closed) such that there would be an error? Do I really need to do something with this?

We have a CALayer subclass performing custom draw(in:) rendering (a radial gradient) behind a card view, resized via viewDidLayoutSubviews. For an ordinary rotation we sync it inside coordinator.animate(alongsideTransition:). If the fold/unfold transition doesn't go through viewWillTransition at all (per Q1), what is the recommended hook to animate custom CALayer content smoothly across this specific transition, given it appears to involve a scene relocation rather than a resize?

he only way we've found to change fold posture is the Simulator app's own toolbar control (cover/flat/bent icons); there's no xcrun simctl subcommand (ui, status_bar, etc. don't cover it) and no XCUITest API we've found. Is there a supported way to drive this programmatically for automated UI testing, the way XCUIDevice.shared.orientation works for rotation?

Beyond the general iPad/regular-width adaptive layout guidance, is there foldable-specific HIG guidance for what should change (or must not change) between the compact cover-screen layout and the regular-width inner-screen layout — particularly around navigation patterns (tab bar vs. sidebar), modal presentation styles, and content reflow expectations?

On the folded phone the keyboard resizes our edge-to-edge sheet. On the inner display the sheet is inset, and keyboardFrameEnd in screen coordinates no longer lines up with the sheet’s container, so input fields stay covered. Should we convert the keyboard frame into the sheet’s coordinate space, and does keyboardLayoutGuide follow the sheet or the screen on iPhone Duo?

Does content state (scroll position, selected tab, in-progress form input) persist automatically across the fold transition, or must apps restore it manually?

We've been reverse-engineering behavior from the Simulator device profile alone. Is there a WWDC session, updated UIKit/SwiftUI documentation, or sample project specifically covering foldable iPhone adoption (window/scene handling, size-class behavior, collection/table view sizing, and the fold-posture API surface) that we should be building against instead of inferring behavior empirically?