On unfolding, our app's horizontalSizeClass becomes .regular, and UITabBarController automatically promotes to the iPadOS-style sidebar. We suppress this with mode = .tabBar (iOS 18+) and sidebar.preferredPlacement = .tabBar / sidebar.preferredLayout = .tile (iOS 27+) to keep a bottom tab bar. Is this the correct/recommended approach for a foldable iPhone's inner display, or is there a foldable-specific tab bar mode we should be using instead?

Our app declares TARGETED_DEVICE_FAMILY = 1 (iPhone only), yet the unfolded inner display presents a .regular horizontal size class identical to iPad's, and our project also carries a leftover INFOPLIST_KEY_UISupportedInterfaceOrientations_iPad override. Does Apple recommend/require declaring iPad as a supported family for apps that want to support this device properly, or is "iPhone-only + regular size class" the intended long-term model?

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.

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)?

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?

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.

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.