My app currently handles push-notification taps by resolving a destination screen and presenting it. With multi-window now available to every app on iPhone Duo whether it opts in or not, if the app already has more than one window open when a notification is tapped, does the system pick an existing window to route into, always spawn a new one, or is that left entirely to the app to decide? Is there a way for the app to express a preference — e.g. "route into the window that's already showing related content, if one exists" — or does userNotificationCenter(_:didReceive:)/scene-continuation handling need to inspect all currently-connected scenes itself and make that decision manually?

My app presents a checkout/transaction screen owned by a third-party payment SDK — a UIViewController I don't control the internal layout of. If the user folds or unfolds the device while that screen is on-screen mid-transaction, and the SDK's internal views weren't written expecting a live resize, is there a recommended pattern for this situation? Options I can think of: constrain that specific scene/window to a fixed size for the duration of the SDK's flow, if that's still possible now that participation in resizing is effectively mandatory. do nothing and accept whatever the SDK does with an unexpected resize. something else Apple recommends for third-party UI you don't control during a sensitive, ideally-uninterrupted flow. Is there existing guidance for apps embedding SDKs that predate iPhone Duo and haven't been updated by their vendor yet?

When the inner camera is in use and the reserved region becomes active, what is the recommended way for apps to adapt their UI? Should content move out of the reserved region where possible, or is it generally acceptable to leave content behind it? More specifically, how should apps handle content that can’t easily move aside, such as a long navigation title directly behind the reserved region? Should it be truncated, moved below the region, or handled another way?

We have built our existing app with Xcode 27.1 and when running it on iPad it does not resize - it seems to run in iPhone mode as usual, in a fixed portrait mode. However the same build will resize to a wider aspect ratio in iPhone mirroring (and on Duo, obviously) But, the app when built with Xcode 27 does resize on an iPad. So is the 27.1 iPad behaviour expected or is this just something temporary in the 27.1 beta?

When the user transitions from an open to a partially folded state, the system detects this is the final state after some delay and un-blurs the left side. The UI should now adapt to this state. For example, split view controller enlarges the sidebar to occupy the full width of the left side. What’s the best trigger to use for a custom view controller that wants to achieve a similar result? Is it the folding region becoming active?

Several of our sheets use custom fractional detents (.custom(identifier:resolver:), with the resolver computing a fraction of context.maximumDetentValue) to size a sheet relative to available height. If a user opens a sheet while iPhone Duo is unfolded (larger inner-display canvas) and then folds the device mid-presentation, does the resolver re-run against the new (smaller, outer-display) maximumDetentValue, or is the computed height locked in at presentation time — requiring the sheet to be dismissed and re-presented to pick up the new geometry?

Let's say we're testing and building for iPhone Duo support can we sign the builds with Xcode 27 and submit to App Store, and then submit additional builds signed with 27.1 once Duo is released or does the IF AVAILABLE have to be removed from these builds?

My app has a small inputAccessoryView that does not fill the width of the screen above the keyboard. On iPhone Duo with a vertical toolbar, tapping in my text view to bring up the keyboard will collapse all bar buttons that are obscured by the keyboard and any that intersect the vertical space of my inputAccessoryView, even though the inputAccessoryView does not visually overlap the vertical bar. Is there a way to keep more bar buttons on screen?

In the iPhone Duo horizontal pose full expanded inner screen, we use UITabBarController (set up using the viewControllers property), and the UITabBar is still horizontal when it should be vertical ? What are the best practices to make it always adaptable in all poses ?

When the inner screen on iPhone Duo is partially folded and horizontal, what is the best practice to make the UITabAccessory adapt ? How to make it shift to the left or to the right screen and how to size it properly in that case ?

We have some horizontal scrolls in our app. When the Duo is open in landscape mode, the scroll content is displayed below the tab bar. Is this expected? Or should we clip the content?

My main screen is a full screen map of a golf hole, which needs to be tall and narrow. On the inner display I want a panel beside it, but a split arrangement splits vertically when the view is taller than it is wide, which gives the map the wrong shape. What is the intended approach when one split axis works for the content and the other does not?

We can currently get the reserved region's sizes. But as far as I can see, we still need to manually move items out of the way of those regions. Or is there any API besides ArrangementView (e.g. for List items) that does this automatically for us?

We're supposed to keep away from the centre of the screen when Duo is half-folded (some sort of book / laptop-like pose). How do I do it in a right/intended by UIKit engineers way? Sub-Questions below: a) What's the proper way in UIKit, if I only have a frame of region? b) How to understand if division region is vertical or horizontal, and where shall i move my controls out of center? c) Do we get any layout guides for that?

What is the best practice to migrate from custom TabBar (with action button in the middle , in example)? This decision were driven by Design team and had a lot of controversy. But yet it's implemented.

Can an iPhone-only app that fully supports iPhone Duo, but is not otherwise optimized for iPad (and is non-universal), opt out of free-form resizing on iPad?

The HIG says never tie functionality to a pose, but games are called out differently. Will App Review accept a game whose core mechanic requires the hinge and simply can't be played elsewhere? Is a graceful "this needs iPhone Duo" screen acceptable?

Does CMMotionManager report in the same way iPhone Duo orientation as with iPhone? What, when it is folded as a book/laptop?

We have a guided, multi-step setup flow where the user must complete each step in order. One step is an approval gate: after submitting information, the user waits for an approval result before they can continue. They can't navigate back from this screen. On iPhone Duo, what would be the recommended approach when the device is unfolded? Should the approval status remain the primary content on one display while the submitted information or other contextual content is shown on the other, or is this a case where the flow should remain focused on a single display?

Cold launch from a shortcut, universal link, or push is handled in scene(_:willConnectTo:options:). Diiferent functionalities also start Live Activities and reload widgets. If the device is folded, does that scene connect for the outer display, and can the geometry still change before the first frame if the user unfolds? When folded, do Live Activities and widgets appear on the outer display, and is there a separate presentation the app must support?