DuoAppsDon’t stretch: the screen-by-screen checklist for iPhone Duo
Closed in landscape, iPhone Duo has a short, wide screen: a portrait view stretched across it becomes unreadable. The DuoApps recommendation, by screen type: a list adds columns, a form stays centered at a maximum width, an article caps the height of its header image, and only a full-screen view fills the whole space.
The problem
Closed and turned to landscape, the outer display of iPhone Duo is short and wide, and both of its size classes, width and height, are compact. A view designed for portrait, left to stretch, becomes unreadable there: lines run too long, images grow oversized, and the content no longer fits the height.
Apple asks you to design for two size classes rather than one layout per pose, not to reinvent the app when it changes size, and to let the existing layout expand (Human Interface Guidelines). Expanding doesn’t mean stretching everything: each screen type grows in its own way, and this checklist goes through each one.
The checklist, screen by screen
Pick your screen type: each block reads in the same order, width first, then four checks (bars, fold, safe area and backgrounds, state). The Bars checks apply to system bars: the system compresses them, and your app sets which one compresses first, screen by screen. Bars your app draws itself have their own pattern.
List and grid
- 1
Width Derive the number of columns from the available width and a maximum cell width, never from the device or the size class alone: one size class covers different widths. As the width grows, the list adds columns; the cell doesn’t get bigger. If the last row isn’t full, its cells keep the same width as the others.
- 2
Bars On a screen people browse (a navigation-focused experience, in Apple’s words), when space runs short, the system moves toolbar items into the overflow menu and keeps the tab bar: that’s the default behavior, nothing to set. In a split view, if the list sits in a column other than the detail column, its controls stay above it; only the detail column has its controls on the side. See Where the bars go, rule 8.
- 3
Fold With the device open, prefer an even number of columns, even when it’s flat, so content divides cleanly at the fold. Partially folded, a grid keeps its outer margins and widens the space around the hinge; a continuous list that scrolls doesn’t need to avoid the fold.
- 4
Safe area and backgrounds What doesn’t scroll never goes under the controls on the side. What scrolls can pass under them, like the photos in a message in Slack, as long as every element can scroll back into the safe area. A cell’s background stops at the edges of the cell: it doesn’t extend to the edges of the screen or under the bars.
- 5
State and continuity Keep the state of elements the same between displays, as the device opens and closes: the selection and the scroll position are never lost.
Form, card, profile
- 1
Width Give the form, card, or profile a maximum width, center the view, and let its height run free. On the outer display, where the width stays compact in both orientations, don’t rearrange the view when the device rotates: it keeps its portrait width, centered in the safe area.
- 2
Bars On a screen where people complete a task (a task-oriented experience, in Apple’s words), the tab bar can compress instead of the toolbar: it shrinks to a single control, and the actions needed to finish the task stay visible. That isn’t the default behavior: the app asks for it on that screen, and the system applies it. A button anchored to one edge of the view, like the Checkout button in a cart, keeps the view’s width, and only its background stretches to the edges of the window; no Apple source supports this second rule.
- 3
Fold Partially folded, keep fields and buttons out of the fold as much as possible: system alerts, menus, and toolbar buttons move aside on their own; move your own elements only as much as needed, and together when they belong together.
- 4
Safe area and backgrounds Apple asks that the keyboard’s accessory bar, which sits above it, stay attached to the keyboard rather than move to the side. Leave no field or button under the controls on the side.
- 5
State and continuity Keep the state of elements the same between displays, as the device opens and closes: what people have typed is never lost.
Article, detail page
- 1
Width Give the header image the full width, but cap its height: closed in landscape, the height is compact. Don’t size anything to the height of the screen, and let the content scroll. Keep the text in a reading column with a maximum width.
- 2
Bars When the controls are on the side, navigation buttons, like Back or Close, take the top; when space runs short, the system moves actions into the overflow menu, starting from the bottom; the app can change that order by giving each action a priority. See Where the bars go, rule 7.
- 3
Fold The article’s text scrolls: it doesn’t need to avoid the fold when the device is partially folded.
- 4
Safe area and backgrounds The header image can extend under the bars; keep the text and links in the safe area.
- 5
State and continuity Keep the state of elements the same between displays, as the device opens and closes: the reading position is never lost.
Carousel
- 1
Width As the width grows, show more items, and always keep one card cut off at the edge.
- 2
Bars A carousel has no bars of its own: it follows those of the screen that holds it, list and grid, article, or block-based home screen.
- 3
Fold The carousel scrolls: it doesn’t need to avoid the fold when the device is partially folded. Anything people tap that doesn’t scroll with it stays out of the fold as much as possible.
- 4
Safe area and backgrounds The carousel can scroll under the controls on the side, like the photos in a message in Slack; at the start and the end of the scroll, rest the first and last elements in the safe area, so each one can come back within reach.
- 5
State and continuity Keep the state of elements the same between displays, as the device opens and closes: the carousel’s position is never lost.
Full screen: map, player, web view, camera
- 1
Width A map, a video player, a web view, or the camera preview fills all the available space, with no maximum width: only a full-screen visual, alone on the screen, stretches like this.
- 2
Bars For a visual, immersive interface that doesn’t scroll, like Calculator, the app can turn off the vertical bar and take the full width, as long as nothing runs into the Dynamic Island or the status bar and nothing interactive is covered by the controls; otherwise, it keeps the default bar placement. See Where the bars go, rule 10.
- 3
Fold When the device is propped up on a table, you can, if you want, provide a dedicated layout: the media at the top, the controls at the bottom; they’re the same controls, in the same hierarchy, as in the other poses. When a Picture in Picture video is pinned to the top of the screen, the app resizes vertically to fit the space that’s left.
- 4
Safe area and backgrounds The full-screen visual runs to the edges; keep its tap targets (buttons, playback controls, links in a web view) in the safe area.
- 5
State and continuity Keep the state of elements the same between displays, as the device opens and closes: playback in progress is never lost. For a front camera (a selfie, a video call), the preview switches to the camera that faces the person when they open or close the device: the Virtual Front Camera switches on its own; if the app picks its cameras itself, switching is up to the app.
Block-based home screen
- 1
Width On a home screen made of stacked blocks, each block follows the width rule for its type: list and grid, form, article, carousel, or full screen.
- 2
Bars When space runs short, the system keeps the tab bar and moves toolbar items into the overflow menu: that’s the default behavior, the one for a screen people browse (a navigation-focused experience, in Apple’s words), nothing to set.
- 3
Fold With the device open, prefer an even number of columns in a grid block. Partially folded, the scrolling home screen doesn’t need to avoid the fold; anything that doesn’t scroll stays out of the fold as much as possible.
- 4
Safe area and backgrounds The screen’s background fills the window and runs under the bars; a block’s background stops at the edges of the content column: it doesn’t run under the bars.
- 5
State and continuity Keep the state of elements the same between displays, as the device opens and closes: the home screen’s scroll position is never lost.
For every screen type
Check every screen in every pose before you ship: closed, open, and partially folded, each in portrait and in landscape; in Split View, next to another app, on one side and then the other; and under a video pinned to the top of the screen.
Prepare your App Store screenshots at two sizes, for the outer display and the inner display; Apple says uploading them to App Store Connect will be available later this year.
This checklist doesn’t cover the build or the code: for that part, see Apple’s developer article, Preparing your app for iPhone Duo.
Demo
Static version, no JavaScript
List and grid
Form, card, profile
Article, detail page
Carousel
Full screen
Block-based home screen
Closed · portrait. Closed, in portrait, the narrowest width: each type keeps its iPhone layout. The list fits in one column; the form and the article’s text take almost the full width (width first).
List and grid
Form, card, profile
Article, detail page
Carousel
Full screen
Block-based home screen
Closed · landscape. Closed, in landscape: wider, but short. The list moves to two columns; the form stays at its maximum width, centered; the article’s header image keeps its capped height, and the text scrolls below it.
List and grid
Form, card, profile
Article, detail page
Carousel
Full screen
Block-based home screen
Open · portrait. Open, in portrait: almost the same width as closed in landscape, but tall. The same rules give the same columns: the available width decides, not the pose.
List and grid
Form, card, profile
Article, detail page
Carousel
Full screen
Block-based home screen
Open · landscape. Open, in landscape: the list moves to three columns and the cell doesn’t get bigger; the article’s header image takes the width without growing taller; only the full-screen view fills everything. Each block on the home screen follows the rule for its type.
List and grid
Form, card, profile
Article, detail page
Carousel
Full screen
Block-based home screen
Split View. Split View: two apps share the open display. Ours, on the left, has only half the width, almost as much as closed in portrait: the list goes back to one column. The available width decides, not the device.
FAQ
How do I adapt a list or a grid to landscape on iPhone Duo?
Add columns based on the available width and a maximum cell width, without making the cells bigger; an incomplete last row keeps cells of the same width. This is a DuoApps recommendation, not an Apple rule (Width check).
Do I need a different layout for each pose of iPhone Duo?
No. Apple asks you to design for two size classes, compact width on the outer display and regular width on the inner display, with no fixed widths or breakpoints (Design for iPhone Duo, 3:50), and to let the existing layout expand (Human Interface Guidelines).
What should I do with the image at the top of an article on iPhone Duo, closed in landscape?
Keep it full width but cap its height, so nothing is sized to the height of the screen (a DuoApps recommendation, Width check). Apple lets it extend under the bars; the text and links stay in the safe area (Safe area check).
Should a form take the full width on iPhone Duo?
No: give it a maximum width, center it, and let its height run free. With the device closed, don’t rearrange it when the device rotates: it keeps its portrait width (a DuoApps recommendation, Width check).
Does this iPhone Duo checklist come from Apple?
Partly. The Apple lines restate what Apple says, with the passage cited; the Recommendation lines are DuoApps rules, with what supports them at Apple, or a note that no passage does.
Sources
- Designing for iPhone Duo, Apple Human Interface Guidelines, September 9, 2026
- Prepare your app for iPhone Duo, Apple Developer, Tech Talk
- Design for iPhone Duo, Apple Developer, Tech Talk
- Raise the bar with iPhone Duo, Apple Developer, Tech Talk
- Preparing your app for iPhone Duo, Apple Developer Documentation
- Strike a pose with adaptive layouts on iPhone Duo, Apple Developer, Tech Talk
- Apple unveils iPhone Duo, Apple Newsroom, September 9, 2026
- Build a great camera experience for iPhone Duo, Apple Developer, Tech Talk
- Leverage multiple displays and scenes on iPhone Duo, Apple Developer, Tech Talk
- Screenshot specifications, App Store Connect Help