How web apps adapt to Safari on iPhone Duo

As of October 28, 2026, Apple has not published any web adaptation guide for iPhone Duo. The only official technical note is WebKit’s blog post WebKit Features for Safari 27.1 from October 23.

Its conclusion fits in one sentence: there is no news. Safari on iPhone Duo runs the same WebKit engine and the same web technologies as every other iPhone. Sites and web apps work as they do everywhere else, and they do not need a separate version.

“Works as everywhere else” does not mean “nothing to do”, though. Below, in implementation order: the viewport range, the basics of adapting a foldable web layout, the one behaviour Safari takes over, the two questions that are easiest to confuse — how web detects fold posture and how web detects a foldable device — and a checklist for adapting a page to iPhone Duo.

1. Start with the viewport: 382 to 951

WebKit published a viewport table for Safari 27.1 across poses (CSS pixels):

Pose	Width	SVH	LVH
Outer display, portrait	382	580	618
Outer display, landscape	594	368	406
Inner display, portrait (one tab)	669	867	902
Inner display, landscape (one tab)	951	585	620
Inner display, two windows side by side (each)	385	571	609

Three takeaways:

• Width spans 382–951, height spans 368–902. That range overlaps other iPhones, so width alone cannot identify the model.
• The inner display puts the tab bar at the top, like iPad or Mac; the outer display keeps it at the bottom, like other iPhones. The tab bar shrinks as the user scrolls.
• Landscape on the inner display can show two windows side by side, and each one gets a narrow portrait viewport (385 wide).

None of these numbers belong in your code. Media queries plus fluid Grid / Flex layouts that cover the whole 382–951 range are enough.

2. Foldable web layout on iPhone Duo: responsive first, no device sniffing

WebKit is direct: do not detect devices with UA sniffing, use feature detection instead. The reason is not only that user agents are unreliable — a posture change never shows up in the UA, and Duo’s viewport overlaps that of regular iPhones.

The first layer of adapting a page to the fold is ordinary responsive design:

.grid {
  display: grid;
  gap: 16px;
  grid-template-columns: repeat(auto-fit, minmax(min(100%, 320px), 1fr));
}

Two details that are easy to miss:

• Do not use 100vh for height. The SVH / LVH columns in the table already show that browser toolbars resize; prefer svh, lvh and dvh.
• Set breakpoints by content width, not by device. Generic 320 / 480 / 720 breakpoints hold up better than “Duo inner display is 669”, and they survive the next hardware revision.

3. Safari foldable adaptation: the only thing the system takes over is PDF

Safari 27.1 changes exactly one thing for users: when the phone is partially folded like a book and the page is a PDF, Safari shows two pages side by side; flatten it or close it and the PDF returns to a single page.

That is browser behaviour. Sites need to do nothing, and no CSS controls it. So the work is not in PDF but in two other places: keeping the layout intact when the viewport changes, and keeping content clear of controls that have moved.

Beyond that, Safari adds no “automatic columns” or “automatic reflow” for foldables. If you want content split across both sides while partially folded, you write it yourself with the two APIs below.

4. How web detects fold posture: the Device Posture API

On iPhone Duo, Safari 27.1 offers the Device Posture API and the Viewport Segments API as a developer preview, off by default. To enable them: Settings > Apps > Safari > Advanced > Feature Flags, then turn on both “Device Posture API” and “Viewport Segments API”.

The Device Posture API has two values:

• folded: the device is partially folded, in a book or laptop pose;
• continuous: the screen is flat, which covers both fully open and fully closed.

In CSS:

@media (device-posture: folded) {
  .layout {
    display: grid;
    grid-template-columns: 1fr 1fr;
  }
}

In JavaScript, read navigator.devicePosture.type and listen for change:

function reportPosture() {
  console.log(`Device posture: ${navigator.devicePosture.type}`);
}

reportPosture();
navigator.devicePosture.addEventListener("change", reportPosture);

One boundary to remember: continuous merges “fully open” and “fully closed” into a single value. So the API can answer “is the device partially folded right now”, but not “am I on the inner or the outer display”.

5. How web tells whether a device is foldable: there is no reliable answer, and you should not try

This is the easiest part to get wrong. The Device Posture API describes the current posture, not the device identity:

