-
Strike a pose with adaptive layouts on iPhone Duo
Learn how to create responsive, flexible layouts that work great on iPhone Duo. Explore displacement design patterns that keep content visible and reachable as people open and close their iPhone Duo. Discover how to use arrangement views in SwiftUI and UIKit to build split and overlay presentations, and find out how to query reserved regions to tailor layouts around the hinge and cameras.
Chapters
- 0:00 - Introduction
- 0:27 - Reserved regions on iPhone Duo
- 1:29 - Designing around the hinge
- 2:26 - Displacement patterns
- 4:00 - Choose where content moves
- 5:12 - Adapt content to its new region
- 6:39 - Query reserved regions
- 7:50 - Division and occlusion regions
- 8:39 - System containers that adapt
- 9:20 - Introducing arrangements
- 11:17 - Build with ArrangementView
- 12:00 - Configure the split arrangement
- 13:21 - Use the overlay arrangement
- 14:39 - Choose between arrangements
- 16:09 - When not to use an arrangement
- 16:34 - Next steps
Resources
Related Videos
Meet with Apple
Tech Talks
-
Search this video…
Hi, my name is Maria, and I'm a Human Interface Designer working on Apple's design system. And I'm Harry, a UI Frameworks Engineer. And today, we'll talk about creating layouts that adapt to the unique characteristics of iPhone Duo. Its expansive screen creates new opportunities for your content and new ways for your app to adapt to its shape.
iPhone Duo includes multiple displays, each with its own size class.
If you're already designing for resizability, this should feel familiar.
New hardware features also play a role in shaping the available space.
These include the hinge and the two cameras across the outer and inner displays.
We call these reserved regions, and Harry will cover them in more detail later.
And treat these just like any other areas your layout already adapts to. such as the window controls on iPadOS.
The outer display camera is always present, with system toolbars and tab bars laying out vertically within the new safe area. For more, check out "Raise the Bar with iPhone Duo." Conveniently, I'll be there too.
On the inner display, your interface may adapt to accommodate the fold, or the new FaceTime camera when it's active. If its viewfinder is central to your experience, keep important content and controls clear of that area. You'll approach the hinge differently in your layout.
When the device is partially folded, like a book, it divides the inner display into multiple usable regions as the display curves through the center.
Hey, Maria, I found this book. Take a look at this photo spread across the two pages. It doesn't look very good, right? Right. As it approaches the spine, parts of the image become harder to see, so it no longer reads as one continuous image. And can the same thing happen to an app? Absolutely. Content and controls that span the fold behave very similarly. So to help your app adapt to these changes, we've developed a set of design patterns and tools to help your app feel right at home on iPhone Duo.
We'll start with talking you through displacement patterns and some of the design principles behind them. Then we'll talk about a new UI pattern we call Arrangements.
Let's get started.
Great design for iPhone Duo hinges on knowing when to adapt. Many interfaces can flow naturally around reserved regions, while others benefit from a more intentional approach through a pattern we call displacement, which adjusts the frame of the existing elements based on the available space, keeping important content visible, reachable, and unobstructed even when the device is partially folded.
A common design starts with an element centered on screen when the device is open. After it folds, that element moves to the region that supports its purpose.
I'm starting small with a single element, but displacement can go much bigger, from a button to an entire container or larger parts of a layout.
Choose the scope that best matches the content. If an element can adapt independently, move it on its own. And when elements work together, move them together to preserve their relationship. And remember to be mindful of excessive movement. Moving an element far away from its source weakens their visual relationship.
For example, when selecting a photo in an album, instead of centering the context menu in the trailing region, both elements move together and align around the fold.
Continuous scrolling content like articles, feeds, documents, and lists don't displace.
These experiences already adapt through scrolling, so moving them between the available regions can interrupt continuity.
When displacing content, let its purpose guide where it moves and where it belongs may change depending on how the device is being used.
When it's partially folded, like a book, elements like alerts move to the trailing side. This keeps them closer to where they'll appear as the device closes and the experience continues on the outer display.
When the device is propped up on a table, the two regions support different kinds of experiences. The top region works well for content that benefits from visibility at a distance.
The same alert can move here to remain easy to find.
The bottom region works well for interactive controls.
Tappable elements like media controls can move here, providing a more stable surface for touch.
And when multiple regions are suitable, prioritize keeping things contextual.
Like on iPhone, when search is focused, it's over the keyboard. When the device is open, the field takes advantage of the extra space it affords. As the device folds, its width and position adapt to remain over the view it's searching.
Once you've chosen where something should move, consider how it adapts to its new surroundings. Position and size are the most common changes, but other visual properties can adapt too.
Action sheets, alerts, menus, and popovers are all lightweight contextual experiences that can appear over a reserved region. So the main goal is to keep them fully visible. The system automatically repositions components around the reserved region.
In a split view app, like Reminders, the system keeps both columns visible by adjusting their width and positioning them into an even 50/50 split.
In this Fitness design, I want to keep every item in the grid interactive as the device folds. I can preserve the outer margins while increasing the spacing around the hinge, keeping each container within its region.
What's common across all of these examples is that we're moving, resizing, or reorganizing what's already there. Keep content, functionality, and layouts available so people can access the full experience regardless of how they're using iPhone Duo.
Now you know how to think about adapting to reserved regions. Harry, are there any new APIs that developers should be aware of? That's a great question, Maria. There's nothing I love more than a new API. And in fact, there are some new APIs I'd like to talk to you about.
In SwiftUI, you query reserved regions using a GeometryProxy from a GeometryReader or onGeometryChange modifier.
Use the new reservedRegion method on the geometry proxy to get the regions available in your view. There are multiple kinds of reserved regions. Here, the fold is backed by a division reserved region because it divides a larger area into multiple smaller areas.
In UIKit, you'll use the reservedRegion method available on UIView. You can query the frame property of a reserved region to incorporate it into your own layout. A region can be active or inactive.
By default, only active ones will be returned, but you can query for inactive ones using the includeInactive query option on the reservedRegion method.
On iPhone Duo, the fold's division region is only active when someone has folded the device. When flat, it's inactive and has a width of zero.
You can use inactive regions to make high-level decisions about your app. For example, in grid-like layouts, you could prefer even numbers of columns when a division region is present regardless of its active state.
There is another kind of reserved region called occlusion regions.
These don't divide areas; instead, they occlude them. Think of them as smaller frames in your view's bounds.
On iPhone Duo, the FaceTime camera is represented by an occlusion region. You query them by passing the occlusion kind to the reservedRegion method.
Just like with the fold's division region, this region is active when the camera is active and inactive when the camera is inactive.
Thanks, Harry. You always seem to have the answer to my question.
I'm really excited about using reserved regions with custom views. But as a systems designer, I have to say, I'm even more excited about leveraging our own components that adapt to the fold.
You're probably familiar with many of them, like NavigationStacks, NavigationSplitViews, and TabViews. These system containers let you use common patterns for how people navigate throughout your app. Then there's views like List and ScrollView, which are containers that hold your content.
Hey, Harry, I have a layout that's kind of like a split view, but I don't really need all the expanding and collapsing behavior that it comes with. Is there anything else I can use? Wow, Maria, another great question. Yes, there is yet another container I can talk to you about.
A layout container sits in between these navigation and content containers. These layout containers arrange two views according to a set of rules. They're called arrangements. Now what do I mean by arrange and rules? To explain, let's open the Podcast app. Here, I've started playing a podcast on my iPad, and I'm looking at the Now Playing view. There's a button in the lower right that will show me its transcript. If I tap that button, the transcript view appears, now splitting the layout in half.
If I show the same view on iPhone Duo, it's pretty similar. after I fold the device. This split layout from iPad lends itself pretty well to iPhone Duo.
But notice what happens if I again toggle the transcript button. It disappears again, but the Now Playing view is not centered like it was on iPad. Instead, it stays constrained to the left region defined by the fold. Like Maria said, this ensures that its controls are easily reachable and unobstructed.
If I rotate iPhone Duo to be taller than it is wide, the now playing and transcript views don't use a split layout at all. Instead, the transcript view is shown with an inline representation.
So to figure out the appropriate layout of the now playing view, I have multiple inputs to consider, like the horizontal and vertical size class of the view, the aspect ratio of the view's width over its height, and whether there are any active division regions.
Based on these inputs, I can determine the outputs of the layout of the Now Playing view, like whether I should show the view at all, And if I do show the view, what's its frame? Together, this function of inputs to outputs is called an arrangement. And in iOS 27.1, you can use system-provided arrangements in your own apps.
Maria made a lot of great points earlier, and I should have been taking notes. By absolute coincidence, I've been working on an audio note app. Let me show you how I can use these new APIs in my app.
Here, I have my NavigationStack. I'll start by adding an ArrangementView inside of the stack. An ArrangementView takes a primary and secondary view. So I'll provide my PlayerView to show information about the currently playing audio note, and my UpNextView to show what notes are going to play after the current note has finished. In UIKit, I'll reach for the UIArrangementViewController to add as the root view controller of my UINavigationController.
Then I'll configure my Player and UpNextView Controllers as the primary and secondary view controllers of my ArrangementViewController.
You configure the preferred arrangement with the arrangementViewStyle modifier. The default style is called split, which I'll manually specify here.
As you can imagine, the split arrangement splits its provided bounds amongst its primary and secondary view.
By default, it splits horizontally when the view is wider than it is tall, like when used here on iPad with a wide aspect ratio, or in a similar aspect ratio on iPhone, or similar aspect ratio on iPhone Duo.
If I rotate the device, the split style will split vertically since the view's now taller than it is wide.
For my now playing view, I only ever want to split it horizontally. So I'll specify the axes in which it should split using the axes method on the split ArrangementStyle. If the split arrangement cannot split among an axis, and it's the primary axis, the arrangement view chooses to only show a single view.
Here, it chooses to show only the PlayerView, since the ArrangementView is taller than it is wide. So its primary axis is vertical, but it can only split horizontally.
In UIKit, I'll reach for the update arrangement method on my UIArrangementViewController, and use the UISplitArrangement type configured with the same horizontal axis configured in SwiftUI.
Here is my player and up next view on iPhone Duo using the split arrangement. I'd like to explore another arrangement for positioning my views. It's called the overlay arrangement. Unlike the split, which prefers to position content side by side, the overlay arrangement prefers to position content above or below each other.
Here I'll update my arrangement view to use the overlay arrangement view style. I want to add a bit of polish before showing this Maria, so I'll switch my player and my UpNext view and add a collapse state.
That came out alright.
Now if I fold the device, the overlay arrangement prefers to position the primary and secondary views side by side. This gives my UpNext view a lot more breathing room, and I'd like to take advantage of that.
When using the overlay arrangement, I can query the overlayArrangementZIndex environment property.
In the UpNext view, it will change as the user folds and unfolds the device. I'll use this to switch between a collapsed and an expanded version of my UpNext view.
In UIKit, I can query the Z index of the primary view by using the state for view placement method on UIArrangementViewController, and then using the Z index property on the returned state. Harry, that is a lot of options, I have to ask. Have you thought about how to choose between them? Of course I have.
First, be sure to follow your existing app patterns. If you're already implementing a split-like layout in parts of your app using components like an HStack or VStack, consider using the split arrangement. If you're already implementing an overlay-like layout in parts of your app using components like a ZStack, consider using the overlay arrangement.
These components naturally translate to the respective arrangements with built-in support for iPhone Duo. If you don't have an existing pattern to lean on, consider an overlay arrangement when there's a clear foreground/background relationship between your views.
For example, here in Accessibility Reader, the controls are in the foreground and the readable content is in the background.
Because you can scroll the readable content above the overlay, it's okay if it's partially obscured at times, so using an overlay arrangement is a great choice.
Consider a split arrangement when there's more of a main-detail relationship between your content. Going back to Podcasts, the transcript view is providing more details about the currently playing podcast. It's important that neither of them are ever obscured, so using a split arrangement is a great choice here.
OK, Maria, let's see if you were paying attention. Which arrangement should I use for my audio note app? Hmm. I'd say we should use a split ArrangementView, since the up next list is providing more detail about the playing state rather than having a background relationship to the player. That's right.
As important as choosing the right arrangement is, consider when an ArrangementView is not the right tool for the job.
For example, ArrangementViews don't provide navigation infrastructure to your app. So avoid putting navigation containers like NavigationSplitViews inside of an ArrangementView. And due to the nature of views like List and ScrollView, avoid putting ArrangementViews inside of these scrollable containers.
iPhone Duo introduces many new configurations for your app. To make sure your app is ready for iPhone Duo, start by auditing your app's centered layouts. Consider whether you can make it a two-column layout, or what displacement pattern makes sense in that use case. If you're using standard system containers and presentations, you'll find you get a lot of behavior for free.
And if you're using a more custom horizontal split or an overlay layout, consider using ArrangementView to handle this layout for you across all of your app's supported devices.
Finally, identify the highest priority manually laid-out controls in your views and consider adopting the ReservedRegions API to implement your own displacement where needed. So what about using the hinge for more than layout? I have a pretty cool interaction idea I want to try to build.
That sounds fun. There is another API that lets you respond to the device's fold state. Check out "Leverage multiple displays and scenes on iPhone Duo" to learn more.
Adaptive layouts help your app feel thoughtfully designed for every pose. Moving, resizing, and adapting only when it makes the experience better. And with all these new possibilities, we can't wait to see what you build.
-
-
6:46 - Query reserved regions in SwiftUI
// SwiftUI GeometryReader { proxy in let regions = proxy.reservedRegions( kind: .division) } -
7:03 - Query reserved regions in UIKit
// UIKit let regions = view.reservedRegions( kind: .division) // Query the frame to incorporate it into your own layout let frames = regions.map(\.frame) -
7:22 - Include inactive regions
// SwiftUI GeometryReader { proxy in let regions = proxy.reservedRegions( kind: .division, options: .includeInactive) let frames = regions.map(\.frame) // ... } -
8:07 - Query occlusion regions
// SwiftUI GeometryReader { proxy in let regions = proxy.reservedRegions( kind: .occlusion) let frames = regions.map(\.frame) // ... } -
11:23 - Add an ArrangementView
// SwiftUI var body: some View { NavigationStack { ArrangementView { PlayerView() } secondary: { UpNextView() } } } -
11:26 - Add a UIArrangementViewController
// UIKit let arrangementVC = UIArrangementViewController() let navController = UINavigationController(rootViewController: arrangementVC) let playerVC = PlayerViewController() arrangementVC.setViewController(playerVC, for: .primary) let upNextVC = UpNextViewController() arrangementVC.setViewController(upNextVC, for: .secondary) -
12:00 - Specify the split arrangement style
// SwiftUI var body: some View { NavigationStack { ArrangementView { PlayerView() } secondary: { UpNextView() } .arrangementViewStyle(.split) } } -
12:41 - Restrict the split to one axis
// SwiftUI var body: some View { NavigationStack { ArrangementView { PlayerView() } secondary: { UpNextView() } .arrangementViewStyle( .split.axes(.horizontal)) } } -
13:07 - Update the arrangement in UIKit
// UIKit let arrangementVC = UIArrangementViewController() // ... arrangementVC.updateArrangement(.split.axes(.horizontal)) -
13:26 - Switch to the overlay arrangement
// SwiftUI var body: some View { NavigationStack { ArrangementView { UpNextView() } secondary: { PlayerView() } .arrangementViewStyle(.overlay) } } -
14:07 - Respond to the overlay Z index
// SwiftUI enum UpNextMinimization { case collapsed; case expanded } struct UpNextView: View { @Environment(\.overlayArrangementZIndex) private var zIndex: Int var body: some View { UpNextList(minimization: minimization) } var minimization: UpNextMinimization { zIndex > 0 ? .collapsed : .expanded } } -
14:21 - Read the Z index in UIKit
// UIKit let arrangementVC = UIArrangementViewController() // ... let primaryState = arrangementVC.state(for: .primary) myModel.minimization = (primaryState?.zIndex ?? 0) > 0 ? .collapsed : .expanded
-
-
- 0:00 - Introduction
Maria, a Human Interface Designer on Apple's design system, and Harry, a UI Frameworks engineer, introduce how to create layouts that adapt to the unique characteristics of iPhone Duo.
- 0:27 - Reserved regions on iPhone Duo
iPhone Duo has multiple displays, each with its own size class, plus hardware features that shape the available space — the hinge and the cameras on the outer and inner displays. These are called reserved regions, and you treat them like any other area your layout adapts to, such as window controls on iPadOS.
- 1:29 - Designing around the hinge
When the device is partially folded like a book, the hinge divides the inner display into multiple usable regions as the display curves through the center. Just as a photo spread across a book's spine stops reading as one continuous image, content and controls that span the fold become harder to see.
- 2:26 - Displacement patterns
Many interfaces flow naturally around reserved regions, while others benefit from displacement — adjusting the frame of existing elements based on available space. Displacement can scope from a single button to an entire container. Move elements independently when they can adapt alone, together when they work as a unit, and avoid excessive movement that weakens visual relationships. Continuously scrolling content like articles and feeds shouldn't displace.
- 4:00 - Choose where content moves
Let purpose guide where content moves, and note that the right destination changes with how the device is used. Partially folded like a book, alerts move to the trailing side, closer to where they'll appear as the device closes. Propped on a table, the top region suits content viewed at a distance while the bottom suits interactive controls. When multiple regions work, keep things contextual.
- 5:12 - Adapt content to its new region
Position and size change most often, but other visual properties adapt too. The system automatically repositions action sheets, alerts, menus, and popovers around reserved regions to keep them fully visible. In a split view like Reminders it keeps both columns visible with an even split, and a grid can preserve outer margins while increasing spacing around the hinge. Throughout, you're moving, resizing, or reorganizing what's already there.
- 6:39 - Query reserved regions
In SwiftUI, query reserved regions with the new reservedRegion method on a GeometryProxy from GeometryReader or the onGeometryChange modifier. In UIKit, use the reservedRegion method on UIView. Query a region's frame to incorporate it into your layout. The fold is backed by a division region, because it divides a larger area into smaller ones.
- 7:50 - Division and occlusion regions
Regions can be active or inactive; only active ones are returned by default, but the includeInactive query option surfaces the rest. The fold's division region is active only when the device is folded, and has zero width when flat — inactive regions still support high-level decisions, like preferring an even number of grid columns. Occlusion regions occlude rather than divide, and represent the FaceTime camera.
- 8:39 - System containers that adapt
Navigation containers like NavigationStack, NavigationSplitView, and TabView provide common navigation patterns, while content containers like List and ScrollView hold your content. Both adapt to the fold for free.
- 9:20 - Introducing arrangements
A layout container sits between navigation and content containers, arranging two views according to a set of rules called an arrangement. Using the Podcasts Now Playing and transcript views as an example, an arrangement is a function of inputs — size classes, the view's aspect ratio, and any active division regions — to outputs, like whether to show a view and what frame it gets. iOS 27.1 makes system-provided arrangements available in your app.
- 11:17 - Build with ArrangementView
An ArrangementView takes a primary and a secondary view — here a player view and an up-next view — and goes inside a NavigationStack. In UIKit, use UIArrangementViewController as the root view controller of your UINavigationController, configuring the primary and secondary view controllers.
- 12:00 - Configure the split arrangement
Set the preferred arrangement with the arrangementViewStyle modifier; the default split style divides its bounds between the primary and secondary views. It splits horizontally when the view is wider than it is tall and vertically when taller. Restrict this with the axes method, and note that when the arrangement can't split along its primary axis it shows only a single view. In UIKit, use the update arrangement method with UISplitArrangement.
- 13:21 - Use the overlay arrangement
Unlike split, the overlay arrangement prefers positioning content above or below, moving to side by side when the device folds. Query the overlayArrangementZIndex environment property to respond as the user folds and unfolds — useful for switching between collapsed and expanded versions of a view. In UIKit, use the state for view placement method on UIArrangementViewController and read the returned state's Z index.
- 14:39 - Choose between arrangements
Follow your app's existing patterns: HStack or VStack layouts translate to the split arrangement, ZStack layouts to overlay. Without an existing pattern, choose overlay when there's a clear foreground/background relationship — as in Accessibility Reader, where partially obscuring scrollable content is acceptable — and split when there's a main/detail relationship, as with the Podcasts transcript where neither view should be obscured.
- 16:09 - When not to use an arrangement
ArrangementViews don't provide navigation infrastructure, so avoid putting navigation containers like NavigationSplitView inside one. Because of how List and ScrollView behave, avoid putting an ArrangementView inside a scrollable container.
- 16:34 - Next steps
Audit your app's centered layouts and consider whether a two-column layout or a displacement pattern fits. Standard system containers and presentations give you a lot of behavior for free. For custom horizontal split or overlay layouts, consider ArrangementView, and adopt the ReservedRegions API for your highest-priority manually laid out controls.