We have observed that the inner display and the outer cover display possess vastly different safe area profiles (top-aligned system band vs. trailing margin status cluster). When developing full-bleed UIKit interfaces using .edgesIgnoringSafeArea equivalents or custom container controllers, what is the best practice for pinning controls to avoid occlusion by hardware bezels or dynamic system clusters without creating rigid, hardcoded coordinate offsets? Does UIView.layoutMarginsGuideautomatically factor in active system reserved regions?

For UIKit applications, is UISplitViewController still the recommended architecture for taking advantage of the Duo form factor, or are there newer APIs/patterns (window groups, scene fragments, adaptive layouts) you recommend for dual-screen support?

During physical articulation transitions, view bounds, safe areas, and reserved regions frequently resolve across distinct sequential layout passes. In declarative SwiftUI hierarchies, this transient intermediate state can trigger view destruction and recreation if subviews are conditionally bound to active divisions. What is the official guidance for stabilizing view state across these asynchronous layout passes? Should coordinators implement client-side debouncing, or does SwiftUI provide layout primitives to smoothly bridge views across active-to-inactive division transitions without dropping view identity or resetting active tasks?

Hi, When adapting an existing UIKit app for iPhone Duo, what should we consider the source of truth for layout adaptation at runtime? For example, suppose the same scene transitions from a narrow layout to an unfolded layout where there is enough space to present two content regions side by side. In this situation, should we primarily react to: trait changes such as horizontalSizeClass changes to the view/window bounds safe area changes or a Duo-specific posture/hinge API? We would like to avoid device-specific logic such as checking whether the current device is an iPhone Duo, and instead make the UI respond to the appropriate UIKit environment signals. I'm also curious about view controller containment during these transitions. If the compact layout presents content through a single navigation hierarchy, but the unfolded layout can present multiple regions simultaneously, is the recommended approach to keep the same view controller hierarchy and adapt its layout, or is transitioning between different container view controller configurations expected? In general, what is the recommended UIKit pattern for deciding when a structural UI adaptation should happen and which system signal should drive it? Thanks!

"How does the app handle fold state during background transitions and foreground launch on Apple Duo? If the device folds while the app is being moved to the background, does the app save the fold state in the scene state data? When the app returns to the foreground, should the fold state be restored to accurately recreate the UI? If a user opens the app via a notification action while the device is already folded, how should the initial view layout be determined? Should SceneDelegate handle fold state transitions during scene lifecycle events (willResignActive, didBecomeActive)?"

When device folds/unfolds, how should interactive component states (animations, selections, playback, expansions) behave? Should state persist, reset, or pause?

How should infinite carousel and cell reusability behave during fold transitions? Is scroll position preserved during fold? If fold occurs during cell reuse, can wrong campaign be displayed? Can "load more" pagination trigger twice during fold? If swipe gesture is mid-progress during fold, can cell snap to wrong position? Can carousel animation glitch during fold? Can cell deallocation fail during fold (memory leak)?

How should deep links and external URL navigation behave when fold transitions occur on Apple Duo?

My app passes data across a Group Activities session on a FaceTime call. It requires that the user can see the video coming from the other end. A normal call on the iPhone only sees a PiP video. On an iPad, the user can divide the screen between the two apps. An iPhone user may not be familiar with the iPad UI. Is there an API to divide the screen between FaceTime and another app, automatically? Group Activities with PiP Video iPad FaceTime Full Screen Video

When using safeAreaBar, what’s the best way to keep its content on just one side of the fold in book mode? Would you recommend using the .division reserved region to adjust the layout manually, or is there a more built-in SwiftUI approach?

Hello! When adapting custom UIKit view controllers for iPhone Duo, what is the recommended architectural boundary for detecting hinge articulation? Does the system surface posture changes through UITraitCollection(such as new traits or size class combinations), or are developers expected to observe UIView.reservedRegions(kind: .division) mutations exclusively inside layoutSubviews() and viewSafeAreaInsetsDidChange()? Furthermore, when the hinge moves, how should view controllers coordinate transitions between a dual-pane layout and a unified continuous column without tearing down existing child view controllers?

How should form transactions handled within embedded WebView behave during Apple Duo fold transitions?

"How should bottom sheets behave on Apple Duo during fold? Should bottom sheets be automatically dismissed when fold occurs? Can bottom sheets be opened while the device is in a folded state? What should happen if the sheet content overlaps with the fold line? Should bottom sheet height be different for folded vs unfolded states?"

