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?

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?

I know iPhone without a home button do not support portrait upside down display, but it seems that this would be very useful on the Duo. Especially if it's upside down when the user closes it. The simulators in 27.1 bets do not seem to support this. Is there a plan to support upside down portrait on the iPhone Duo? Left handed people may appreciate it.

I’m simulating an iPhone Duo using Xcode 27.1 beta, and I’m having trouble tapping buttons placed near the top of the screen. It seems that the top ~20 pixels of the screen are not responding to taps. In my ViewController, preferredScreenEdgesDeferringSystemGestures returns .all, so system gestures should require two swipes to be triggered. However, a simple tap in this area does not seem to be recognized. This appears to happen only on iPhone Duo; taps work normally on other iPhone models. Does anyone know whether this behavior is expected to occur on the actual iPhone Duo hardware as well, or is it specific to the simulator? For reference, the buttons are positioned according to LayoutMarginsGuide with Safe Area. FB24914903 I wonder if anyone knows how to get the top margin size programmatically.

I noticed the hinge keep out has an isActive status on it. does that mean the hinge area is only un-tappable when it is active? As in, when the device is open 100%, the hinge area can receive taps? Same for the camera cutout on the inside screen, I assume it's only active when the camera is being used?

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!

When using ArrangementView with the overlay style, the Duo simulator does not appear to return a distinct z-index environment value, though it correctly displays z-index 0 and 1 on other iPhone simulators. I would like to use this value to determine whether the overlay is active. Currently, this does not seem possible. Is this behavior intended, or is it a bug? If intended, what is the recommended approach to determine if the Duo is displaying the arranged view over another arranged view? import SwiftUI struct ContentView: View { var body: some View { ArrangementView { Controls() } secondary: { Player() } .arrangementViewStyle(.overlay) } } struct Controls: View { @Environment(\.overlayArrangementZIndex) var zIndex var body: some View { Text("Controls Z:\(zIndex)") .frame(maxWidth: .infinity, alignment: .leading) } } struct Player: View { @Environment(\.overlayArrangementZIndex) var zIndex var body: some View { Text("Player Z:\(zIndex)") .frame(maxWidth: .infinity, alignment: .trailing) } } #Preview { ContentView() }

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?