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?

on the iPhone Duo simulator reports two distinct "Integrated" screens ("LCD" at 1398×2034 and "LCD-1" at 2007×2853), both simultaneously powered on. Is this the correct mental model for the real hardware — a genuine cover display and inner display as separate UIScreen objects — as opposed to one continuously flexible panel whose bounds just change? This significantly affects whether we handle the transition via trait/size-class changes or via UIScreen.didConnectNotification-style multi-screen handling.

my app widget supports iPhone and iPad. Which widget sizes are available on the outer and inner home screens (including systemExtraLarge)? Does a fold or unfold trigger a new timeline or a re-render?

On fold we see both a size transition and a horizontal size-class change, but not always in the same order, and sometimes only one of them. We update tab-bar visibility in both. Which one is guaranteed for a fold, and should geometry updates happen only inside the transition coordinator’s alongsideTransition block?

When toggling between cover and unfolded posture in the iPhone Duo simulator, we observe several seconds of black screen during the transition — much longer than a typical 0.3s rotation animation. Does viewWillTransition(to:with:) fire at all during this transition, or does the OS tear down and recreate the UIWindowScene/UIWindow on the other screen? We need to know which lifecycle hooks are guaranteed to fire so we can update UI state (search width, gradients, cached layout sizes) at the right time.

Our app is a standard iPhone app (iOS 15 and later). Guidance so far is that an app that ignores ArrangementView, reserved regions, and the hinge keeps its existing iPhone size. On a folded Duo, does that mean letterboxed on one half, scaled on the outer display, or a normal compact layout on the cover screen? Is any of the six new APIs required for App Store review, or can we ship with size-class adaptation only and adopt arrangements after the October 23 launch?

I would love to utilize the whole screen area of the iPhone Duo. To do that, my app needs to show the controls on the side under the status indicators. It works nice if you use system NavigationStacks and TabBars. But what if you don’t? I work on a browser app, and we don’t use system toolbars and tab bars, because they don’t provide enough flexibility for our tasks. For example, playing an icon animation in a tab bar is a bit challenging with the stock TabBar. As far as I know, only system toolbars and tab bars move to the side, and there’s no API to know where this region exactly is. So if you use some custom views you want to present on the side under the status indicators, you may need to guess its location depending on safe area margins, orientation and hinge state. I don’t want to do that, it doesn’t seem reliable. It differs from the previous times screen shape changed. On an iPhone X, you just continued to put interactive content inside safe area, and in many cases you don’t need to go outside it. But in the case of iPhone Duo, you get a blank, unused space on the side, so it feels like we should do something about it. So is there any way for the apps that do not use system tab bars and navigation system to put custom views in that blank area on the side?

A map callout loaded from a xib has autoresizingMask including flexible width and height. Unfolding resizes it to the new parent bounds, so a fixed-size pin stretches. Rotation does the same. Is the fold delivered as a normal bounds change to the existing view hierarchy, and should fixed-size subviews avoid width/height-sizable masks?