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

When iPhone Duo is unfolded completely flat to 180°, ReservedRegion(.division) becomes inactive or reports empty geometries. At this point, both the flat inner display and the closed cover display present continuous rectangular surfaces. We currently infer the inner display by evaluating the asymmetric system safe area signature (specifically the presence of the 82 pt top status band versus the trailing lateral cluster on the outer display). Is relying on asymmetric safe area insets the intended pattern to discriminate the active display surface in SwiftUI, or is there a preferred platform API to identify whether a window is hosted on the internal foldable panel versus the cover glass?

"For QR scanner functionality on Apple Duo: Should QR scanner remain accessible during fold, or should it be disabled? If fold occurs during active scanning, what happens to the scan session? Should we use one camera or dual cameras on both screens? How do we handle camera permission state across fold transitions? Should scan result be displayed on the screen where the camera was active?"

"How should our application's components (campaign cards, payment flows, bottom sheets) be displayed on iPad and Apple Duo? Should we adapt our current iPhone-only design to iPad, or create separate layouts? Should layouts work seamlessly during fold/unfold transitions on Apple Duo? Can we reuse the same storyboards and XIBs, or do we need device-specific implementations? Are Size Classes sufficient, or do we need custom breakpoints for these different screen sizes?"

"When implementing SegmentedControl for container navigation on Apple Duo: What's the optimal segment placement when the screen is folded (top, side, or hidden)? How do we handle segment state persistence across fold transitions? Should we use a single SegmentedControl for both screens or separate ones per display? Are there performance implications for frequent container switching on dual screens?"