Designing Websites and Apps for iPhone Duo: The Practical Guide

Do not design a separate layout for every iPhone Duo pose. Design an interface that can resize. Treat the outer display as compact width and the inner display as regular width. On the web, do not depend on detecting the fold — Safari still does not expose it reliably. Build a genuinely responsive site first; treat fold APIs as progressive enhancement.

For years, “responsive design” on iPhone mostly meant answering one question:

How wide is the screen?

iPhone Duo changes that.

Apple’s first folding iPhone has a 5.4-inch outer display and a 7.6-inch inner folding display. Open it, close it, rotate it, stand it on a desk or partially fold it like a book and the same interface can move through very different shapes in a few seconds.

That does not mean we suddenly need six versions of every screen. Apple’s advice is almost the opposite:

Do not design for every pose. Design for an interface that can resize.

That is the most important rule in this guide. It applies to websites as much as native apps — although the implementation is very different.

Outer vs inner: the hardware, not your breakpoints

The physical numbers are useful for understanding the device. They are a poor foundation for layout.

When a new device arrives, designers naturally reach for those dimensions and start adding Figma breakpoints. I would not.

The device may be partially folded, used in Split View, rotated, or resized by Picture in Picture. If your layout depends on a hardcoded “iPhone Duo breakpoint”, you are already fighting the platform.

The better mental model:

Design for available space, not for the device name.

That is not a Duo-specific lesson. It is responsive design becoming more important.

One device, many shapes

The interesting thing about Duo is not that it has a large screen. We already design for large screens. The interesting part is that the usable geometry can change while somebody is using the interface.

The user can move through:

• closed phone
• fully open display
• partially folded book
• tabletop position
• landscape
• Split View

without leaving the app.

Apple calls these configurations poses. The design implication is subtle. You should not ask “what should my app look like in book mode?” Ask:

Can the interface reorganise itself when the space and safe regions change?

Apple’s Human Interface Guidelines say that supporting Duo’s poses does not mean creating a custom layout for each pose. A compact outer layout and a regular inner layout provide the foundation, with the system handling much of the transition. That is healthier than a collection of device-specific templates.

The inner display is not a stretched iPhone

This is the biggest visual mistake we will see in the first months of Duo apps: take an ordinary iPhone screen, make it twice as wide, and call it done. Everything then floats in the middle of a huge empty canvas.

Apple wants the extra space to reveal more structure. That can mean:

• list plus detail
• navigation plus content
• media plus supporting controls
• two related panels instead of one panel stretched to 100% width

Native NavigationSplitView, UISplitViewController, TabView and UITabBarController already adapt across configurations. A good Duo layout should feel richer when opened, not simply larger.

This distinction matters for websites too. If a 420px card becomes an 1,100px-wide card because your CSS says width: 100%, the site technically responded. The design probably did not.

Think in components, not pages

Component-based layouts have an advantage here. A product page might contain image, title, price, variant selector, description, reviews, and a CTA.

• On a narrow viewport, those components form one column.
• On a larger inner display, the same components can become product media | product information.

Nothing needs to be reinvented. The relationship between components changes.

CSS Grid and container queries are particularly useful because the component can respond to the space it actually receives instead of assuming the width of the entire device.

.product {
  display: grid;
  grid-template-columns: 1fr;
  gap: 2rem;
}

@container (min-width: 48rem) {
  .product {
    grid-template-columns: minmax(0, 1.1fr) minmax(20rem, 0.9fr);
  }
}

That pattern is more future-proof than:

@media (device-width: 1878px) {
  /* iPhone Duo */
}

The second approach solves one screenshot. The first solves a family of layouts.

The fold changes where controls belong

On the outer display, Apple moves many controls that traditionally sit at the top or bottom of an iPhone onto the side of the display. Two reasons: it frees vertical space, and it places controls closer to the thumb.

The system can move toolbars, tab bars and navigation onto the vertical axis. When the inner display opens in landscape, those controls remain on the side, which helps preserve continuity.

If you build with Apple’s standard navigation components, much of this behaviour comes automatically. If you have built a custom navigation system out of positioned rectangles and gesture handlers, you have more work to do.

The more you work with the system, the more Duo support you get for free.

Symbols suddenly matter more

Vertical toolbars create a practical constraint: text-heavy controls do not fit well on a narrow side rail. Apple therefore favours symbol-based controls for items that move vertically. Text-only items can remain horizontal. Custom controls need to be designed with their possible axis in mind.

Apple also recommends keeping a textual title available even for symbol controls, because the system may need it when items move into an overflow menu.

If your toolbar contains Share, Favourite, Download and Save, ask whether each control has a clear, recognisable symbol. Not because icons are inherently better — because the same control may need to survive in more than one layout axis.

Do not put important controls on the fold

A folding OLED is continuous visually, but it is not an ordinary flat interaction surface when partially folded. Apple calls the centre area the folding region.

Interactive elements can be displaced away from it: a button on the curve may be awkward to tap. Apple does not treat every type of content the same way:

