A Summary of the iPhone Duo Group Lab

This thread has been locked by a moderator; it no longer accepts new replies.

Group Labs are a unique opportunity for the community to submit questions directly to a panel of Apple engineers and designers. Here are the highlights from the iPhone Duo Group Labs:

How should apps preserve navigation and UI state when switching between the inner and outer displays?

Treat display transitions as size-class and trait changes, not a scene disconnect or app termination; your process stays alive. For more information, see Prepare your app for iPhone Duo. For state that must survive a scene disconnect/reconnect, implement stateRestorationActivity(for:) to save an NSUserActivity Restoring your app's state.

Do multiple instances of the same app on iPhone Duo share UserDefaults/@AppStorage state?

Multiple instances of your app's UI on iPhone Duo behave similarly to multi-window support on iPadOS. To learn more, see Leverage multiple displays and scenes on iPhone Duo. Both UserDefaults and AppStorage are app-wide, not per-window, stores.

If a full-screen app on the inner display is closed, does it move to the outer display or get backgrounded?

iPhone Duo honors UIRequiresFullScreen and apps adapt in place as the device opens and closes rather than backgrounding. To learn more, watch Prepare your app for iPhone Duo.

How should apps preserve state — text input, scroll position, video playback, camera sessions — during hinge angle transitions? For example, when a LazyVGrid's column count changes because the device folds, does SwiftUI preserve scroll position automatically, or should you use scrollPosition(id:)?

The system generally preserves text input and scroll position automatically since hinge angle changes are represented as size-class and trait updates, not a scene disconnect or app termination. This applies even to cases like a LazyVGrid column-count change triggered by opening or closing the device — apps typically don't need to manually manage scroll position with scrollPosition(id⚓ ) for this transition. For more info, see Prepare your app for iPhone Duo.

How can apps preserve what someone is doing when switching displays or folding/unfolding?

Treat this as a resize/trait-change event, not app teardown — your process keeps running as size classes change. See Prepare your app for iPhone Duo to learn more. For scenes that actually disconnect and reconnect, implement stateRestorationActivity(for:) to save an NSUserActivity Restoring your app's state.

How does actively playing video behave through the hinge angle animation?

The system generally preserves video playback and player position automatically since hinge angle changes are represented as size-class and trait updates, not a scene disconnect or app termination. AVKit will scale and resize the video automatically.

If a user folds or unfolds the device mid-checkout, what does the system preserve automatically, and what should the app manage itself to avoid lost input or duplicate requests?

When someone opens or closes an iPhone Duo, the system represents this as a size-class and trait collection change, not a scene disconnect or app teardown, so in-memory state like input fields typically persists automatically since the app’s process keeps running. For more info, see Prepare your app for iPhone Duo.

How should apps handle the keyboard and text input when the device folds or unfolds while typing?

As iPhone Duo folds or unfolds, the available screen geometry and framing change. Ensure your app adopts standard layout controls, containers, and size classes to handle resizability gracefully across all poses. When a text field becomes first responder, the system automatically shows the keyboard and binds its input to the text field. Because the appearance of the keyboard has the potential to obscure portions of your user interface, you should update your interface as needed to ensure that the text field being edited remains visible. Use keyboard notifications such as keyboardWillShowNotification, keyboardWillHideNotification, and keyboardWillChangeFrameNotification to detect the appearance and disappearance of the keyboard and to make necessary changes to your interface layout. To learn more, see UITextField.

If someone is typing and closes iPhone Duo, does the keyboard/editing session survive the hinge transition, or does it get a new scene?

When a user types and closes iPhone Duo, the active editing session and keyboard do not get a completely new scene. Instead, the app undergoes a dynamic resizing and transitions from the inner display to the compact outer display, maintaining the existing scene and application state. For more info, watch Prepare your app for iPhone Duo.

(Continued)

Can an app present content on the outer display while it's is in a standing position (like a tent), similar to the demoed alarm clock?

Yes for apps displaying camera previews or apps adopting AlarmKit. For camera previews, register a scene accessory (sceneAccessory(content:) in SwiftUI, or registerSceneAccessory(_:) in UIKit) on your main view, and the system decides when to show it on the outer display Leverage multiple displays and scenes on iPhone Duo. For AlarmKit, see Scheduling an alarm with AlarmKit.

Are there restrictions on animation or update rates for scene accessories on the outer display?

On iPhone Duo, scene accessories are system-controlled for presentation timing and availability. Your app registers accessory content declaratively (sceneAccessory(content:) in SwiftUI or registerSceneAccessory(_:) in UIKit), and the system decides when to display it. The system can withdraw the content at any time, for example, when the device closes, the app leaves the foreground, or the capture session ends. Design your animations so they can start, pause, and stop cleanly at any point. To learn more, see Registering a camera capture accessory on iPhone Duo. If your accessory content needs custom-timed animation, use TimelineView or CADisplayLink to synchronize with the display's refresh rate, the same as on any other display. See Optimizing ProMotion refresh rates for iPhone and iPad for more details.

How do I build an alarm-clock-style app with the main interface on the outer display while standing folded like a tent?

When adopting AlarmKit for iPhone Duo, (a) ensure your app’s alarm-management scenes are resizable and render appropriately for all size classes, and (b) design a good Live Activity for the countdown state to let AlarmKit, StandBy, or Dynamic Island handle the actual alert presentation across displays. To learn more, see Prepare your app for iPhone Duo and Scheduling an alarm with AlarmKit.

How does audio mixing work with two instances of my app open on iPhone Duo — can I control each instance's volume independently?

Each instance is its own UIScene/window, the same multi-instance model as iPad. However, the active audio and video playback is associated with the most recent app which began the playback session.

Are there accessibility nuances specific to iPhone Duo we should consider?

Because iPhone Duo shares design patterns with iOS, standard accessibility practices and guidelines for iOS still apply. When designing for this new form factor, maintain consistent functionality across device poses and ensure your interface remains adaptable and accessible. Use Xcode and Device Hub to simulate your app on iPhone Duo across its various poses. Verify that your app supports Dynamic Type, sufficient color contrast, proper VoiceOver descriptions, and seamless resizing as the device opens, closes, or folds. To learn more, see Designing for iPhone Duo.

Can apps use both screens at once to enable new features?

Yes, through scene accessories, which present different, coordinated content on both displays simultaneously — for example, a camera accessory showing a teleprompter on the outer display while the main capture UI stays on the inner display Leverage multiple displays and scenes on iPhone Duo. Apps can also use Split View multitasking and multiple scene instances to show related content in separate windows.

Which widget families and how many widgets are supported on iPhone Duo's Lock Screen, and does this differ between the inner and outer displays?

iPhone Duo supports system family widgets (WidgetFamily.systemSmall, WidgetFamily.systemMedium, WidgetFamily.systemLarge, and WidgetFamily.systemExtraLargePortrait) as well as accessory widget families (WidgetFamily.accessoryCircular, WidgetFamily.accessoryRectangular, and WidgetFamily.accessoryInline) depending on the display and context. The inner and outer displays of iPhone Duo handle widget families and contexts similarly to the broader iOS and iPadOS ecosystems, where small, medium, and large system widgets appear on the Home Screen and Today View, while accessory widgets appear on the Lock Screen. For more information, see WidgetFamily.

Will Safari/WebKit expose new APIs, including hinge-specific ones, for web pages to detect iPhone Duo poses and hardware features?

Yes, there are the Viewport Segments and Device Posture APIs. Both are opt-in experimental features in iOS 27.1, and can be enabled for testing in Settings > Apps > Safari > Advanced > Feature Flags.

(Continued)

Are there APIs that let a custom tab bar behave like UITabBar on iPhone Duo?

No, not directly. Use the system-provided containers such as TabView (SwiftUI) and UITabBarController (UIKit) to receive automatic adaptive behavior, such as vertical placement, sidebar, overflow menu items. For apps that must stay custom, use ReservedRegion (SwiftUI) and UIView.ReservedRegion (UIKit) and the toolbarVerticalEdge (SwiftUI) and verticalBarEdge (UIKit) trait to detect vertical-bar presentation and reposition your own UI accordingly. To learn more, see Preparing your app for iPhone Duo.

Can non-camera apps display content on the outer display while unfolded?

Only via the system-controlled scene accessory mechanism — not by drawing on the outer display directly. UISceneAccessory / sceneAccessory(content:) let an app declare content the system may present on another display, but the system decides whether and where it actually appears Leverage multiple displays and scenes on iPhone Duo.

Are there new APIs in iOS 27 specifically designed for foldable layouts?