• On a regular iPhone, navigator.devicePosture may not exist at all;
• When a foldable is fully flat, type is continuous too, indistinguishable from a regular iPhone;
• The UA string does not help either, and WebKit explicitly recommends against UA sniffing.

Strictly speaking, there is no official way for web to tell whether a device is foldable. What you can do is capability detection, not device detection:

const hasPosture = "devicePosture" in navigator;
const segments = window.viewport?.segments ?? [];

Even if window.viewport.segments returns two segments, that only means the current display is split by a fold. It does not identify the hardware: landscape on the inner display with two windows also produces two viewports.

The right approach is to drop “detect the device” and use “detect the available space” instead: two columns when there is room, one when there is not, and align to the fold when it is partially folded and the API is available. Then no future form factor requires a rewrite.

6. Viewport Segments: the API that actually avoids the fold

The Viewport Segments API describes the segments on either side of the fold. With the feature flags on, Safari 27.1 supports two media queries:

• horizontal-viewport-segments: 2: two segments side by side, book pose;
• vertical-viewport-segments: 2: two segments stacked, laptop pose.

To size content to the exact edges of each segment, the API adds six environment variables: viewport-segment-width, viewport-segment-height, viewport-segment-top, viewport-segment-right, viewport-segment-bottom and viewport-segment-left. Each takes two indexes: column, then row, starting at 0 0 in the top left. Side by side, the left is 0 0 and the right is 1 0; stacked, the top is 0 0 and the bottom is 0 1.

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

On the JavaScript side, window.viewport.segments gives you an array of DOMRect objects. Re-read it when the posture changes or the window resizes:

function reportSegments() {
  window.viewport.segments.forEach((segment, i) => {
    console.log(`Segment ${i}: ${segment.width}px × ${segment.height}px`);
  });
}

reportSegments();
navigator.devicePosture.addEventListener("change", reportSegments);
window.addEventListener("resize", reportSegments);

A caveat: both APIs sit behind feature flags and are off for real users by default. Treat them as enhancements, never as the only layout strategy — with the flags off, the page must still be complete and readable, which means the responsive layout from section 2.

7. Side controls on the outer display: background colour is all you get for now

The outer display is wider and shorter than other iPhones, so iOS moves controls to the side to leave vertical space for content.

In Safari 27.1, web content does not currently extend behind those controls. Safari reads the page background colour and fills the surrounding space with it. WebKit says it is looking at opening that area up, mentions viewport-fit=cover as a direction, but admits that many sites fail to inset all four edges correctly, so it is still looking for a more foolproof solution. No conclusion yet.

Until an official mechanism ships, there are three small things to do:

• Give body a background colour that matches the top of the page, so the side area does not become a mismatched block;
• Use env(safe-area-inset-*) on fixed elements instead of pinning them to the screen edge;
• Watch sticky top navigation: the inner display has its tab bar at the top, so a sticky header should not compete for the same space.

8. Checklist for adapting a page to iPhone Duo

1. Media queries cover 382–951px; breakpoints follow content width, not device models;
2. Heights use svh / lvh / dvh, never 100vh;
3. @media (device-posture: folded) enhances the layout when partially folded, and the single-column layout remains when unsupported;
4. When content must hug the fold, align both sides with Viewport Segments env();
5. Every fold-related style sits behind feature detection, so the page is complete with flags off;
6. Test every pose in the Device Hub simulator from Xcode 27.1 or later — no physical device needed.

9. Testing without a device

WebKit is explicit: you do not need iPhone Duo in hand. Download Xcode 27.1 or later and create an iPhone Duo simulator in Device Hub. Enable the feature flags in Safari inside the simulator and you can verify posture and segments.

Poses worth walking through: outer portrait, outer landscape, inner portrait, inner landscape, two windows side by side, book fold, laptop fold. Check three things: whether content is covered by the fold or the controls, whether state survives open and close, and whether a two-column layout survives the 385px-wide window.

10. References

• WebKit Features for Safari 27.1 (WebKit blog, October 23, 2026)
• Device Posture API (MDN)
• Viewport Segments API (MDN)
• Alternatives to UA sniffing (MDN)

Apple has not published a web adaptation guide; this article is based on the WebKit blog of October 23, 2026, and will defer to official documentation once it exists. If your site hits a problem not covered here, tell us through the feedback form in the footer.