Websites on iPhone Duo: Safari can't see the fold

Your website already works on iPhone Duo. It is a browser on a larger screen; responsive CSS does what responsive CSS does.

What it cannot do is know the screen folds. And that gap is not an oversight in your code — it is a gap in WebKit. The checklist below is what you can do about both, and each item links to the detail.

Website iPhone Duo checklist

1. Add viewport-fit=cover if you draw to the edge; safe-area values stay at zero without it.
2. Split every safe-area shorthand into separate left and right values; the two differ on iPhone Duo.
3. Replace user-agent layout branching with media and container queries; iPhone Duo reports as an iPhone.
4. Swap 100vh for 100dvh, which tracks a viewport that changes mid-session.
5. Replace a cached window.innerWidth with ResizeObserver.
6. Keep critical controls out of the centre of wide viewports, where the fold runs.
7. Test in Split View by dragging the divider through its full range.
8. Do not wait for fold detection in Safari. WebKit has taken no position on the Viewport Segments API; treat segments as an enhancement.

Steps 1 and 2 take an afternoon and account for nearly all of the visible difference.

The web platform solved this. Safari did not adopt it.

Foldables are not new to the web. The Viewport Segments API exists precisely for this: it exposes each logically separate region of the viewport, so a layout can avoid the hinge.

/* Two segments side by side — the device is folded, hinge running vertically */
@media (horizontal-viewport-segments: 2) {
  .layout {
    grid-template-columns:
      env(viewport-segment-width 0 0)
      env(viewport-segment-width 1 0);
  }
}

There is a companion Device Posture API for the fold state itself:

@media (device-posture: folded) { /* … */ }

navigator.devicePosture.addEventListener('change', () => {
  console.log(navigator.devicePosture.type); // "folded" | "continuous"
});

Both shipped in Chrome 138. Neither works in Safari.

The part worth knowing

Intel filed WebKit standards positions for both APIs in March 2024. As of this writing:

• Viewport Segments — open, no position
• Device Posture API — open, no position

The only comment on the Viewport Segments issue is the proposer asking “Any update on the position?” in April 2025. It has not been answered.

So Apple shipped a folding iPhone while the two web standards for detecting a fold sit unanswered in WebKit’s own queue. Plan for the fold being invisible to your CSS on this device, and check again after the next Safari release rather than assuming it arrived.

What Safari does give you

The useful parts of the platform still work, and they cover more than people expect.

The viewport resizes properly. Unfolding changes the viewport; so does Split View, and that one is user-driven at an arbitrary moment. CSS reflows on its own. JavaScript that measured once does not:

// Stale the moment the device unfolds or Split View is resized
const width = window.innerWidth;

// Tracks it
new ResizeObserver(([entry]) => layout(entry.contentRect.width))
  .observe(document.body);

Safe area insets work, and they are asymmetric. This is the one real break, and it is the same trap native apps hit:

/* Wrong on iPhone Duo — one value applied to both edges */
padding: 0 env(safe-area-inset-left);

/* Right */
padding-left: env(safe-area-inset-left);
padding-right: env(safe-area-inset-right);

That shorthand was harmless for a decade because the two values were always equal. They are not equal here. Grep your stylesheets for safe-area-inset — it is the highest-yield search you can run.

It also needs opting in:

<meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover" />

Dynamic viewport units behave. 100vh was always awkward on mobile; on a device whose viewport changes mid-session without a navigation it is worse. 100dvh tracks it correctly.

Container queries are the right tool. In Split View your element’s width has little to do with the device’s. Query the container, not the window:

@container (min-width: 480px) {
  .card { flex-direction: row; }
}

The trap: user-agent sniffing

iPhone Duo reports as an iPhone. Any code branching on a phone user agent will serve your phone layout to a 626-point-wide, regular-width display with room for a sidebar:

// Serves the wrong layout on the largest iPhone ever made
const isMobile = /iPhone/.test(navigator.userAgent);

The inner display is close to a small tablet in usable width. Your existing tablet breakpoint is probably the right layout, and it will never fire if a UA check gates it.

What to do about the fold, given you cannot detect it

You have three honest options.

Ignore it. For most sites this is correct. The fold is a soft crease, not a bezel; text and images crossing it are readable. A one-column article does not need fold awareness.

Avoid the centre band by construction. You cannot know exactly where the fold is, but you know roughly — it runs down the middle of the unfolded display. Keep a primary call to action or a critical control out of the centre of wide viewports. Costs nothing, needs no API.

Feature-detect and enhance. If you serve significant Android foldable traffic, the API is there for those users, and the same code degrades to nothing on Safari:

if ('segments' in (window.visualViewport ?? {})) {
  // Chrome on a foldable: lay out around real segment boundaries
} else {
  // Safari, and every non-foldable: single continuous viewport
}

Write the fallback first and treat segments as the enhancement. That is the correct shape regardless of what WebKit decides later.

This is a browser gap rather than a device gap: the same CSS is fold-aware on every Android foldable and fold-blind on Apple’s. The wider picture, including where each device’s screen actually sits, is in designing apps for the foldable era.

Where this differs from a hybrid app

If you ship a Capacitor, Cordova or Ionic app rather than a website, most of the above applies, but you also have a native layer available — and a plugin can reach the reserved-region APIs that Safari does not expose. That is covered separately in Capacitor, Cordova and web views on iPhone Duo.