Yes, and the following API are available on iOS 27.1 and later: ArrangementView (SwiftUI) / UIArrangementViewController (UIKit) for split/overlay layouts across the hinge area; ReservedRegion (SwiftUI) / UIView.ReservedRegion (UIKit) to detect fold and camera occlusion; onHingeChange (SwiftUI) / UIHingeInteraction (UIKit) for hinge angle/status; and toolbarVerticalEdge / verticalBarEdge for vertical bar layouts Preparing your app for iPhone Duo.

Are arrangement views exclusive to iPhone Duo, or can they be used on any iPhone with iOS 27?

ArrangementView in SwiftUI and UIArrangementViewController(UIKit) are general iOS 27 layout containers that work on any iPhone or iPad. These UI types are just especially useful on iPhone Duo because they adapt to reserved regions like the hinge area. To learn more, see Designing for iPhone Duo.

How do I get device attitude oriented to what's displayed on screen?

To receive processed device-motion data, including the device's attitude, call startDeviceMotionUpdates(using:) on a CMMotionManager instance to begin receiving motion updates relative to a specified reference frame. Your view conforms to CMBodyIdentifiable, which lets you tell Core Motion which body — physical display — your app's UI currently occupies. Set the deviceMotionBody property on your motion manager instance to that view, and the system automatically transforms the sensor values to align with your UI's actual orientation, based on whether it's shown on the inner or outer display. Then, continue reading CMDeviceMotion.attitude as you always have. The values arrive already corrected for that body's current orientation — including which face is up — whenever your app is full screen on the display hosting your UI. If your scene isn't full screen, body-relative orientation isn't available, and you receive motion data in the device's default reference frame instead. To learn more, see Getting processed device-motion data and Sensor coordinate orientation.

Does my app need to know which face is up?

No. Use size classes and trait collections so your UI adapts to the available space.

Does iPhone Duo support an external-monitor, iPad-style Stage Manager experience?

No. iPhone Duo does not support Stage Manager. Instead, iPhone Duo brings powerful multitasking features like Split View, where two apps can be placed in a side-by-side layout, and support for multiple instances of an app's UI on its inner display. To learn more, watch Leverage multiple displays and scenes on iPhone Duo.

Can an app control when its scene accessory appears on the outer display, independent of camera state?

No. The system determines whether and where to present it — for CameraCaptureAccessory, the system shows it only while the app is in the foreground with an active capture session CameraCaptureAccessory. Apps can toggle their own content via isEnabled, but can't override system presentation decisions Leverage multiple displays and scenes on iPhone Duo.

Will there be a way for web apps to detect if the device/layout is an iPhone Duo?

No, web developers should be using responsive web device principles to adapt to various screen sizes and layouts, rather than detect the device type.

Does iPhone Duo support multiple windows?

Yes. It's the first iPhone to support multiple instances of your app's UI, following iPad's scene-based multi-window model — though new windows can only be created on the inner display, not the outer one Leverage multiple displays and scenes on iPhone Duo.

(Continued)

Can an app present content on the inner display while in standing folded (like a tent), similar to the alarm clock demo?

Yes, via scene accessories — the same mechanism behind that demo. Register a UISceneAccessory (sceneAccessory(content:) in SwiftUI, registerSceneAccessory(_:) in UIKit) and the system decides when to present it Leverage multiple displays and scenes on iPhone Duo.

For a custom grid or layout that spans the hinge, do we need to manage VoiceOver focus order ourselves?

When building a custom grid or layout that spans the hinge on iPhone Duo, you generally do not need to manually manage the VoiceOver focus order from scratch if you rely on standard accessibility containers and grouping mechanisms. SwiftUI and UIKit automatically manage accessibility elements and their traversal order based on the view hierarchy. However, for custom layouts or views that cross structural boundaries like folding regions, you may need to explicitly define accessibility containers or adjust sort priorities to ensure assistive technologies navigate the content in a logical sequence. For more detail, see Inspecting the accessibility of the screens in your app.

What's the recommended way to combine navigation views with ArrangementView, since they don't work well together directly?

Keep navigation outside arrangement views — an arrangement view lays out content but doesn't handle navigation, so place navigation containers like NavigationSplitView or TabView around it, not inside it, per the guidance in Designing for iPhone Duo.

What's the recommended pattern for a confirmation dialog triggered from a ToolbarOverflowMenu item, since the menu isn't a view to anchor to?

When working with ToolbarOverflowMenu (SwiftUI) and additionalOverflowItems (UIKit), actions are placed directly into the toolbar's overflow menu. Because the menu itself is managed by the system and is not a view you can directly anchor to, presenting a confirmation dialog requires standard state-driven presentation rather than attaching the modifier to the menu item directly. In SwiftUI, combine the ToolbarOverflowMenu and the confirmationDialog modifier by linking them to a shared state variable within your view structure. To learn more about overflow menus, see Designing for iPhone Duo.

How does Picture in Picture work on iPhone Duo, and can the PiP window move to the outer display?

Picture in Picture (PiP), via AVPlayerViewController or AVPictureInPictureController, behaves similarly as on other devices, minimizing playback into a small floating window. To learn more about PiP, see Adopting Picture in Picture in a standard player. When a video plays in PiP on iPhone Duo while fully open in landscape, a person can pin the PiP window to the top of the screen to keep watching while the current app resizes vertically to fit the remaining space. If the device is partially folded, the video automatically extends to fill half of the screen, allowing apps to adjust vertically to different video sizes in real time. However, the PiP moves to the outer display only when the device is closed and the system controls its transition across displays.

If a custom UI element overlaps the camera's reserved region without adopting the reserved-region APIs, does touch still register there, or get suppressed?

When a custom UI element overlaps a hardware-reserved region such as the camera without adopting the appropriate reserved-region APIs, touch events in that area are suppressed or may not register as expected. To ensure your interface correctly accounts for occlusions like the camera or Dynamic Island, use ReservedRegion (SwiftUI) or UIView.ReservedRegion (UIKit) and query intersecting regions using reservedRegions(kind:options:layoutDirectionBehavior:) (SwiftUI) or reservedRegions(kind:options:) (UIKit).

Do live notifications need any special adaptation regarding the Dynamic Island on iPhone Duo?

On iPhone Duo, the outer display has a front-facing camera, which is positioned within a reserved region. This region is always present, and expands into the Dynamic Island for Live Activities. When controls are on the side, the system automatically accounts for it and arranges elements accordingly. Every Live Activity must implement all required presentations within its ActivityConfiguration, including compactLeading, compactTrailing, minimal, and the expanded region layouts, alongside the Lock Screen presentation. For more information, see Displaying live data with Live Activities.

Does the standalone UITabBar class (used outside UITabBarController) support vertical bar placement?

iPhone Duo's vertical bar adaptation is tied to the navigation containers (TabView in SwiftUI and UITabBarController in UIKit), not the standalone bars (toolbar in SwiftUI and UITabBar in UIKit). For more detail, watch Raise the bar with iPhone Duo.

(Continued)

My app uses a fully custom (non-SwiftUI/UIKit-native) tab bar — what APIs are available to move it to the side on iPhone Duo?

There's no API that moves a custom tab bar for you. Use ReservedRegion (SwiftUI) / UIView.ReservedRegion (UIKit) to detect the hinge area or camera regions, and toolbarVerticalEdge (SwiftUI) / verticalBarEdge (UIKit) to detect vertical-bar presentation, then reposition your custom view yourself to match. To learn more, see Preparing your app for iPhone Duo.

Is there an API to directly set or modify a window scene's size?

No, UIWindowScene's API centers on observing geometry/size changes, not requesting a specific size. Scene size on iPhone Duo is driven by device pose and Split View, aside from the multi-window activation flow on the larger inner screen. For more info, watch Leverage multiple displays and scenes on iPhone Duo.

For a mixed UIKit/SwiftUI codebase, should we use compact/regular size classes for most screens and reserve iPhone Duo region/arrangement APIs only for hinge-specific experiences?

That's a reasonable approach, though not an explicit catch-all recommendation. When designing an adaptable user interface for a mixed UIKit and Swift/SwiftUI codebase, use horizontal and vertical size classes (horizontalSizeClass and verticalSizeClass) rather than checking device types or orientations. Size classes describe the actual available space in a given dimension, allowing your app to resize gracefully across different device configurations and multitasking states. Specialized layout containers and APIs—such as ArrangementView / UIArrangementViewController and reserved region APIs (ReservedRegion in SwiftUI or UIView.ReservedRegion in UIKit)—should be reserved for custom UI or specialized experiences where content must deliberately avoid folding regions, hardware cutouts, or specific display features. For standard layouts, standard size classes and system layout guides are sufficient. Only employ fold-specific and region-specific arrangement APIs when building custom edge-to-edge UI, custom bars, or handling complex multi-display arrangements where standard layout behavior needs explicit adjustment around a hinge. For more info, see Prepare your app for iPhone Duo.

