Hello SwiftUI team, When building custom container layouts conforming to the Layout protocol that dynamically flow content around the new .division reserved region (avoiding the fold area), what is the expected performance contract during rapid physical hinge movement? Does the continuous hinge motion invalidate the layout cache (makeCache / updateCache) on every frame, or are intermediate hinge angles decoupled from container re-measurements (sizeThatFits) to prevent layout thrashing? For asymmetric safe areas across the inner dual-pane presentation, what is the canonical way for a custom Layout to read the reserved division bounds directly from LayoutSubviews / subview.layoutPriority, without having to wrap each subview in a GeometryReader or an explicit ArrangementView that could disrupt matchedGeometryEffect transitions across the fold? Thanks!

I have an app mixing UIKit and SwiftUI. Right now it’s not yet migrated to SceneDelegate. What will happen when the iPhone Duo is available ? Will the app run, or crash ?

Where is the NFC antenna located on the iPhone Duo? Our app is using it and we show to the user where it is before starting the process, but we don't know yet where it will be

When the app moves between the outer and inner displays, does SwiftUI preserve view identity end to end: @State, scroll position, @FocusState, an active text field with the keyboard up, presented sheets and popovers? Is anything recreated, and does scenePhase change during the transition?

See screenshot (closed state) for an example of the kinds of issues we are seeing with certain shapes. I'm sure we can figure out something with the safe area view modifiers; my question is more conceptual about why this sort of thing would happen in the first place and if you have any best practices to avoid it.

When iPhone Duo is folded or unfolded while our app is running, what is the supported way to be notified, so the layout can re-evaluate? Our app currently computes its board size once when the game screen appears and never recalculates, so a fold or unfold mid-game leaves it sized for the previous display. What should we observe, and at what point in the transition is the new size reliable to read?

I have three buttons on top of main screen on one of our apps (just like the new Health app), currently top of the buttons is constrained to safeArea.top but on Duo that is zero and so are layout margins. So these buttons touch the bezels on top in folded and unfolded (landscape mode). What is the best approach to handle such cases.

Our SwiftUI word game shows a "screen too small" warning on small iPhones, and the same size check gates one feature. We originally read UIScreen.main.bounds. On iPhone Duo the app runs on the inner display (669 x 871 pt), but UIScreen.main returned the cover display's size, so the warning fired on the largest iPhone screen there is. We now read the size from the active window scene's screen instead, which fixes it. Two questions: Is the active window scene's screen the supported way to get the size of the display the app is actually on, or is there a better API (e.g. reading the size from the SwiftUI view hierarchy instead)? For roughly the first second after launch, the Duo reports the scene's screen bounds transposed (871 x 669 instead of 669 x 871). Re-reads a second later are correct. Is that expected, and what is the right moment or signal to read a trustworthy size at launch?

What's the best practices to adopt iPhone Duo for a production UIKit app? What few things we need to consider during the development? "As long as we use auto layout, it should be fine" is this correct term for iPhone Duo? Meaning, as long as our app use proper auto layout, our app should be able to support iPhone Duo properly.

I'm using a 2 column SplitViewController, with preferredDisplayMode = .oneBesideSecondary Running it on the duo simulator in device hub, everything works, but i'm not seeing that cool animation when it unfolds, that the inner screen already has the content open. Opening it, the screen goes black, and then the fullsized splitview appears. Close it, screen goes black, and it reverts to showing the only the master. Is this a limitation of the simulator or an issue with the setup? Its hard to tell due to the limited apps installed on the new simulator

Hi I have 2 buttons on the right side of the navigation bar (on a "classic" iPhone), and I want the one that's most on the right to be at the top when the buttons are shown top to bottom on iPhone Duo. What navigationItem property should I set ?

Our SwiftUI game's board screen is one vertical stack: header, board, two tile racks, action buttons, message bar. Built with the iOS 27 SDK it renders correctly upright on iPhone Duo's inner display, but the content needs ~948 pt in an 837 pt canvas, so the racks clip and the buttons fall off the bottom. The canvas is unusually wide and short (669 x 871) compared with any iPhone. What is the recommended way to adapt a portrait phone layout to the inner display — is the expectation that apps restructure into a side-by-side arrangement at this size class, and is there guidance on what to key that off? Size class alone reports .regular width on both displays.

when I am in 2up split view, in a navigation controller stack pushed to a second back button, it would be nice to be able to have the left vertical bar also have an offset to the back button that's the same height as the camera/status occlusion is. But I can't add a fixed bar button of width (whatever the occlusion frame height is) (The desire is to have symmetric vertical bars if the user is in the same view controller. Otherwise it just looks weird.)

Is there an API for opting out of the inner screen blur when the phone is actively folding? I want to play with using hinge angle as an interaction point in an app, but if half the visible screen blurs every time the user changes the angle, it kind of ruins the experience I'm imagining.

UITableView Index uses iPhone idiom when unfolded (could use regular layout)/ should move away from fold FB24853722

The overflow menu is black/white I would like it styled like my other buttons (such as back button) how do I do this? 100% white/black is 100% ON and draws the eye. Overflow should be the least important thing on the screen, not an attention sink.

What’s the recommended approach for aligning a component at the top? On other devices, we’ve "relied" on the top safe area as spacing. However, on the Duo, when folded or opened in landscape mode, the top safe area is zero. What’s the recommended way to handle the top spacing in this case? Should we detect when the top safe area is zero and add a custom top padding instead?

Is ArrangementView intended specifically for iPhone Duo, or should it also be used for adaptive layouts across iPhone and iPad? This is unclear because when I use a horizontally or vertically split ArrangementView on a non-Duo device, such as iPad, it only displays one of its child views. If ArrangementView is Duo-specific, what is the recommended way to use it only on iPhone Duo while falling back to a different layout on other devices? I haven’t seen an API or pattern for conditionally switching between those layouts.

I have a UIImagePickerController subclass I’ve been using for the last 15 years (yes since 2011) to take photos to add to a record. (Upgraded to the new library picker when it came out with sheets). Can I still use it? Anything to be aware of? If I want to upgrade the experience is anything as easy as that API? Which camera is 'better’/should I encourage use of/how?

With app opened in split view, I cannot drag UITableView list items to the other window (if it's the home screen) and drop them to open a new window, like I can with my iPad multitasking app. When I test an iPad device in the 27.1 simulator, selecting New Window from the simulator crashes the simulator. (FB24876909) (I can open in split view from home screen icon, but I can't get any gestures to make the app go from full screen to split view, what is the gesture there?)