iPhone Duo SwiftUI Q&A

I’m building a real-time game where the iPhone Duo hinge angle will drive a continuous in-game “reality shift” effect as the device opens and closes. For an interactive game, what update frequency and latency should developers expect from the hinge-angle APIs? Is it appropriate to use continuous hinge updates to drive visual state frame-by-frame, or should apps sample/debounce the values? Also, if the main renderer is not SwiftUI, for example Metal or Unreal Engine through a small native bridge, is there a recommended pattern for observing hinge changes and synchronizing them with the game render loop? I’m especially interested in any guidance around avoiding jitter, delayed updates, or excessive work during rapid folding/unfolding.

For an interactive game effect driven by hinge angle, should the value from DeviceHingeContext generally be consumed directly, or is it expected that an app will apply its own interpolation/smoothing before using the value for animation? Are there recommended practices for handling rapid direction reversals, very small angle changes, or transitions between partially-open and fully-open states without introducing visible jitter?

How often is onHingeChange delivered: every frame, or smoothed and throttled? Is it called with the initial context when the view appears, or only on change? Is there a guaranteed angle range and precision?

My app has a blocking condition that's meant to halt the entire app, not just the current screen — for example a mandatory-update check that must pass before any use, or a security check that should lock the whole app if it fails. Previously, with a single window, blocking that one window effectively blocked the whole app. With multi-window now standard on iPhone Duo, if this condition is detected while running in one scene, does it need to be manually propagated to every other currently-connected scene (e.g. via NotificationCenter or shared app-level state each scene observes), or does Apple provide a built-in mechanism for "this app-wide state changed, all active scenes should react" that I should be using instead of rolling my own?

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?

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?

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?

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.

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?

Hi everyone, I’m developing an iOS application and I’m wondering whether it is possible to position the app on either the left or right side of the screen when running in a dual-window/multitasking configuration. If the app does not occupy the entire screen, can I customize the remaining empty space by assigning a background color or displaying an image? Additionally, if I place a visual element or background in the central/remaining area, could this cause any issues with touch interaction or hit-testing? In particular, I’d like to understand whether the system would still correctly route touch events to the active application, or whether the additional area could interfere with the app’s clickable elements.

We use a PreferenceKey-based pattern to measure real per-row content height in a List (via an invisible .background(GeometryReader { ... }) per row), caching the result in @State keyed by row index, since a fixed height estimate wasn't reliable. This is a common SwiftUI technique, not iPhone-Duo-specific. Apple's guidance on GeometryProxy.reservedRegion covers fold-aware layout for regions affected by the hinge, but I haven't found guidance on whether a live pose change (open → folded, or vice versa, without a relaunch) automatically invalidates cached measurements taken via a PreferenceKey at first layout, or whether SwiftUI's dependency tracking doesn't propagate that kind of external geometry change and the cache needs to be explicitly cleared on a pose-change notification. Is there a specific environment value or notification to observe for "the window's available geometry changed due to a fold event," separate from the standard horizontal/vertical size-class change?

I would love to utilize the whole screen area of the iPhone Duo. To do that, my app needs to show the controls on the side under the status indicators. It works nice if you use system NavigationStacks and TabBars. But what if you don’t? I work on a browser app, and we don’t use system toolbars and tab bars, because they don’t provide enough flexibility for our tasks. For example, playing an icon animation in a tab bar is a bit challenging with the stock TabBar. As far as I know, only system toolbars and tab bars move to the side, and there’s no API to know where this region exactly is. So if you use some custom views you want to present on the side under the status indicators, you may need to guess its location depending on safe area margins, orientation and hinge state. I don’t want to do that, it doesn’t seem reliable. It differs from the previous times screen shape changed. On an iPhone X, you just continued to put interactive content inside safe area, and in many cases you don’t need to go outside it. But in the case of iPhone Duo, you get a blank, unused space on the side, so it feels like we should do something about it. So is there any way for the apps that do not use system tab bars and navigation system to put custom views in that blank area on the side?

On iPhone Duo, is this the recommended pattern for displaying two views, A and B in a splitted way? I would use an ArrangementView configured as follows: When the hinge is closed, display A and B using a regular adaptive HStack/VStack. When the hinge is open, let ArrangementView split A and B across the two displays. Is this the intended way to structure this kind of layout?

For a full-screen game with a Metal/Unreal rendering view and a SwiftUI overlay for touch controls, what is the recommended way to keep interactive controls away from the hinge while still allowing the rendered game world to use the full display? Would you recommend querying ReservedRegion in the SwiftUI overlay while allowing the underlying render view to remain edge-to-edge? Also, should control placement respond continuously while the device is being folded, or primarily respond to layout/reserved-region changes once the pose changes?