iPhone Duo UIKit Q&A

Hi, I have an app based almost entirely on standard system components and UICollectionViewController that I'd like to adapt for the iPhone Duo I'd like to describe my viewController setup and ask a few questions, please correct me if any of the statements are incorrect. In the time between the annoucement of the Duo and the release of Xcode 27.1 I also tried to adapt the app to the iPad. It's a simple set up so I think it should be make a good example for questions. My rootViewController is a UITabBarController so on the iPad I get the sidebar (but not the iPhone Duo) Up until now, on the iPhone (horizontal compact) I normally pass a UINavigationController to the UITab's viewController provider closure. This works well because on the iPad when the sidebar is hidden the tab bar at the top of the screen floats above the visible tab's navigation bar For the iPhone Duo and iPad I need a container view controller to load two viewControllers into the rootViewController to make use of the extra horizontal space. Presumably I sholud setup and keep the same view hierarchy (for all devices) and adapt it based on changes to the traitCollection.horizontalSizeClass Using a split view controller's supplementary/second column seems to work well, the UITabBarController manages the sidebar on iPad, views can be resized by the user.Tthe supplementary column is hidden automatically in horizontalSizeClass compact. The navigation bar of the supplementary/second column stays below the floating tab bar -which is understandable because of the split. If I hide the navigationBar on the supplementary/second columns, Is it possible to instal bar items in a navigation bar at the top of the screen/below the floating tab bar? Also if i hide the supplementary column when the iPhone Duo is unfolded, the empty navigation bar becomes visible at the top of the screen, I think this might be a bug. I also tried UIArrangementView. I'm sure if it's suited for this use case as primary (leading) placement needs to switch to the secondary (trailing) placement when the iPhone Duo is unfolded. Is there something that I didn't understand correctly?

When iPhone Duo is partially folded, you need to move some UI to the left or right (or top or bottom depending) half of the screen to avoid the division region, but how do you determine which side is appropriate? Sheets move to the left automatically but why? Is there anything that should move to the right? Can you share any examples? Is there API to get the system recommendation for a specific type of UI or something?

When adapting a UIKit app for iPhone Duo, is there a supported API for observing the hinge/fold angle continuously during an unfolding transition? For example, if the device is partially unfolded at approximately 23°, can an app detect or respond to that specific angle (or ranges of angles) and update/freeze its UI accordingly, or does UIKit expose only discrete pose/state transitions? Additionally, can an app distinguish between unfolding while the device is oriented in portrait versus landscape and provide different adaptive layouts or transition behavior for each? I’m specifically interested in what device posture/hinge information is exposed to UIKit during the interactive unfolding transition, and whether developers should design around continuous hinge-angle changes or only the system-provided size, orientation, trait, and pose/state changes.

For a banking app displaying sensitive information, are there any new privacy or security considerations we should be aware of on iPhone Duo, especially around app snapshots, transitions, multitasking, or content visibility?

We ship a mature document viewer (PDF) written mostly in Objective-C with UIKit. It runs on iPhone and iPad and supports multiple scenes. We're planning support for iPhone Duo and would like advice on the right architectural approach before we start. Current structure (simplified) One root viewer view controller (a UIViewController subclass, large and long-lived) owns the document view, search, bookmarks, text-to-speech, presentation mode and similar features. Most of these live in categories and helper modules. Chrome is swapped by size class. A factory picks one of two "toolbars controller" classes based on the trait collection: one for compact, one for regular. The regular one also hosts a tab strip and a sidebar built on the system sidebar UI. When the class it would pick changes, traitCollectionDidChange: tears down the current chrome controller, builds the other one, re-parents the document view into the new container, and then restores tool and presentation state. We skip this while the app isn't active, because UIKit sends trait changes during backgrounding. Geometry changes go through viewWillTransitionToSize:withTransitionCoordinator:, which forwards to the chrome controller, the document view and a zoomed handwriting helper. When the transition completes we recompute content insets and re-render the output for an external display. The document view is a custom scroll-based view (not PDFKit). It has display modes for continuous, single page, two-page spread and two-page spread with a cover page. It calculates its own insets from safe areas and whatever chrome is visible. We still use traitCollectionDidChange: and haven't moved to registerForTraitChanges:. Questions Posture changes and size-class flips. When the device folds or unfolds, should we expect a normal viewWillTransitionToSize: plus a trait change (compact ↔ regular) that our existing swap handles? Or is there a posture/display-configuration signal we should observe instead? Swapping the whole chrome hierarchy in the middle of a fold animation seems costly. Is there a recommended way to defer or coordinate that with the transition coordinator? Hinge or seam area. Is the fold region exposed through safe-area insets, layout guides or a new API? A custom scroll view that lays out two-page spreads needs to keep content out of that region, or line the spread up with it. What's the recommended way to get this geometry from Objective-C? Two-page spread tied to posture. Showing a two-page spread automatically when the device is unfolded (like an open book) seems natural. Does Apple recommend deciding this from traits/posture or from bounds, and is there a trait we can override per view controller? Trait registration. For this form factor, is it effectively required to move from traitCollectionDidChange: to registerForTraitChanges: (for example to get notified about new traits), or will the legacy callback still fire reliably? Scenes and external displays. Does iPhone Duo change anything about scene activation, window geometry or UIScreen handling that a multi-scene app with external-display output should plan for? Incremental adoption. Can we adopt this step by step in Objective-C, or do some of the APIs only exist in Swift and push us toward Swift wrappers? Any pointers to WWDC sessions, sample code or documentation for adapting existing UIKit apps would be very helpful. Thanks!

If the available screen geometry changes while the app is running, what’s the recommended UIKit approach for adapting the UI without losing the user’s navigation or transaction state?

