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?

We read windowScene.statusBarManager?.statusBarFrame and pin views to the safe area. Mid-fold, the status bar and home-indicator insets change, but several child view controllers do not get viewSafeAreaInsetsDidChange until the animation finishes. Which callbacks are apps expected to use to track safe area continuously through a fold?

Our detents use fractions and absolute heights derived from the screen’s long side. After a fold, a detent that was “medium” on the outer display is far too short or too tall on the inner display until we rebuild the sheet. Do custom and system detents automatically track windowScene.screen.bounds, or must the app reassign sheet.detents when the scene geometry changes?

On iPhone Duo, is this the recommended pattern for displaying two views, A and B in a splitted way? I would use an ArrangementView configured as follows: When the hinge is closed, display A and B using a regular adaptive HStack/VStack. When the hinge is open, let ArrangementView split A and B across the two displays. Is this the intended way to structure this kind of layout?

If the user folds or unfolds while our sheet is up, the detent heights and whether the sheet is inset are stale. We dismiss with animated: false and present again inside traitCollectionDidChange. Is the supported approach to update detents in place during the transition coordinator, and which callback is guaranteed to run after the sheet’s container has its final bounds?

I have an app mixing UIKit and SwiftUI. Right now it’s not yet migrated to SceneDelegate. What will happen when the iPhone Duo is available ? Will the app run, or crash ?

The same .pageSheet is edge-to-edge on the folded phone and an inset sheet on the unfolded display, because the size class is regular. Our home sheet used to include its own tab bar so it could cover the real one. On the inner display that produces two tab bars. Should a phone-style edge-to-edge sheet on the inner display be requested with a specific modalPresentationStyle or UISheetPresentationController flag, rather than inferring it from “sheet width ≈ window width”?

Hinge interaction, layoutSubviews, etc – when we're supposed to get notified, and react to the change of pose/layout?

When the automatic sidebar is active, a dimming layer covers the selected child. We cannot find a public property to disable it. Is that dimming UITabBarController’s own overlay, and is there a supported way to keep the selected controller fully interactive while the sidebar is visible?

On iOS 27 we set sidebar.preferredPlacement = .tabBar and sidebar.preferredLayout = .tile, and we also set mode = .tabBar. After unfolding, a sidebar can still appear and dim the content underneath. What is the correct combination so a five-item tab bar stays a tab bar on both Duo displays?

Hi. We use the viewWillTransition(to size: CGSize, with coordinator: any UIViewControllerTransitionCoordinator) function to update frames when user rotates / opens / folds an iPhone Duo. However we found that the safeAreaInsets are not always correct in the alongsideTransition block of the animate(alongsideTransition:completion:) funciton. Here's the test code I wrote in a UIViewController: override func viewWillTransition(to size: CGSize, with coordinator: any UIViewControllerTransitionCoordinator) { super.viewWillTransition(to: size, with: coordinator) print(">>> before animate, view.frame: \(view.frame)") print(">>> before animate, view.safeAreaInsets: \(view.safeAreaInsets)") coordinator.animate { [weak self] _ in print(">>> in animate, view.frame: \(self?.view.frame)") print(">>> in animate, view.safeAreaInsets: \(self?.view.safeAreaInsets)") DispatchQueue.main.asyncAfter(deadline: .now() + 0.1) { print(">>> after 0.1, view.frame: \(self?.view.frame)") print(">>> after 0.1, view.safeAreaInsets: \(self?.view.safeAreaInsets)") print(">>> -------------") } } } And here's the logs when I rotate an opened iPhone Duo from "portrait" to "landscape" (where the tab bar is placed on the trailing / right side of screen): >>> before animate, view.frame: (0.0, 0.0, 669.0, 951.0) >>> before animate, view.safeAreaInsets: UIEdgeInsets(top: 82.0, left: 0.0, bottom: 83.0, right: 0.0) >>> in animate, view.frame: Optional((0.0, 0.0, 951.0, 669.0)) >>> in animate, view.safeAreaInsets: Optional(__C.UIEdgeInsets(top: 82.0, left: 0.0, bottom: 83.0, right: 0.0)) >>> after 0.1, view.frame: Optional((0.0, 0.0, 951.0, 669.0)) >>> after 0.1, view.safeAreaInsets: Optional(__C.UIEdgeInsets(top: 24.0, left: 0.0, bottom: 34.0, right: 84.0)) >>> ------------- In the alongsideTransition block I can get the correct view's frame, but the safeAreaInsets value is not correct. After a short delay of 0.1 seconds the safeAreaInsets becomes correct. Is getting the wrong safeAreaInsets in the alongsideTransition block a normal behavior? When is the correct timing to detect view's frame and safeAreaInsets when rotation (or view size change) happens?

For a full-screen game with a Metal/Unreal rendering view and a SwiftUI overlay for touch controls, what is the recommended way to keep interactive controls away from the hinge while still allowing the rendered game world to use the full display? Would you recommend querying ReservedRegion in the SwiftUI overlay while allowing the underlying render view to remain edge-to-edge? Also, should control placement respond continuously while the device is being folded, or primarily respond to layout/reserved-region changes once the pose changes?

I’m building a real-time game where the primary gameplay runs on the inner display. I’d like to use the outer display for optional supplementary content such as a scanner, companion view, enemy sensor, or other game information. The current Scene Accessories examples appear centered around CameraCaptureAccessory. Is there a supported API for a non-camera app or game to present arbitrary supplementary content on the outer display while the main game remains active on the inner display? If not currently supported, should developers design the outer-display feature as optional and wait for additional accessory types?

We create the window once in scene(_:willConnectTo:options:) with windowScene.coordinateSpace.bounds. After a fold, should that same scene’s screen.bounds and coordinateSpace.bounds animate to the new display, or does UIKit discard the session and deliver a new scene we must attach the window to?

We currently dismiss and rebuild a presented sheet whenever horizontalSizeClass changes. That also fires for rotation and for Split View or Stage Manager resizing. Is there a callback or geometry value that means “the device folded or unfolded,” separate from a normal size transition?

For a guided SwiftUI flow with a blocking approval step, how would you recommend using the second display on iPhone Duo? For example, while the user waits for approval on one display, would showing the submitted information or other contextual content on the other display be an appropriate pattern?

Setting XCUIDevice.shared.orientation has no effect on the Duo simulator running iOS 27.1 — the window size and our computed layout mode stay unchanged. We measured this on two clean boots. On other devices (iPhone 18 Pro, iOS 27.0) the same call works as expected. Is orientation expected to be a no-op on Duo, or are we holding it wrong?

Is 27.1 (when final) intended to be what we use to submit our optimised Duo builds to the App Store ? Or will it be 27.2 or something else?

As a workaround we used xcrun devicectl device appResize. It works: setting 951×669 makes our layout classifier report wideSplit and 669×951 reports tallSplit, confirmed from the app's own debug readouts. Two behaviours we had to discover empirically: the resize must be applied while xcodebuild test is already running, because xcodebuild's own app launch resets a size set beforehand; and appResize start needs roughly six seconds to establish the session, failing at two seconds with "not currently hosting a resizable app session". Is appResize the intended mechanism for exercising foldable scene sizes in tests, or is there a first-class API we should be using instead?

For some input screens we need a minimum height for the user to be able to comfortably navigate and complete the form. Can we prevent rotation for such screens?