Can audio experiences be pinned to the top (outer) screen during multitasking, similar to video PiP?

No. Picture in Picture (PiP) functionality in AVKit is designed specifically for video playback and video calls, allowing users to minimize a video player to a floating window while performing other activities. Currently, the system-provided PiP interfaces, such as AVPlayerViewController and AVPictureInPictureController, do not support pinning audio-only players to the screen in a manner similar to video PiP. For audio-only content, standard system recommendations rely on background audio handling and the Now Playing interface rather than a visual PiP window.

Is it worth adding multi-window (scene) support, or do single-window apps feel unnatural on iPhone Duo?

That's a subjective call, but the mechanics are the same as iPad. iPhone Duo is the first iPhone to support multiple instances of your app's UI, and if your app supports it on iPad, it will on the inner display of iPhone Duo. Watch Leverage multiple displays and scenes on iPhone Duo to learn more.

Is the ellipsis icon fixed for the toolbar overflow menu, or can we specify a custom icon?

The system automatically manages the toolbar overflow menu in iPadOS and macOS when items no longer fit in the available space. According to the Human Interface Guidelines, you should reserve the ellipsis symbol for overflow and use the system-provided overflow menu rather than adding one manually. To define custom content that the system always places in the toolbar's overflow menu regardless of the toolbar mode or platform, use ToolbarOverflowMenu in SwiftUI or additionalOverflowItems in UIKit. To learn more, see Toolbars.

Can iPhone Duo apps be built exclusively in SwiftUI, or is UIKit also supported?

Both are fully supported. Apple documents equivalent SwiftUI and UIKit APIs for every iPhone Duo-specific capability — hinge, arrangement views, scene accessories Preparing your app for iPhone Duo.

Should developers move fully to SwiftUI instead of UIKit for iPhone Duo and future releases?

That's not an explicit recommendation. Apple provides equivalent SwiftUI and UIKit APIs for every iPhone Duo capability.

(Continued)

Does Dynamic Type or accessibility differ on iPhone Duo, and are there changes developers need to make?

iPhone Duo introduces a foldable design featuring a compact outer display and a large inner display. When considering Dynamic Type and general accessibility features on iPhone Duo, the device behaves consistently with the broader iOS ecosystem. The system handles text scaling and accessibility settings seamlessly across both the inner and outer displays, utilizing established APIs like preferredContentSizeCategory and traits to respect user preferences. Use Xcode and Device Hub to simulate various poses—such as closed, open, and partially folded—to verify that your text scaling, Dynamic Type implementation, and UI layouts adapt correctly without clipping or truncation. To learn more, see Preparing your app for iPhone Duo and iPhone Duo Group Lab.

For a non-scrolling, one-screen layout, should accessibility text sizes reflow into scrolling, or hold at the largest standard size?

When designing a non-scrolling, one-screen layout, accessibility text sizes should generally reflow or adapt to ensure content remains readable without forcing users to rely on system zoom tools. According to App Store Connect evaluation criteria for Larger Text, primary content should scale as large as possible while retaining usability and information hierarchy. Specifically, iOS and iPadOS support Dynamic Type scales that reach past 200% at the AX3 size and over 300% at the AX5 size. For fixed, one-screen layouts, holding text at the largest standard size instead of allowing it to reflow or scale can fail accessibility guidelines. To learn more, see Larger Text evaluation criteria.

Can I present multiple instances of my app in the inner display like Safari?

Yes. iPhone Duo supports multiple simultaneous scene instances of your app's UI via the standard windowing APIs on the inner display, the same as iPad. To learn more, watch Leverage multiple displays and scenes on iPhone Duo.

Does iPhone Duo require apps to support multiple UIScenes for fold/unfold, and when is that recommended?

It's not required universally. Multiple scenes matter specifically for Split View multitasking with multiple app instances and for scene accessories — hinge angle resizing is just a trait/geometry change to the existing scene Leverage multiple displays and scenes on iPhone Duo.

UITab/UITabBarItem only support title/image/badge — is UITabAccessory the only way to add custom content like a dot indicator or animation to a tab item?

Yes. UITabAccessory exists precisely to add custom content beyond title/image/badge. Attach it via bottomAccessory, and it lays out either regular (above or at the bottom of the tab bar) or inline with the collapsed bar, per UITabAccessory.Environment. However, instead of custom dot indicators or complex custom views embedded directly into individual tab items, you can use the standard badge APIs to display status updates, counts, or indicators cleanly across device layouts. For more info, watch Raise the bar with iPhone Duo.

For a full-screen map with a panel that opens beside it, is ArrangementView the intended container, or should the panel only appear when folded?

ArrangementView is the intended container. Apple recommends it specifically for layouts that already resemble a primary/secondary structure — two views side by side or one above the other translates directly to a split arrangement Designing for iPhone Duo.

Does UIArrangementViewController work on other iPhones and on iPad, or only iPhone Duo?

While ArrangementView (SwiftUI) and UIArrangementViewController (UIKit) adapts to various contexts and hardware features like folding regions, the standard UIKit availability guidelines for the running iOS or iPadOS SDK version determine explicit availability across specific iPhone and iPad models. These APIs are available on all iOS devices running 27.1 and later. To learn more, see Designing for iPhone Duo.

Can developers use the dual camera and display features to build FaceTime-style experiences?

Yes. On iPhone Duo, the Virtual Front Camera automatically selects the relevant physical camera, and AVCaptureDeviceDirectionCoordinator manages which camera faces the user as the device opens and closes. Scene accessories let apps show content on both displays simultaneously, similar to pairing a subject-facing view with the main capture UI. To learn more, watch Build a great camera experience for iPhone Duo.

How do I detect which pose the device is in?

There's no single system-provided pose value. Use the discrete hinge status (closed, partially open, fully open) and continuous hinge angle from onHingeChange (SwiftUI) or UIHingeInteraction (UIKit), and infer the pose from angle, orientation, and size class together Leverage multiple displays and scenes on iPhone Duo.

Can we read the current hinge angle (e.g., 30°, 45°) directly?

Yes, onHingeChange (SwiftUI) and UIHingeInteraction (UIKit) expose a continuous, live hinge angle alongside the discrete open/closed status. Use it for live interactions and effects; for layout decisions, use the arrangement and reserved-region APIs instead. For more details, see Leverage multiple displays and scenes on iPhone Duo.

(Continued)

Is the CoreMotion reference frame fixed to the chassis, or normalized to the active display, on iPhone Duo?

Core Motion behavior, reference frames, and coordinate axes are determined by the physical sensors onboard supported devices as defined by CMMotionManager. For more information, see Getting processed device-motion data and Device sensors.

How precise/reliable is hinge angle for driving gameplay mechanics?

Hinge data is observed live and is ideal for driving interactions or effects, while layout should use the arrangement and region APIs instead. The rate and granularity of hinge angle updates are system policy and can change based on system state, so don't depend on a particular update frequency or precision. See Leverage multiple displays and scenes on iPhone Duo to learn more.

Will iPhone Duo have a Dynamic Island?

Yes. The outer front-facing camera region expands into the Dynamic Island for Live Activities, and it's laid out vertically alongside the status bar, toolbar, and tab bar on the outer display Designing for iPhone Duo.

How does an app detect that the iPhone Duo is fully extended to exactly 90°, versus partially open?

Use the discrete hinge status (closed, partially open, fully open) and continuous hinge angle from onHingeChange (SwiftUI) or UIHingeInteraction (UIKit). However, you can also utilize the ArrangementView (SwiftUI) and UIArrangementViewController (UIKit) API to compose arrangement styles, such as split or overlay, based on layout and hinge status. For more information, see Leverage multiple displays and scenes on iPhone Duo.

Is there an API to read the relative spatial axis/orientation of both displays independently, for something like a leveling tool or 3D compass?

To receive processed device-motion data, call startDeviceMotionUpdates(using:) on a CMMotionManager instance to begin receiving motion updates relative to a specified reference frame. Your view conforms to CMBodyIdentifiable, which lets you tell Core Motion which body — physical display — your app's UI currently occupies. Set the deviceMotionBody property on your motion manager instance to that view, and the system automatically transforms the sensor values to align with your UI's actual orientation, based on whether it's shown on the inner or outer display. Then, continue reading CMDeviceMotion.attitude as you always have. The values arrive already corrected for that body's current orientation — including which face is up — whenever your app is full screen on the display hosting your UI. If your scene isn't full screen, body-relative orientation isn't available, and you receive motion data in the device's default reference frame instead. To learn more, see Getting processed device-motion data and Sensor coordinate orientation.