• Buttons, menus, alerts and other interactive UI may move.
• Continuously scrolling content — an article, feed, document or list — usually does not.

Moving a paragraph sideways as the user folds the phone would destroy visual continuity. Letting the text continue through the region is often less disruptive.

Protect interaction before decoration. A paragraph crossing the fold might be acceptable. Your checkout button crossing it probably is not. That is the same conversion-UX instinct we already apply to sticky CTAs and overlays.

Tabletop mode creates a new interaction zone

Partially fold the Duo horizontally and place it on a desk. You now have an upper surface and a lower surface. Apple’s guidance: use the upper area for content that benefits from visibility, and the lower half for controls that benefit from physical reach.

Examples:

• video above, playback controls below
• camera preview above, shutter controls below
• presentation above, navigation controls below
• a recipe app: instructions above, timers and steps below
• a conferencing app: the meeting above, mute and reactions below
• a music app: the lower half as a physical-feeling control deck

This is not a lazy 50/50 split. The two areas have different ergonomic roles. Apple’s warning:

Do not remove functionality just because the pose changed. A specialised pose can rearrange the experience, but the overall hierarchy and capabilities should remain consistent.

Safe areas are no longer symmetrical

We are used to code like padding-inline: env(safe-area-inset-left) — or native layouts that assume left and right insets are roughly equal. On Duo, safe areas can be asymmetric. System controls, cameras and Split View can change each side independently.

For web, prefer:

.page {
  padding-left: max(20px, env(safe-area-inset-left));
  padding-right: max(20px, env(safe-area-inset-right));
}

not:

.page {
  padding-inline: max(20px, env(safe-area-inset-left));
}

The second version silently assumes the left inset is also correct for the right side. On a normal iPhone you may never notice. On Duo, you might.

Apps vs websites: the fold is the split

Apple’s native frameworks know about the folding region. iOS 27.1 introduces reserved-region APIs for SwiftUI and UIKit so custom interfaces can keep areas unobstructed. Apple also provides adaptive arrangements that reorganise two views according to size, aspect ratio and active division regions.

For websites, the situation is different. The web already has proposed standards for foldables:

• the Viewport Segments API, exposing separate logical areas
• the Device Posture API, e.g. @media (device-posture: folded)

Conceptually, CSS can do this:

@media (horizontal-viewport-segments: 2) {
  .layout {
    grid-template-columns:
      env(viewport-segment-width 0 0)
      env(viewport-segment-width 1 0);
  }
}

The problem is browser support. As of September 2026, MDN still labels Device Posture as experimental and not Baseline. Apple’s WebKit standards-position request for Viewport Segments also remains open.

Do not currently build an iPhone Duo website that depends on detecting the fold. Build a responsive site that works without knowing whether a fold exists. Then treat fold APIs as progressive enhancement when Safari eventually supports them. That is the safest architecture today.

Your website still needs to survive the transition

Not being able to detect the hinge does not mean websites are stuck. Safari still resizes. CSS still reflows. Grid, Flexbox, container queries and safe-area variables still work. The browser can move between narrow and wide layouts even if it cannot tell your CSS that the user folded the screen to 73 degrees.

A well-built responsive site is already surprisingly close to being Duo-ready. A badly built “responsive” site is not. Typical problems:

• fixed widths
• viewport assumptions
• full-screen modals
• sticky elements
• oversized cookie banners
• JavaScript that measures the screen only once

Do not cache the viewport size

This old pattern becomes particularly risky:

const width = window.innerWidth;

if (width > 768) {
  enableDesktopLayout();
}

The value might be correct when the page loads. Then the user opens the Duo, rotates it, or changes Split View. Your layout logic is now working from stale information.

Prefer CSS wherever possible. If JavaScript really needs the available size, observe it:

const observer = new ResizeObserver((entries) => {
  const width = entries[0].contentRect.width;
  updateInterface(width);
});

observer.observe(document.documentElement);

This is good foldable practice, but really it is just good responsive engineering. Duo makes bad assumptions easier to expose.

Stop using 100vh blindly

Instead of min-height: 100vh, prefer dynamic viewport units where appropriate:

.hero {
  min-height: 100dvh;
}

Browser chrome, orientation and changing display geometry all affect usable height. Again, this is not uniquely a Duo issue. Duo simply creates more opportunities for the viewport to change while the user stays on the same page.

Modals deserve special attention

Large centred dialogs are already problematic on small phones. A foldable gives them more ways to fail. A modal can:

• cross the folding region
• hide an important button near an edge
• become unnecessarily wide
• sit awkwardly between the two halves
• cover almost the entire compact display

Native sheets, alerts, menus and popovers handle much of the fold behaviour for you. Web teams need to test custom overlays manually.

On the outer Duo display, a large cookie-consent panel can occupy a substantial percentage of the available screen and compete with the page CTA. Nothing is “broken” — but on a shorter, unusually proportioned outer display, the cost of a large bottom overlay becomes obvious. That is exactly the sort of detail this device will expose. The same applies to chat launchers, sticky diagnosis banners, and conversion overlays.

The outer display is not a normal small iPhone

