I am seeing an asymmetric horizontal inset around the system-provided buttons in App Intents snippets on macOS. The left edge of the button row is almost flush with the snippet card, while the right edge is inset by approximately 16 points. Environment: macOS 27.0 (26A428), Xcode 27.0 (27A266a). My system UI language is Polish, so the system buttons in the screenshots read “Gotowe” (Done), “Anuluj” (Cancel), and “Dalej” (Continue). Steps to reproduce: Create a new macOS App project in Xcode, select a valid signing team, and add the Swift file below to the app target. Keep the generated @main App file. Build and run the app once to register its intents. Run Result Snippet Test from Spotlight Actions. The result view is only a bare Text with no layout modifiers. Run Confirmation Snippet Test from Spotlight Actions. Its confirmation view is also only a bare Text. Repeat both actions in the Shortcuts app. Expected: The system-provided Done button, and the Cancel/Continue row, have balanced left and right insets within the snippet card. Actual: In both Spotlight and Shortcuts, the system button row begins about 1 point from the card's left edge and ends about 16 points before its right edge. The same behavior occurs with one system button and with two. Removing all padding and frame modifiers from the custom view does not change it. import AppIntents import SwiftUI struct ResultSnippetTestIntent: SnippetIntent { static var title: LocalizedStringResource = "Result Snippet Test" static var isDiscoverable = true static var supportedModes: IntentModes = .background func perform() async throws -> some IntentResult & ShowsSnippetView { .result(view: Text("Result snippet")) } } struct ConfirmationContentIntent: SnippetIntent { static var title: LocalizedStringResource = "Confirmation Content" static var isDiscoverable = false static var supportedModes: IntentModes = .background func perform() async throws -> some IntentResult & ShowsSnippetView { .result(view: Text("Confirmation snippet")) } } struct ConfirmationSnippetTestIntent: AppIntent { static var title: LocalizedStringResource = "Confirmation Snippet Test" static var supportedModes: IntentModes = .background func perform() async throws -> some IntentResult { try await requestConfirmation( actionName: .continue, snippetIntent: ConfirmationContentIntent() ) return .result() } } struct SnippetButtonInsetShortcuts: AppShortcutsProvider { static var appShortcuts: [AppShortcut] { AppShortcut( intent: ResultSnippetTestIntent(), phrases: ["Show result snippet in \(.applicationName)"], shortTitle: "Result Snippet Test", systemImageName: "rectangle.dashed" ) AppShortcut( intent: ConfirmationSnippetTestIntent(), phrases: ["Show confirmation snippet in \(.applicationName)"], shortTitle: "Confirmation Snippet Test", systemImageName: "rectangle.on.rectangle" ) } } Is this a known layout issue in the macOS snippet presenter? Is there a supported way to control the insets of the system-provided button row, or a workaround that keeps the snippet in Spotlight and Shortcuts?

Hello UIKit team, When building custom multi-column layouts with UICollectionViewCompositionalLayout that must dynamically span or split across the iPhone Duo's .division reserved region during continuous hinge motion: What is the recommended strategy for handling UICollectionViewLayoutInvalidationContext during live fold/unfold gestures? Specifically, does the system coalesce intermediate trait changes (registerForTraitChanges) to allow smooth orthogonal scrolling without constantly purging cached layout attributes or triggering full cell rebinds? When adapting custom container view controllers using viewWillTransition(to:with:), should we coordinate layout updates through the UIViewControllerTransitionCoordinator's animate(alongsideTransition:), or does UIKit provide a dedicated layout guide / accessory pipeline that guarantees zero hitch when the trailing/leading safe area insets flip dynamically around the physical crease? Thanks!

If we have create a custom Navigation back item, while running on iPhone Duo simulator, we see it at normal position i.e. on screen's top left side. How can we move it to the safe area like when we use default back button?

Our app performs security checks (compromised-device detection, certificate pinning setup) once per app launch inside SceneDelegate's willConnectTo:options: and on scene-becomes-active. Given developer coverage states every app participates in iPhone Duo's multi-window support whether it opts in or not, and each window is presumably backed by its own scene/SceneDelegate instance: does opening a second window on the inner display spawn an independent scene that would re-run (or fail to run) this per-scene setup? For an app with security checks tied to scene lifecycle rather than app-level AppDelegate lifecycle, is there existing guidance on whether such checks should run per-scene, be coordinated across scenes via a shared app-level state, or whether Apple recommends opting out of multi-window support entirely for apps where per-window security state doesn't make sense (e.g. a single authenticated session shouldn't have divergent security state across two windows of itself)?

I use an icons-only UISegmentedControl in the toolbar. For iPhone Duo, I’d like to place this segmented control in a vertical layout in the righthand control area. How can I achieve that?

I have a destructive action exposed as a toolbar item, which might be collapsed into a ToolbarOverflowMenu. I'd present the delete confirmation as a confirmation dialog anchored to the button that triggered it. But when the action is inside the overflow menu, the menu item isn't a view I can anchor it to. What's the recommended pattern for the delete confirmation in that case? Is an alert the intended fallback, is there a supported way to anchor a confirmation dialog to a toolbar overflow item, or would you recommend a different approach altogether?

I’m using a UITabBarController with fixed UITabs and sidebarOnly UITabs, on an iPhone Duo I’m seeing the sidebarOnly tabs show up regardless of sidebar.preferredPlacement. Is this expected? I’m trying to achieve the same behavior as the Health app as shown in the developer videos. I have a feeling that I might need to check for the horizontal size class, but I feel like the API should be doing the work of hiding the sidebarOnly tabs, no? Also, when setting tabBarController.sidebar.preferredPlacement = .sidebar and collapse it I don’t see the sidebar when I collapse on the inner display using Xcode 27.1. I think this is a bug?

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.

We ship a large production app that mixes UIKit and SwiftUI. We're planning our iPhone Duo support, but until we adopt the latest SDK, we want to understand how compatibility mode applies to our current builds. Is there a canonical way to preview our app in compatibility mode across all iPhone Duo poses? We can build with Xcode 26.6 and run on the iPhone Duo simulator, but we can't switch poses and it's unclear whether that matches the real compatibility mode on device. We'd like to see how the app responds to each pose so we're confident in the experience users will get at launch.

It would be great if Apple could provide a sample app covering all the cases for iPhone Duo, an app that follows best practices when it comes to handling UI and works on normal iPhones, iPhone Duo and iPad. Also if I remember correctly it's been a long time since we got a UIKit sample app.

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?

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?