Do Dynamic Island interactions change when both displays are in use, or should we treat it the same as on current iPhones?

iPhone Duo continues the path of adapting user interfaces to special regions like the Dynamic Island. When the device is closed or in different poses, the Dynamic Island and status bar are positioned vertically on the side of the display along with toolbars and tab bars to maximize vertical space for content. Rather than treating iPhone Duo entirely differently or designing custom layouts for every single pose, build your app using standard dynamic layout practices, layout margins, safe area insets, and size classes. The outer display behaves with a compact horizontal size class in portrait, while the inner display provides regular horizontal and vertical size classes. To learn more, see Prepare your app for iPhone Duo.

When iPhone Duo is partially folded in an L shape, can an app receive touch input from both displays at once?

Yes. The hinge divides the inner display into multiple usable regions, and system components like alerts, sheets, and split views adapt around it automatically Designing for iPhone Duo. Apple's Split View demo confirms both sides can host active, interactive content simultaneously Leverage multiple displays and scenes on iPhone Duo.

Can an app be released exclusively for iPhone Duo?

When building and distributing an app for iPhone Duo, you’re still designing for iPhone, so existing iOS patterns and best practices still apply. iPhone Duo continues to honor UIRequiresFullScreen and your declared orientations, and iOS apps run on iPhone Duo even without adopting the iOS 27 SDK. To learn more, watch Prepare your app for iPhone Duo.

Will iPad apps be able to run in a compatibility mode on iPhone Duo, similar to how iPad apps run on Apple Vision Pro?

No. Unlike Apple Vision Pro, which runs iPad and iPhone apps in a standalone window designed to emulate an iPad layout automatically, iPhone Duo introduces dynamic folding poses and resizability mechanics that scale applications based on the compiler version and SDK used. When iPhone Duo becomes available, apps that have not yet been updated or linked against newer SDKs will run in a compatibility mode on the displays. On the cover display, the app appears with the aspect ratio of an iPhone mini, complete with a letterbox where the vertical bar resides. On the inner display, the system centers that same aspect ratio on the screen. For more info, see iPhone Duo Group Labs.

How can existing apps minimize letterboxing/pillarboxing and use more of the screen during the Xcode 27 transition?

Prefer changing aspect ratio over letterboxing/pillarboxing, especially for games, and add artwork to any unavoidable padding so it still feels full-screen Designing for iPhone Duo. Build with Xcode 27.1 or later — apps built with earlier SDKs don't extend under the status bar and camera, so they show more letterboxing by default Preparing your app for iPhone Duo.

(Continued)

How are apps built with the iOS 26 SDK (not yet iPhone Duo-aware) presented across poses?

They still run and resize, but use less of the display: closed, they sit left of the status bar and camera; open, they render at a familiar iPhone aspect ratio rather than extending fully. Rebuilding with iOS 27 or 27.1 SDKs progressively extends the app further under the status bar and camera Prepare your app for iPhone Duo.

My app needs months of work to support iPhone Duo — can I disable screen stretching and keep regular iPhone behavior on Xcode 27?

Yes, that’s the default. iPhone Duo honors UIRequiresFullScreen, and your app still resizes as the device opens and closes, but apps that haven't adopted the new SDK keep a familiar iPhone size and aspect ratio, simply using less of the available screen Prepare your app for iPhone Duo.

What best practices should developers follow when adapting an existing app for iPhone Duo?

Follow these best practices to adapt smoothly for iPhone Duo:

  • Use size classes for layout decisions rather than UIUserInterfaceIdiom or interface orientation
  • Handle safe-area insets independently on each side, since they're often asymmetric
  • Build flexible, size-class-driven layouts instead of hard-coding fixed iPhone-specific dimensions
  • Let the system's default vertical bar placement do its job rather than overriding it unnecessarily

Following these practices helps your app adapt cleanly across all iPhone Duo poses and displays. To learn more, see Preparing your app for iPhone Duo.

What's the best way to support the new iPhone Duo APIs while maintaining compatibility back to iOS 16?

In general, gate iOS 27.1 APIs (ArrangementView , ReservedRegion, onHingeChange, etc.) behind availability checks, and build your baseline layout on the same size-class-driven approach Apple recommends for all iPhone apps. Size classes and safe area insets are available well before iOS 16, so this foundation degrades gracefully. To learn more, see Preparing your app for iPhone Duo.

Can an immersive AR app be locked to full screen only?

Yes, using UIRequiresFullScreen. It continues to be honored on iPhone Duo, though your app still resizes as the device opens and closes Prepare your app for iPhone Duo.

Will ArrangementView be supported on older iOS versions?

Both ArrangementView and UIArrangementViewController are available on iOS 27.1 and later. These APIs are unavailable on iOS 27.0 or earlier.

What does compatibility mode look like in portrait orientation?

In general, apps built without the iOS 27 SDK use the screen space to the left of the status bar and camera when closed, and render at a familiar size and aspect ratio when open. As mentioned in Prepare your app for iPhone Duo, iPhone Duo will continue to honor the UIRequiresFullScreen key, but your app will still resize when someone opens or closes their iPhone Duo. As soon as possible, you should remove UIRequiresFullScreen and adopt size-class-driven resizing. To learn more, see TN3192: Migrating your iPad app from the deprecated UIRequiresFullScreen key.

In black-frame compatibility mode on the inner display, is a portrait-only app's UISupportedInterfaceOrientations honored, and does this differ between the iOS 27 and 27.1 SDKs?

Yes, iPhone Duo still honors UISupportedInterfaceOrientations, but the expected behavior for this device differs from previous iPhone devices in certain hinge states and orientations. Instead, use size classes to handle sizing constraints and adapt your layout dynamically to the available space across all device. Apps built with the iOS 26 SDK render at a familiar iPhone size and aspect ratio rather than filling the inner display. Building with the iOS 27 SDK extends further under the status bar, and iOS 27.1 is required for full edge-to-edge layout. To learn more, watch Prepare your app for iPhone Duo.

Can an app require specific iPhone Duo capabilities, or must an iPhone Duo-adapted app also support the full iPhone family?

iPhone Duo apps don’t need to require specific device capabilities or isolate themselves to the foldable form factor exclusively. Apple designs the iOS ecosystem so that apps can adapt dynamically across the entire iPhone family, including traditional single-screen devices and the dual-screen foldable iPhone Duo.

If my app only optimizes for iPhone, do I also need iPad support to optimize for iPhone Duo?

No, support for iPad is not required for building apps for iPhone Duo. Updating your app to support iPad does help with understanding larger layouts and multi-tasking behaviors, but adopting standard layout controls, size classes, and scene geometry is sufficient on its own. For more info, see Preparing your app for iPhone Duo.

(Continued)

For existing UIKit apps, what's the recommended approach for adapting layouts and navigation between folded and unfolded states?

Adopt standard layout controls and containers, use size classes and scene geometry instead of fixed dimensions, and handle reserved regions for the hinge Preparing your app for iPhone Duo. For navigation, use UISplitViewController — it's fully adaptive, collapsing to single-stack navigation when closed and tiling when open Prepare your app for iPhone Duo.

Can apps built for iPad move easily to iPhone Duo?

Apps that already resize well on iPad and Mac, or that support iPhone Mirroring, are well on their way to supporting iPhone Duo. However, iPhone Duo introduces its own considerations like vertical bars, reserved regions, and the hinge that iPad layouts don't need to handle. To learn more, see Preparing your app for iPhone Duo.

My app manually creates UIToolbars as subviews — how should I adapt this for iPhone Duo while keeping regular-device support?

Migrate to standard toolbar items on a navigation-controller-managed view controller instead of a manually created UIToolbar subview Preparing your app for iPhone Duo. This gets automatic vertical-bar and overflow-menu behavior on iPhone Duo while remaining a normal horizontal toolbar elsewhere.

Our custom tab bar uses Lottie animations for its items — can we keep using it on iPhone Duo, and what should we watch for?

It won't adapt automatically since it's not UITabBar/UITabBarController. Migrate to standard tab bar components to get automatic vertical-placement, sidebar, and overflow behavior Preparing your app for iPhone Duo. If the custom bar must remain, use ReservedRegion and toolbarVerticalEdge/verticalBarEdge to detect and manually reposition it.

If our iPad app already uses TabView and Split View multitasking, will the corresponding iPhone app adapt automatically for iPhone Duo just by rebuilding with Xcode 27.1?

