iPhone Duo UIKit Q&A

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?

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?

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?

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?