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?

If we have create a custom Navigation back item, while running on iPhone Duo simulator, we see it at normal position i.e. on screen's top left side. How can we move it to the safe area like when we use default back button?

With the default mode of .automatic, the inner display shows a sidebar instead of a bottom tab bar. The sidebar draws UIKit’s dimming view over the selected view controller, which hides our map. We force mode = .tabBar on iOS 18. Is a bottom tab bar on the Duo inner display supported, or is the sidebar the intended phone-unfolded layout?

UITabBar measures titles on the first layout pass. After unfolding, the bar is much wider but labels stay truncated with an ellipsis until the user switches tabs. Reapplying standardAppearance does not rebuild the buttons. Is there a public API to invalidate tab-item title measurement when the bar’s width changes?

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?

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?

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?

what happens to the 3DS payment page, the Auth0 login, Apple Wallet's add-pass screen and the QR camera?

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?

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?

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?

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?