I’m working on a UIKit interface with two persistent layers: A large interactive canvas that should remain visible and tappable. A content drawer that can move between several detents and contains its own navigation and scrolling content. On a compact display, the natural presentation is a bottom sheet. On a wide display, the natural presentation is a constrained-width sheet beside the canvas. When the Duo is partially folded, the drawer should occupy one usable region while the canvas remains interactive in the other. UISheetPresentationController gets close because it supports detents, undimmed background interaction, and placement. UIArrangementViewController also seems relevant because this is conceptually an overlay or split relationship. However, an arrangement doesn’t provide sheet interaction, while a presented sheet doesn’t appear to model the canvas and drawer as peer regions. What is the intended public UIKit composition for this kind of interface on iPhone Duo? Should this be modeled as a UISheetPresentationController, a UIArrangementViewController, or a custom container? Is there a supported way for one persistent sheet instance to adapt from a bottom drawer to a side drawer as geometry and reserved regions change? Can the system preserve the sheet’s navigation stack, scroll position, selected detent, and first responder while changing its placement? Is there a public UIKit sample that demonstrates the Maps/Find My-style relationship between an interactive background and an adaptive drawer? I’m trying to avoid branching on a specific device or pose. Ideally, this would be driven entirely by available geometry and reserved regions.

For a large UIKit app, what’s the recommended way to include iPhone Duo in our automated regression testing? Can we reliably test its different configurations using Simulator and XCUITest?

When a payment confirmation notification arrives and the user taps the APPROVE action during or immediately before a fold transition, what are the risks to transaction integrity?

We’re adapting a UIKit screen for newer iOS versions and iPhone Duo. The screen has a solid navigation-bar background, navigation actions, and scrollable content underneath. The layout behaves as expected on a regular iPhone, but Duo introduces questions around safe-area handling, navigation-item placement, scrolling transitions, and how Liquid Glass resolves its appearance when content changes beneath the navigation bar. What is the recommended UIKit architecture for: Using Liquid Glass navigation actions with a visually solid navigation-bar surface. Keeping navigation controls correctly positioned across Duo poses, orientation changes, and resizing. Should this be handled entirely through UINavigationController, UINavigationItem, and UINavigationBarAppearance, or are there iPhone Duo-specific APIs or patterns we should follow? We also need to preserve the existing design on iOS 18.6 while using modern behavior on newer systems. Any guidance on the intended ownership boundary between the navigation host, screen, and scroll view would be appreciated.

Wrong data displayed after fold? Cell reference lost during fold animation? Carousel position jumps after unfold?

I contribute to Flutter, which renders its whole UI into one CAMetalLayer instead of composing UIKit views. The automatic fold adaptation UIKit components get never reaches its dialogs and sheets, so the engine has to read the geometry itself and hand it to the framework, which is what positions them away from the fold. Reading it works. UIView.reservedRegions(kind:options:) returns the fold division and the camera region, and UIHingeInteraction reports the angle. On the iOS 27.1 simulator the inner display is 951×669 pt with a 40 pt division, and hinge.angle runs from 0 shut to π open. Three things I can't answer from the API surface. How does an app learn that a reserved region changed? The hinge interaction covers the fold, but the inner display's front camera region can become active or inactive for reasons that have nothing to do with the hinge, and re-reading in layoutSubviews only catches that if something else happens to trigger layout. Is there a notification or a delegate callback for a region change, or is a layout pass the intended trigger? Is the ordering between the hinge status and a region's isActive defined? isActive seems to lag the hinge: in the update that reports the device fully open, the fold division can still read active. A client that trusts both in the same frame ends up reporting a division that is no longer there. Is there a point where the two are guaranteed to agree? Is the frame of an inactive region meaningful? It keeps its 40 pt frame while flat in my measurements, which would let an app lay out ahead of a fold instead of reflowing when it happens. Is that guaranteed, or incidental? For context, this feeds a proposal to populate Flutter's display feature model on iOS (flutter/flutter#192515) and the implementation under review (flutter/flutter#193025). Happy to post whatever I learn back there.

I have a question about how to adapt UICollectionViewCompositionalLayout for different size classes. Initially I adapted both the diffableDataSource snapshot and the UICollectionViewCompositionalLayout based on the horizontalSizeClass. I wasn't very happy that my datasource (snapshot construction code) needs to know about sizeClasses, it feels like it should only know about data. So I thought why not just return an empty section in the UICollectionViewCompositionalLayout because it get's passed NSCollectionLayoutEnvironment. It works fine but I'm not sure if it's supported or the right way to reason about this. Here's my empty section code. static var hiddenSection: NSCollectionLayoutSection { // Note: .zero is regarded by the system as an error, it might crash in the future let dimension = NSCollectionLayoutDimension.absolute(0.1) let size = NSCollectionLayoutSize(widthDimension: dimension, heightDimension: dimension) return NSCollectionLayoutSection(group: NSCollectionLayoutGroup.horizontal(layoutSize: size, subitems: [.init(layoutSize: size), .init(layoutSize: size), .init(layoutSize: size)] )) } ``` Thank you for any insights!

For banking apps that blur/mask sensitive data when backgrounded, how should this work on Duo when both screens are potentially visible? Should blur behavior differ between active/inactive screens in split view? How to handle data masking during fold transitions?

How should existing UlNavigationController-based applications adapt their navigation hierarchy for iPhone Duo without rebuilding the navigation architecture?

For applications displaying sensitive information, are there any new privacy or security considerations on iPhone Duo, particularly around multitasking, snapshots, screen transitions, or content visibility?

For a large production UIKit application with many legacy screens, would you recommend a gradual screen-by-screen adoption strategy for iPhone Duo, or is there an application-level adaptation that should be implemented first?

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?

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!