It would also be a mistake to think outer display = old iPhone mini. The Duo outer screen has its own proportions, camera position and control behaviour. Apple moved system controls vertically specifically to preserve useful content height. The outer camera sits in the corner and aligns with that side control region.

From a web perspective, this reinforces an old lesson:

• do not place important content because “nothing normally appears in this corner”
• respect safe areas
• do not position essential CTAs with fixed offsets from a physical screen edge

Split View means your inner display may still be narrow

Do not equate “Duo open” with “tablet layout”. The user can place two apps side by side. Apple’s system adjusts the layouts and, in some cases, uses a 50/50 split around the folding region. Your app can be running on the large inner display while receiving considerably less horizontal space than you expected. Picture in Picture can reduce the usable area again.

The correct question is never is the device open? It is:

How much useful space do I have right now?

That principle applies almost perfectly to web container queries too.

Test the transitions, not just the screenshots

Teams will initially get Duo testing wrong. They will screenshot outer, inner, portrait, landscape — and tick four boxes. The transition is part of the experience. Test what happens when someone:

• opens the device while a form is half completed
• rotates during video playback
• changes Split View while a menu is open
• partially folds while a sheet is visible
• opens the device with the keyboard displayed
• moves from a single-column list into a master-detail layout

The question is not only whether the final layout looks correct.

Did anything jump, disappear, reset, become untappable or lose context during the transition?

Apple is adding an iPhone Duo simulator through Xcode 27.1 and DeviceHub so developers can open, close, rotate and fold the simulated device. For websites, visual proportion testers are useful for checking the official 5.4-inch and 7.6-inch displays — treat them as a visual simulator, not a substitute for Safari on real hardware.

A practical Duo checklist

Before calling an app or website Duo-ready, check:

1. Resize continuously. Drag through widths rather than checking only named breakpoints.
2. Outer display first. Confirm primary actions remain obvious in compact width.
3. Use the inner display. Do not simply stretch a phone layout.
4. Check asymmetric safe areas. Never assume left and right are equal.
5. Protect interactive elements from the centre. Especially custom controls.
6. Keep scrolling content stable. Do not overreact to the fold by moving everything.
7. Test overlays. Cookie banners, chats, drawers, modals, tooltips and sticky CTAs.
8. Avoid device sniffing. Respond to available space and supported features.
9. Do not cache viewport dimensions. Layout can change while the page remains open.
10. Use standard native components where possible. Apple gives them adaptive behaviour for free.
11. Plan vertical controls. Icons, labels and overflow priority now matter more.
12. Test Split View. Open does not automatically mean you own the whole inner screen.
13. Test keyboard states. Forms are often where responsive assumptions break.
14. Test the transition itself. Preserve state and hierarchy while resizing.
15. For websites, progressively enhance fold-specific APIs. Do not require them until Safari support is confirmed.

The bigger lesson is not really about iPhone Duo

Duo forces designers to confront assumptions that were already fragile: fixed screen sizes; desktop and mobile as two separate worlds; breakpoints tied to particular devices; controls positioned against physical edges; JavaScript that assumes the viewport never changes; interfaces that resize but do not actually adapt.

Apple’s advice is essentially a more demanding version of modern responsive design:

Build one coherent experience and allow it to reorganise itself according to the space available.

For native apps, Apple is doing a lot of the difficult work through safe areas, adaptive system containers, vertical navigation, reserved regions and arrangements.

For websites, developers currently have less information about the physical fold, so the best strategy is more conservative:

responsive first, feature detection second, device detection never.

Teams that already build genuinely responsive products may need surprisingly few changes. Teams that designed around a collection of fixed screenshots may have much more work ahead of them.

Our view

I do not think iPhone Duo means designers suddenly need a new discipline called “foldable design”. That risks turning another responsive surface into a collection of device-specific hacks.

The more interesting interpretation is that the viewport is becoming fluid in another dimension. We already learned that width can change. Then height became dynamic. Then browser chrome changed. Then multitasking and floating windows became normal. Now the physical display itself can change shape while the interface is running.

The right response is not more breakpoints. It is better layout systems. And that is probably the most useful design lesson iPhone Duo gives us.

If you are shipping conversion-critical UI on iOS or the web and want a second pair of eyes on the layout system — not a pile of Duo-specific mockups — that is the kind of frontend work we do at Lazige.

Sources and tools

• Apple Human Interface Guidelines: Designing for iPhone Duo — layout, pose, safe-area and fold behaviour.
• Apple iPhone Duo developer hub — Tech Talks, simulator guidance and Xcode 27.1 resources.
• Blake Crosley: Designing for iPhone Duo — vertical bars, displacement, arrangements and reserved regions.
• Reddit r/UI_Design discussion — concise takeaway: do not create separate layouts for every fold position.
• MDN: Device Posture API — still experimental / not Baseline as of September 2026.
• WebKit: Viewport Segments standards-position — the open web-platform gap versus native reserved regions.
• iPhone Duo Screen Tester — quick visual preview of Apple’s official outer and inner proportions; not a substitute for Safari on hardware.