Not guaranteed, though it's a strong starting point. If your app already supports resizing on iPad or iPhone Mirroring, you're off to a great start, and standard containers built with Xcode 27.1 adjust automatically for the outer display, folded inner display, and camera occlusions. Nothing guarantees full automatic adaptation without any additional work, so please see Leverage multiple displays and scenes on iPhone Duo and Preparing your app for iPhone Duo to learn more.

We create our window with init(frame:) and UIScreen.main.bounds rather than adopting SceneDelegate — will this cause issues on iPhone Duo?

Yes. Avoid referencing the main screen on any device; it's ambiguous and will be deprecated. Use the environment, trait collection, or scene bounds instead, accessing the screen dynamically from the window scene if needed. Adopting SceneDelegate and scene-based bounds is the recommended fix here. To learn more, see Prepare your app for iPhone Duo.

What would make an app genuinely optimized for iPhone Duo rather than just compatible with it?

There's no fixed checklist, but the theme to remember is deliberate adaptation — purposeful vertical-bar organization, arrangement-view axis choices, reserved-region handling, and intentional use of scene accessories (rather than an app that merely resizes passively). For more info, see Designing for iPhone Duo.

What's the best approach to adapt an existing UIKit app for iPhone Duo?

Adopt Auto Layout to make views resizable, use automatic trait tracking (horizontalSizeClass/verticalSizeClass) instead of userInterfaceIdiom/UIInterfaceOrientation, prefer standard containers (UISplitViewController, UITabBarController, [UIArrangementViewController](https://developer.apple.com/documentation/uikit/uiarrangementviewcontroller)), and use [UIView.ReservedRegion](https://developer.apple.com/documentation/uikit/uiview/reservedregion) to keep content clear of the hinge area and camera Preparing your app for iPhone Duo.

If we update our portrait-only iPhone app to support iPhone Duo, do we effectively get iPad support for free?

The relationship runs the other way: if your app already works on iPad, you're well on your way to supporting iPhone Duo. For more detail, see Preparing your app for iPhone Duo.

(Continued)

Our app reads UIScreen.main.bounds for non-Auto-Layout view sizing — will this cause layout exceptions when iPhone Duo folds/unfolds, and do we need to rewrite it?

Avoid using UIScreen.main.bounds to make decisions about your app’s interface or view geometry. Accessing screen dimensions can cause layout issues as your app resizes across different device configurations and form factors like iPhone Duo. Instead, perform layout calculations based on the scene or containing view’s bounds rather than screen dimensions. To prevent layout exceptions and broken interfaces when fold-and-unfold transitions occur, replace static, frame-based layouts with flexible constraint-based layouts using Auto Layout. Set translatesAutoresizingMaskIntoConstraints to false when managing constraints programmatically for views that require dynamic sizing. While you do not necessarily need to completely rewrite your application from scratch, refactoring hardcoded screen-bounds-dependent calculations to use local bounding boxes, layout margins, and safe area insets is strongly recommended. Adopting these best practices ensures your app will not throw exceptions and will scale seamlessly across inner and outer displays. To learn more, watch Prepare your app for iPhone Duo.

How will apps that don't use native toolbars or top bars work on iPhone Duo?

They won't automatically receive iPhone Duo's vertical-bar adaptation, sidebar opt-in, or overflow-menu behavior, since that's tied to using system-provided navigation containers Preparing your app for iPhone Duo. Such apps need to manually detect and adapt using ReservedRegion and toolbarVerticalEdge/verticalBarEdge APIs.

Do apps automatically take up the full screen when iPhone Duo is open?

Depending on the SDK version they are built with, apps may not automatically take up the full screen on iPhone Duo by default. When building an app with the iOS 27 SDK, the app extends to the left of the status bar area on the inner display. To take advantage of the entire screen space and achieve the full-screen experience, you must build your app with the iOS 27.1 SDK or later. To learn more, watch Prepare your app for iPhone Duo.

Will there be a new Xcode coding-intelligence skill to help developers update apps for iPhone Duo layouts?

Yes. Apple announced an 'App Resizability' Xcode skill during the 'Prepare your app for iPhone Duo' tech talk. With Xcode 27.1, it supports SwiftUI and iPhone Duo Prepare your app for iPhone Duo.

Will there be locations where developers can test their apps on a physical iPhone Duo before release?

iPhone Duo workshops, where you can learn to optimize your app and explore resizability, are being held around the world, but please note device availability is not guaranteed in all locations. To explore workshops, browse the Meet with Apple schedule.

Will Xcode include a new skill to help developers make changes for iPhone Duo?

Yes. the 'App Resizability' Xcode skill, which now supports SwiftUI and iPhone Duo as of Xcode 27.1 Prepare your app for iPhone Duo.

What's an interaction that looks fine in the simulator but feels awkward on a physical iPhone Duo?

Interactions that appear functional in simulation can feel awkward on physical hardware due to reachability, asymmetric safe areas, and physical weight distribution. Always validate button targets, vertical bar positioning, and navigation flows on physical iPhone Duo devices. To learn more, watch iPhone Duo Group Lab.

Does iPhone Mirroring's resizing behavior translate well to iPhone Duo, and is it a good way to test resizability?

Apps prepared to resize in iPhone Mirroring are on a good path toward iPhone Duo support, and Device Hub supports checking resizing in iPad or iPhone Mirroring contexts as a testing aid. iPhone Duo-specific behaviors like vertical bars and reserved regions still need dedicated testing. For more detail, see Prepare your app for iPhone Duo and Layout.

How does the iPhone Mirroring app on Mac handle iPhone Duo's two displays?

The iPhone Mirroring app on Mac handles the dual displays by treating iPhone Duo as a resizable canvas, allowing continuity as the device transitions between the outer and inner screens. To learn more, watch iPhone Duo Group Lab.

What's the best way to preview how my app looks on iPhone Duo before release?

Use Device Hub in Xcode 27.1 to preview your app across iPhone Duo poses Designing for iPhone Duo. In the meantime, Device Hub's Resizable iPhone / iPhone Mirroring resizing behavior is a reasonable approximation. Audit against the resizability checklist: layout per pose, vertical-bar presentation, and fold-blocked elements Preparing your app for iPhone Duo.

What's the one thing you'd want every developer to get right for iPhone Duo?

Build your app to resize using standard system layout containers — size classes, safe area insets, split views, tab bars, arrangement views — instead of fixed dimensions or device-specific checks. That's the first best practice in Designing for iPhone Duo.

(Continued)

How different should iPhone Duo's outer-display landscape UI be from iPad landscape?

Don't design a bespoke layout for every way someone might hold the device, whether that's partially folded like a book, laid flat, or standing on its edge. Instead, rely on size classes: compact width for the outer display, regular width for the inner display. If your layout already respects size classes, margins, and safe area insets, it should adapt across poses with little additional work. Avoid fixed widths or anything hardcoded to a specific display. To learn more, see Designing for iPhone Duo.

What's the recommended way to keep content clear of the hinge without hard-coding iPhone Duo dimensions?

Use the reserved-region APIs: call reservedRegions(kind:options:layoutDirectionBehavior:) on a GeometryProxy in SwiftUI, or reservedRegions(kind:options:) on UIView in UIKit, to get the hinge area and camera occlusion frames and lay out around them Preparing your app for iPhone Duo.

On the vertical tab bar, is text supported, or should tab items be icon-only?

Text is supported, but with rules: the system uses an icon when presenting an item vertically, and if an item has a title without an icon, the system won't present it vertically Preparing your app for iPhone Duo. Provide both a title and a symbol on every item for maximum adaptability Designing for iPhone Duo.

Conceptually, does Apple want us to think of iPhone Duo as one large adaptable canvas, or as two displays that cooperate?

Mostly the former, with room for the latter. An app designed for iPhone Duo adapts seamlessly across both displays for a continuous experience Designing for iPhone Duo. Scene accessories let apps show coordinated, distinct content on each display when that adds real value, like camera-facing content Leverage multiple displays and scenes on iPhone Duo.

Does iPhone Duo have its own UIUserInterfaceIdiom?

No. On iPhone Duo, use size classes instead of userInterfaceIdiom or UIInterfaceOrientation for layout decisions. For more details, see Preparing your app for iPhone Duo.

How should an iPad three-column layout adapt to iPhone Duo?

Use NavigationSplitView (SwiftUI) or UISplitViewController (UIKit) rather than a hand-built column layout — both are fully adaptive, collapsing to single-stack navigation when closed and tiling or overlaying when open Prepare your app for iPhone Duo. These also adapt automatically to the hinge area when built with standard components Designing for iPhone Duo.

What's the recommended way to give the inner display distinct portrait and landscape layouts?

Use size classes, not orientation checks. Observe horizontalSizeClass and verticalSizeClass via automatic trait tracking, since the inner display doesn't honor your declared interface orientations Prepare your app for iPhone Duo.

Does every pose need manual adoption, or is following best practices enough?

Following best practices covers most of it: use size classes so your app adapts naturally, and avoid redesigning for each pose Designing for iPhone Duo. Some refinements, like arrangement-view axis choices, still benefit from manual tuning.

Will a custom bottom tab bar automatically adapt to iPhone Duo, and how will it be displayed?

No — a truly custom bar (not UITabBar/UIToolbar) won't automatically move to the vertical side layout. Migrate to standard components to get that behavior Preparing your app for iPhone Duo. If a custom bar must remain, use toolbarVerticalEdge / verticalBarEdge and ReservedRegion APIs to manually reposition it.

Many camera apps fake auto-rotation by spinning UI elements individually — how should this adapt on iPhone Duo?

Adopt real orientation support rather than a faked rotation trick. The outer display behaves like a normal iPhone for orientation, but the inner display doesn't honor your supported orientations, so size-class-driven layout is more reliable Prepare your app for iPhone Duo. For the camera feed itself, use AVCaptureDeviceDirectionCoordinator to track the forward-facing camera as the device flips or opens Build a great camera experience for iPhone Duo.

(Continued)

How should overlay-panel sheet patterns (like Find My) adapt on iPhone Duo — side by side instead of overlaid?

By default, sheets on the outer display present vertically, and sheets on the inner display are centered. Use presentationPlacement(_:) (SwiftUI) or preferredPlacement (UIKit) to request centered, leading, or trailing placement. To learn more, see Prepare your app for iPhone Duo and Preparing your app for iPhone Duo.

Where do bottom controls above content (like Find My's) go in landscape on the outer display?

Keep such controls with the content area they affect, rather than moving them to the vertical side bar — the same pattern Mail uses for its list controls Designing for iPhone Duo.

For a fully custom (non-UITabBar) tab bar, should we move it to the trailing edge ourselves, and do the outer display's safe-area insets already reserve that space?

Move to standard system bar components instead of hand-positioning a custom bar: set toolbar items on a view controller added to a navigation controller. If a custom bar must remain in your app, use the toolbarVerticalEdge (SwiftUI) or verticalBarEdge (UIKit) trait plus reservedRegions APIs to inspect the camera/Dynamic Island region rather than assuming safe-area insets alone reserve that space. To learn more about vertical bars, see Preparing your app for iPhone Duo.

If an app locks its orientation to portrait, does it still get compact/regular size-class changes as the device folds and unfolds?

Yes. Orientation locking and size-class-driven layout are separate concerns: iPhone Duo respects your supported orientations, but your app still scales via size classes on the inner display, including in Split View Prepare your app for iPhone Duo.

How does the SDK handle asymmetric safe-area insets in Split View near the hinge, and are there layout guides to keep UI out of the crease?

Yes — safe areas are often asymmetric on iPhone Duo, so avoid assuming insets on opposite sides are equal; handle each side independently Prepare your app for iPhone Duo. Use safeAreaInsets (GeometryProxy in SwiftUI, or the UIView property in UIKit), and for precise fold-hugging layout, use the iOS 27.1 ReservedRegion APIs Preparing your app for iPhone Duo.

What signal should drive layout changes between portrait and landscape on the outer display, since size classes stay the same?

Use the toolbarVerticalEdge environment value (SwiftUI) or verticalBarEdge trait (UIKit) — it directly reports whether the system is presenting bars vertically, which is a better signal here than size class or orientation Preparing your app for iPhone Duo.

For an app that already supports iPhone and iPad, should we treat iPhone Duo as just another size-class environment, or are there cases where iPhone Duo-specific layouts are recommended?

Treat iPhone Duo as another point on the adaptive size-class continuum by default Prepare your app for iPhone Duo. Apple does call out specific scenarios warranting iPhone Duo-aware refinement, like arrangement views for primary/secondary layouts or scene accessories for camera content.

How much should developers experiment with new design paradigms on iPhone Duo versus staying consistent with the system?

Most apps should favor consistency over bold experimentation. Don't reinvent your app when it resizes, and in general don't override default bar placement, since keeping controls in familiar positions reinforces the unified platform experience on all supported devices, including iPhone Duo. For guidance, see Designing for iPhone Duo.

Can users freely resize an app on iPhone Duo, like on iPad?

Not with free-form drag-to-resize. Apps resize continuously based on device pose and Split View multitasking instead Designing for iPhone Duo.

Should apps support all orientations by default now, across all devices?

It is best practice to support all interface orientations whenever possible, allowing layouts to resize smoothly across various poses, rotations, and Split View configurations. If your app supports multitasking, the system requires it to support all orientations. Avoid checking interface orientation or user interface idioms for layout decisions. Instead, use size classes to handle sizing constraints and adapt your layout dynamically to the available space across all devices, including iPhone Duo. To learn more, watch Prepare your app for iPhone Duo.

How do Tab Bar Accessory Views behave across iPhone Duo's poses and orientations — do they collapse when scrolling on the inner display in landscape?

UITabAccessory is a content view attachable to a tab bar controller's bottomAccessory, with two layout environments — regular and inline — exposed via UITabAccessory.Environment UITabAccessory.

(Continued)

How does the safe area present across the various iPhone Duo poses?

The following list provides a general example of safe areas across poses on iPhone Duo:

  1. Closed Pose: The outer display places toolbars and tab bars along the trailing edge (or leading depending on language direction), creating an asymmetric safe area inset on that side.
  2. Open Pose (Portrait): The inner display provides enough vertical space to maintain standard horizontal bars, resulting in top and bottom safe area insets.
  3. Open Pose (Landscape) and Split View: Controls move to the side edge, requiring your app to handle leading or trailing safe area insets independently.
  4. Partially Folded Pose: The folding region acts as a reserved region (specifically a division region), and system components automatically adjust their positioning to stay clear of the center fold.

How does tabSidebar (UIKit) or sidebarAdaptable (SwiftUI) behave on iPhone Duo?

When using sidebarAdaptable and SidebarAdaptableTabViewStyle in SwiftUI, or UITabBarController.Mode.tabSidebar in UIKit, the system presents the platform's regular tab bar or an adaptable sidebar depending on the active context, orientation, and pose. In general, iOS displays a bottom tab bar rather than adapting into a sidebar the way iPadOS does. You can opt into a sidebar on the inner display of iPhone Duo by setting the default tab bar placement to sidebar in SwiftUI, or the preferred placement to sidebar in UIKit.

Do we need to consider vertical bars on iPad?

On iPadOS, toolbars, tab bars, and sidebars work together to provide optimal navigation while preserving vertical space for content. Depending on the configuration, such as using sidebarAdaptable or a split view, navigation controls adapt smoothly to window resizing and rotation. For more information, see Sidebars. Similarly, newer form factors like iPhone Duo feature hardware-aligned vertical controls where navigation bars, toolbars, and tab bars can move to the side of the display to maximize vertical reading space. Developers should rely on system-provided navigation containers (such as NavigationStack, NavigationSplitView, or UITabBarController) rather than building custom vertical bars manually. This guarantees automatic adaptation to size classes, safe areas, and vertical bar behaviors.To learn more, see Preparing your app for iPhone Duo.

In multi-selection edit mode (where ToolbarOverflowMenu isn't available), is a custom ellipsis menu in the bottom bar still the recommended pattern for overflow actions?

When implementing a custom overflow menu or handling overflow actions in multi-selection edit mode, the ellipsis is the standard overflow symbol on iPhone, and you should reserve it strictly for that purpose rather than introducing custom symbols from other platforms. If you need to consolidate app-specific overflow actions into a single system-managed menu when ToolbarOverflowMenu (SwiftUI) or additionalOverflowItems (UIKit) isn't directly available, prefer using the system's designated overflow mechanisms or standard layout guidance to maintain a consistent user experience. For more details, watch Raise the bar with iPhone Duo.

Since the vertical tab bar is on the side, does that negatively affect tab bars that use text labels? Any way to prevent that?

Text is supported but constrained — the system uses an icon when presenting an item vertically, and an item with only a title (no icon) won't be presented vertically Preparing your app for iPhone Duo. Provide both an icon and a title on every item so the system can use the icon vertically while keeping the title available in overflow menus Designing for iPhone Duo.

Is there a recommended way to adapt sheet and popover presentations as the available display area changes?

Yes. Use presentationPlacement(_:) (SwiftUI) / preferredPlacement (UIKit) to request centered, leading, or trailing placement on the inner display, and toolbarVerticalBehavior(_:) (SwiftUI) / preferredVerticalBarBehavior (UIKit) to opt a sheet's toolbar out of vertical presentation Preparing your app for iPhone Duo. By default, outer-display sheets present vertically, and inner-display sheets are centered Prepare your app for iPhone Duo.

How does modalPresentationStyle = .overCurrentContext behave on iPhone Duo?

In general, UIModalPresentationStyle.overCurrentContext only applies in regular-width size classes, with adaptivePresentationStyle(for:traitCollection:) handling the compact-width substitution. This same guidance applies to iPhone Duo open flat with a single active app displayed.

What are Apple's recommendations for game development on iPhone Duo, including engine support like Unity/Unreal?

In general, make your game playable in every device pose for iPhone Duo, and prefer changing aspect ratio over letterboxing or pillarboxing. For more info, see Designing for iPhone Duo.

(Continued)

Is there a sanctioned way to lock the inner display to portrait only?

No. The inner display doesn't honor your supported interface orientations — avoid checking orientation for layout decisions and use size classes instead Prepare your app for iPhone Duo.

For information-dense apps, when should the larger inner display show more content versus restructure the information architecture?

As general guidance, maintain your information hierarchy, but show an additional level on the larger inner display when it makes sense for your content. For example, Mail shows list and detail separately when closed, side by side when open. For more info, see Designing for iPhone Duo.

When iPhone is held in an L-shape, should controls sit on the lower part of the screen, and what happens if the user starts typing in the upper part?

On unique device form factors like iPhone Duo, system controls and toolbars typically position themselves along the vertical axis to preserve vertical space for content. When a user begins typing in an upper portion or separate window region, ensure that text views and fields appropriately respond by displaying the correct virtual keyboard type and adapting to safe area insets. Always use layout margins, safe area insets, and dynamic layout containers to ensure that controls and typing surfaces do not obscure critical content across different device poses. For more info, see Designing for iPhone Duo.

What should apps that already use native controls check for when supporting iPhone Duo?

There’s no single checklist, but confirm views resize well in each pose, inspect vertical-bar presentation of navigation bars/toolbars/tab bars, identify awkwardly positioned sheets or popovers, and check for elements caught in the hinge area. For more info, see Preparing your app for iPhone Duo.

Should custom bottom sheets implement fold-avoidance behavior, or is safeAreaInsets enough?

Custom bottom sheets and interactive controls should implement fold-avoidance behavior when the device is partially folded. Relying only on standard safeAreaInsets is insufficient for handling dynamic folding regions and hardware hinges where interactive elements might be clipped or obstructed. On hardware configurations such as folding devices, reserved regions (which include camera housings and the folding region itself) shape available space. While system components automatically adjust to accommodate these regions, custom implementations require explicit handling using layout primitives. To keep custom elements clear of hardware hinges and active camera regions, developers can query reserved regions using ReservedRegion in SwiftUI or UIView.ReservedRegion in UIKit. This ensures that custom bottom sheets and UI elements reposition themselves safely away from occlusions and divisions. To learn more, see Prepare your app for iPhone Duo and Preparing your app for iPhone Duo.

How are bottom sheets with a partial detent ('dented' sheets) presented on iPhone Duo, and what are the best practices?

On iPhone Duo, the outer-display sheets present vertically by default, and inner-display sheets present centered. You can adjust placement with presentationPlacement(_:) / preferredPlacement, and opt a sheet's toolbar out of vertical presentation with toolbarVerticalBehavior(_:) / preferredVerticalBarBehavior. To learn more, see Preparing your app for iPhone Duo.

How is an inspector UI presented on an app running full screen on the inner display — can a sidebar and inspector coexist when iPhone Duo is open?

When an app runs full screen on the inner display of iPhone Duo, both a sidebar and an inspector can coexist, depending on the navigation structure and container view controllers you use. In SwiftUI, building with a NavigationSplitView allows the sidebar and detail columns to operate seamlessly alongside an .inspector(isPresented:content:) modifier applied to the detail view. On the inner display, the system presents bars horizontally for the sidebar or content view, and vertically on the trailing edge for the detail view. However, to avoid visual confusion in complex split views, an inspector inside the detail column does not receive its own separate vertical bar; instead, it coordinates with the existing trailing column layout. To learn more, see Preparing your app for iPhone Duo.

In RTL languages like Arabic, does the entire iPhone Duo interface mirror automatically, including the vertical bar's side, or do some controls stay fixed?

When using right-to-left (RTL) languages such as Arabic or Hebrew on iPhone Duo, system-provided UI frameworks and components support RTL layouts by default. Standard layout flow, navigation bars, toolbars, and tab bars automatically adapt their positions to match the reading direction of the script. On iPhone Duo, controls like toolbars and tab bars move to the side of the display (the vertical axis) to maximize vertical content space. Because these controls align with the hardware structure, they remain on the corresponding side in RTL languages, maintaining a consistent positional relationship rather than arbitrarily flipping to the opposite side of the device frame. For more info, see Right to left.

(Continued)

Is it against best practice to build experiences unique to iPhone Duo that aren't easily replicated on a standard iPhone?

When developing for new form factors like iPhone Duo, building unique experiences that aren't easily replicated on a standard iPhone is not inherently against best practice, provided they adhere to core adaptive design principles. iPhone Duo features dual displays, dynamic poses, and unique layout regions that encourage creative and tailored user experiences. However, Apple emphasizes that apps should maintain continuity and core functionality across all poses and displays. Avoid making fixed assumptions about display sizes or tying core features to a single specific orientation or pose. To learn more, see Designing for iPhone Duo.

For a UIKit/SwiftUI hybrid app using UIHostingController and UIViewRepresentable that wasn't designed for resizing, how should size changes be handled across that boundary on iPhone Duo?

Observe horizontalSizeClass/verticalSizeClass via automatic trait tracking rather than userInterfaceIdiom, and use Auto Layout in UIKit to make views resizable. Apply this consistently on both sides of the UIKit/SwiftUI boundary. For more info, see Preparing your app for iPhone Duo.

Can UI elements reposition dynamically as the hinge angle changes?

Yes, via the continuous hinge angle from onHingeChange (SwiftUI) or UIHingeInteraction (UIKit), which provides live updates beyond the discrete open/closed status Leverage multiple displays and scenes on iPhone Duo.

When using Split View on iPhone Duo, how should we decide what content goes on each side of the hinge?

Keep information hierarchy consistent between the outer and inner displays on iPhone Duo. For example, show a list of items (primary) on the leading side and item details (secondary) on the trailing side when open. Ensure that functionality remains the same across device poses so people can access the same controls regardless of how the device is held. Also, prefer system-provided split view containers instead of custom implementations to handle resizing and fold accommodations automatically. For more info, see Designing for iPhone Duo.

Will portrait-only apps adapt well to all iPhone Duo poses?

Partially. The exact behavior depends on the display. If an app locks its supported orientations to portrait only, it still receives compact and regular size class changes as iPhone Duo folds and unfolds. On the outer display, the system honors supported orientations, but on the inner display, it adapts and provides regular-regular size classes, ignoring orientation restrictions. For more info, see Preparing your app for iPhone Duo.

Our music player has a dense custom control bar that won't fit as standard toolbar items — is a horizontal bottom bar on the outer display acceptable, or are there APIs to place it in the side rail?

A dense custom bar not built from UIToolbar items won't move to the side rail automatically. Use ReservedRegion / UIView.ReservedRegion and toolbarVerticalEdge / verticalBarEdge to detect the side-rail region and reposition your content into it manually, as needed. To learn more, see Preparing your app for iPhone Duo.

How should a custom tab bar that aligns vertically on the right adapt for iPhone Duo, especially regarding safe areas when the device is closed?

Use UITabBarController instead of a custom implementation — it adapts to all poses automatically, laying out vertically when appropriate, with an inner-display sidebar option Prepare your app for iPhone Duo. For safe-area concerns alongside custom UI, use safeAreaInsets and verify against toolbarVerticalEdge/verticalBarEdge Preparing your app for iPhone Duo.

If an app overrides horizontalSizeClass directly, does that block the system's size-class updates as the device folds? Should we remove such an override?

Yes, it would very likely interfere. Use automatic trait tracking to observe horizontalSizeClass and verticalSizeClass as they naturally change, rather than overriding them. To learn more, see Preparing your app for iPhone Duo.

(Continued)

For a non-scrolling, immersive full-width layout like Calculator, is a bottom bar on the outer display acceptable, or does side placement always apply?

When designing for non-scrolling, immersive full-width layouts on iPhone Duo, you can use the full display width as long as interactive elements do not conflict with system controls such as the Dynamic Island or the status bar. A bottom bar would be an alternative choice rather than a requirement in this case. For single-page apps with a bottom-heavy layout like Calculator, consider if a horizontal layout allows the content to fully expand. You can use APIs such as toolbarVerticalBehavior and preferredVerticalBarBehavior to disable the vertical bar behavior when side placement is not appropriate. To learn more, watch Raise the bar with iPhone Duo.

Should we redesign our tab bar if it relies on text labels instead of icons?

Yes, adding icons would support the vertical-bar behavior of iPhone Duo much better. Keep text-based buttons to a minimum — labels with text stay in a horizontal bar, so prefer a symbol wherever one works. To learn more, see Designing for iPhone Duo and Tab bars.

When iPhone Duo is held like a book, what should be prioritized when splitting the view, especially if a sidebar looks odd spanning the whole screen?

There's a general axis rule, not a pose-specific one: a split arrangement divides horizontally when wider than tall, and vertically when taller than wide Designing for iPhone Duo. If a sidebar-based layout looks awkward full-screen, consider UISplitViewController/NavigationSplitView instead, since split views adapt their column width and margins to the inner display's symmetry automatically.

Are Inspectors supported on iPhone Duo — do they present as sheets, or as a right sidebar?

On iPhone Duo, inspectors adapt based on the active size class and device context. When you apply the .inspector(isPresented:content:) modifier, an inspector can present as a trailing column in a horizontally regular size class (such as on the inner display when fully open), but adapt to a sheet in a horizontally compact size class or on the outer display. When used within split view structures like NavigationSplitView (SwiftUI) or UISplitViewController (UIKit), the system configures split views to expand on the inner display and collapse to a single pane on the outer display. In split views, bars for inspectors are presented horizontally, and when the interface is collapsed, the split view controller or SwiftUI container displays the inspector as a sheet over the secondary column.

On iPhone Duo, is it acceptable to expose persistent editing controls using the extra space, while keeping gesture-based editing on smaller iPhones?

On iPhone Duo, you should maintain consistent functionality across device poses, and provide access to the same controls and content regardless of how someone holds or views the device. Also, your app should keep functionality and the state of elements the same between displays to avoid requiring people to relearn where actions live. When needed, make small adjustments rather than dramatic rearrangements when controls overflow or content moves during resizing. For more info, see Designing for iPhone Duo.

Does an app need to support every iPhone Duo pose, and what happens if some poses aren't supported?

Supporting the poses of iPhone Duo doesn't mean designing a custom layout for each one. Use size classes so your app adapts naturally. To learn more, see Designing for iPhone Duo.

How should UI elements handle corner concentricity as the device switches poses?

Use the Concentricity APIs introduced in iOS 26, which are updated to work with iPhone Duo's screen shapes: ConcentricRectangle in SwiftUI, UICornerConfiguration in UIKit.

Should we adopt size classes or ViewThatFits for iPhone Duo support, and drop our iPad-specific checks?

When designing for foldable devices like iPhone Duo, developers should rely on standard adaptive layout principles rather than hardcoding device-specific checks. Utilizing size classes and built-in adaptive components allows apps to scale naturally across poses and displays without maintaining fragmented codebases. ViewThatFits evaluates a provided list of child views in order of preference and selects the first one whose ideal size fits within the proposed space on the constrained axes. This makes it an ideal tool when content needs to adapt dynamically to narrower layouts or smaller window configurations. Size classes express the available horizontal and vertical space rather than relying on device type or interface orientation. Maintaining adaptive layouts via size classes ensures that apps scale seamlessly across iPhones, iPads, and foldable device poses.

How should I manage iPhone Duo layout when using storyboards?

When designing layouts for iPhone Duo in storyboards, rely on Auto Layout and the safe area layout guides to ensure your views automatically adapt to different device poses and screen sizes. Avoid using fixed widths or hardcoded dimensions tied to a specific display. Also, prefer system-provided containers such as UISplitViewController, UINavigationController, and UITabBarController in your storyboard. These containers automatically handle resizing, bar repositioning, and adaptation across the outer and inner displays. To learn more, see Preparing your app for iPhone Duo.

(Continued)

Does iPhone Duo support portrait-upside-down orientation?

On iPhone Duo, the inner display doesn't honor your supported interface orientations. As with device idiom, avoid checking interface orientation for layout decisions. Use size classes instead. To learn more, watch Prepare your app for iPhone Duo.

For multi-column data tables, are there APIs to adapt around the hinge when it appears in the middle of the view when iPhone Duo is folded like a book?

When developing multi-column data tables or interfaces for iPhone Duo, avoid hardcoding dimensions or relying on display-specific metrics. Instead, prefer system-provided layout containers and collection view configurations that handle resizing and adapt automatically to varying form factors and display poses. Use reservedRegions(kind: .division, options:) (SwiftUI) or reservedRegions(kind:options:) (UIKit) to detect the hinge area’s location and width, then reposition columns to avoid the center division. To learn more, see Preparing your app for iPhone Duo.

My app doesn't yet support Split View — how will it appear on iPhone Duo when unfolded, and how do I start adopting Split View?

It will still function, but won't take full advantage of the inner display — it renders at a familiar aspect ratio rather than a fully adapted layout Prepare your app for iPhone Duo. Start with UISplitViewController (UIKit) or NavigationSplitView (SwiftUI) — both are fully adaptive and collapse to single-stack navigation when closed.

When iPhone Duo is partially folded, how should developers place important controls near the hinge area — are there dedicated safe-area or layout guides for that region?

Yes — use the ReservedRegion (SwiftUI) / UIView.ReservedRegion (UIKit) APIs, designed specifically to keep important elements clear of the center when the system doesn't move them automatically Designing for iPhone Duo. They report the hinge dividsion’s frame so your layout can avoid it.

What are the recommended patterns for master-detail/split-view interfaces on iPhone Duo, and are there specific safe-area considerations?

Yes — safe areas are often asymmetric on iPhone Duo, so avoid assuming insets on opposite sides are equal and handle each side independently Prepare your app for iPhone Duo. For the pattern itself, use UISplitViewController/NavigationSplitView, which adapt column width and margins to match the inner display's symmetry automatically Designing for iPhone Duo.

Are standard SwiftUI size classes enough to manage the hinge area, or do we need explicit GeometryReader logic?

Size classes alone aren't enough for division-aware layout. They describe available space broadly but don't encode the hinge’s exact location. Use the ReservedRegion (SwiftUI) / UIView.ReservedRegion (UIKit) APIs via GeometryReader/GeometryProxy to inspect the hinge division's frame and adjust your views. To learn more, see Preparing your app for iPhone Duo.

A text-labeled menu button in our top navigation bar — how should it adapt to iPhone Duo's vertical navigation bar?

On iPhone Duo, text labels stay in a horizontal bar rather than presenting vertically, so a text-labeled button would likely need an icon to remain in the vertical bar, or move into the overflow menu where icon and title both display. Also, to ensure your menu button adapts correctly across different display configurations and contexts, follow these guidelines for your items:

  • Provide both a title and a symbol for each toolbar item.
  • Use symbols for items displayed in the vertical bar representation.
  • Ensure the title is included even when showing a symbol, as the system uses the title in overflow menus and expanded forms.

To learn more, see Designing for iPhone Duo.

Split arrangement views show Music's primary view on one side and Podcasts' on the other in different examples — how should we decide primary/secondary placement?

There's no single fixed rule. The Human Interface Guidelines describes general overlay-arrangement placement—views occupy each side when partially folded, with primary moving atop secondary otherwise—but apps choose their own primary/secondary assignment based on content hierarchy rather than a system-wide convention. For more info, see Designing for iPhone Duo.

What's one thing to consider for aspect ratio on iPhone Duo apps compared to a standard iPhone?

When designing or adapting your app for iPhone Duo, avoid making assumptions about display sizes or fixed aspect ratios. On the inner display, your app will be a familiar size and aspect ratio when the device is open, but it must dynamically resize to fit every pose—whether opened, closed, rotated, or folded. General guidance favors changing aspect ratio over letterboxing/pillarboxing, particularly for games, and adding artwork to any unavoidable padding. For more info, see Designing for iPhone Duo.

Would Apple update the UIKit design kit in Figma or Sketch so designers can adapt apps for iPhone Duo?

Get Figma and Sketch design kits for iPhone Duo from the Apple Design Resources.

A Summary of the iPhone Duo Group Lab
 
 
Q