I'm adapting modal sheet presentation for iPhone Duo. My root is a UITabBarController, and I present detail view controllers with present(_:animated:) using .pageSheet / UISheetPresentationController. I want to confirm how much of the sheet's placement and sizing I can control as the device moves between poses, and which APIs are the intended levers versus behavior the system owns. 1. Closed pose — constraining sheet width away from the edges With modalPresentationStyle = .pageSheet in a horizontally compact layout, the sheet spans the full width. Is there a supported way to constrain its width so it doesn't run edge-to-edge — e.g. via the presented controller's preferredContentSize, a .formSheet style, or a custom UIPresentationController with an overridden frameOfPresentedViewInContainerView? Does UISheetPresentationController honor a preferred width, or is width strictly derived from the container's size class? 2. Partial open — targeting which arrangement the sheet presents over When the device is partially open and multiple arrangements are visible, can I influence which arrangement (leading vs. trailing) the sheet is presented in? Does the presentation container respect reserved regions and the current UIArrangement, and is there a recommended way to anchor a modal presentation to a specific arrangement — or is the presenting view controller's location in the hierarchy the only determinant? 3. Fully open — driving large vs. compact sheet sizing When fully unfolded with the additional horizontal space, is detents the correct mechanism to switch between a compact and expanded sheet (e.g. .medium(), .large(), or a .custom detent resolved via UISheetPresentationController.Detent.custom)? Should selectedDetentIdentifier be updated in response to trait changes, and is sheetPresentationController.widthFollowsPreferredContentSizeWhenEdgeAttached relevant here? General question: Should all of the above be driven by observing UITraitCollection changes (size classes) via traitCollectionDidChange(_:) / the trait registration APIs, or is there dedicated iPhone Duo API tied to the hinge angle and arrangements that I should adopt for sheet presentation instead?

For a UIKit app embedding a WKWebView across the inner display, what is the recommended way to keep web content and interactive controls clear of the fold’s division reserved region? Are these regions exposed to web content through public CSS or JavaScript APIs, or should the UIKit host query them and communicate the geometry to the page? How should this work alongside CSS safe-area insets and the web view’s scroll-view inset adjustment, so that native and web layouts don’t apply the same spacing twice? A small UIKit + WKWebView example would be very helpful.

How do scheduled campaign reminder notifications behave on Apple Duo during fold transitions? If a scheduled notification is triggered while the device is in a folded state, does the notification display correctly? Should we implement fold-aware notification scheduling? Can the notification payload be corrupted or truncated if fold occurs during the notification delivery process? Should we validate notification data after fold transitions? Is the notification center accessible and visible to the user during a folded state? Can the user interact with notification actions during fold? If the device unfolds after a scheduled reminder was set to trigger during the fold, will the notification still be delivered, or could it be skipped? Should we implement retry logic for missed notifications?

"How does session management and authentication handle fold transitions on Apple Duo? If the device remains folded for 30+ seconds, could the user session timeout despite the app being active? Should the authentication token be refreshed during or after a fold transition to prevent expiry? Can user login state become invalid if fold occurs while the device is in a folded position? After fold completes, should we re-validate the authentication token before allowing critical operations (payments, sensitive actions)?"

"What are the financial transaction integrity risks on Apple Duo during fold transitions? Is there a risk of double-charging if fold occurs during payment processing? If a user confirms payment and immediately folds the device, how is the transaction status handled? Can we guarantee the payment was processed only once? Can a failed payment retry mechanism cause duplicate payment attempts if fold occurs during the retry logic? If a refund or payment reversal is initiated and fold occurs during the operation, could the transaction be interrupted or processed twice?"

Hello! The session description mentions "responding to the hinge angle" in SwiftUI. In the current iOS 27.1 SDK surface, physical division detection relies primarily on inspecting GeometryProxy.reservedRegions(kind: .division). Could you clarify whether Apple recommends modeling posture strictly through geometric division queries, or if there is a recommended/upcoming approach (such as a dedicated view modifier, environment value, or semantic posture state) to observe chassis articulation directly? If continuous or discrete angles are accessible, what is the canonical way to drive declarative layout changes without incurring redundant body re-evaluations during active folding?

"For payment confirmation and retry flows on Apple Duo: If fold occurs during payment confirmation screen: Should we pause/dismiss the confirmation modal? Can user confirm payment while device is folding? Should we preserve the confirmation state and re-display after fold completes? What if transaction is already processing when fold occurs? For failed payment retry scenarios: Should we automatically retry after fold completes?