Will Your Website Work on iPhone Duo? Foldable CSS and Viewport Guide

Quick answer: Your site will work on iPhone Duo if it already handles two different portrait widths: a phone-narrow cover (~390–430 CSS px class, like modern iPhones) and a tablet-wide inner (~800–950 CSS px class when unfolded). If you only tested a single iPhone width and a desktop breakpoint, you will miss the inner canvas.

Foldables do not introduce a new CSS language. They expose an edge case you already care about: the viewport can change while your tab stays open.

What changes on iPhone Duo vs a slab iPhone?

A slab phone gives you one primary portrait width. Safari, Dynamic Type, and the address bar still move the numbers, but the display does not change shape.

The Duo is a book-style foldable with two panels in our database:

Display	Physical	Resolution	Aspect
Cover (folded)	6.3″	1206 × 2622	19.5:9
Inner (open)	7.6″	2670 × 1878	10:7

Physical pixels are not CSS pixels. DPR, Display Zoom, and browser chrome sit in between. We list hardware specs on the device page and in the inner vs outer screen size guide.

For layout work, treat the Duo as two devices that share a cookie jar.

Will my layout break? A honest checklist

You are in good shape if most of these are true:

• Layout uses fluid widths (%, fr, minmax, clamp) instead of fixed px shells.
• Breakpoints use min-width media queries (or container queries) rather than one "mobile" and one "desktop" cut.
• Navigation works when the viewport is wider than iPhone but narrower than a laptop (roughly 700–1000 CSS px).
• Images use max-width: 100% or responsive srcset/sizes.
• You do not rely on hover-only interactions for primary tasks.
• Fixed elements account for safe areas (env(safe-area-inset-*)) on notched cover screens.

You are likely to ship bugs if:

• The "tablet" layout only appears at min-width: 1024px, so the inner Duo panel gets the phone layout on a wide screen.
• A fixed max-width: 390px card grid never expands on the inner display.
• JavaScript reads viewport width once on load and never listens for resize/orientation.
• You assume 100vh fills the visible area while Safari's toolbar animates (see 100dvh vs 100vh).

CSS viewport on cover vs inner (what to plan for)

We do not publish a single verified CSS width for iPhone Duo until it is measured on hardware. Guessing resolution ÷ 3 and calling it done will fool you on foldables.

Use planning bands, then confirm on a real device:

Mode	What to design for	Why
Cover, portrait	~390–430 CSS px wide	Same class as iPhone 17 / 17 Pro (6.3″). Your existing mobile layout should land here.
Inner, portrait	~800–950 CSS px wide	Wide inner panel (10:7). Often between phone and laptop breakpoints.
Inner, landscape	Height-constrained, wide	Toolbars and safe areas bite harder; test landscape on inner, not only cover.

Rough math for orientation only: inner 2670 × 1878 at 3× DPR is on the order of 890 × 626 CSS px if Safari reported the full panel without chrome. Your live window.innerWidth will be lower. That gap is why measurement wins over spreadsheets.

Run the viewport checker on a Duo in both states. Compare with the breakpoint checker and read viewport vs screen width vs DPR before you hard-code widths in analytics.

Foldable-specific browser behavior

resize and visualViewport

When the user unfolds the phone, the active display changes. Safari may fire resize on window and update visualViewport dimensions. Listeners you attached only on first paint will miss the new width.

function logViewport() {
  console.log({
    inner: `${window.innerWidth}×${window.innerHeight}`,
    visual: `${visualViewport.width}×${visualViewport.height}`,
    dpr: window.devicePixelRatio,
  });
}

window.addEventListener('resize', logViewport);
visualViewport.addEventListener('resize', logViewport);
logViewport();

Use this on a real Duo (or any foldable) folded and unfolded. If your layout component caches width in React state without a resize subscription, this is the bug you are looking for.

Media queries still work, but pick better breakpoints

Avoid anchoring everything to 768px because "iPad." The Duo inner panel is often wider than 768 CSS px in portrait but not a desktop.

Prefer bands that match content, for example:

/* Phone-first: cover + small phones */
.site-nav { /* compact nav */ }

@media (min-width: 48rem) {
  /* Large phones, Duo inner portrait, small tablets */
  .site-nav { /* expanded nav or two-row */ }
}

@media (min-width: 64rem) {
  /* Laptop / desktop */
  .page { max-width: 72rem; margin-inline: auto; }
}

Generate starting points with the media query generator, then edit thresholds after you measure Duo widths.

Container queries when the page is wide but the card is narrow

On the inner display, users may run Split View or your own multi-column app chrome may squeeze the article column. @container tracks the card width, not the display width.

.card-grid {
  container-type: inline-size;
}

@container (min-width: 32rem) {
  .card { display: grid; grid-template-columns: 1fr 1fr; }
}

Container queries do not replace foldable testing, but they stop a full-width inner viewport from masking a narrow content column.

Safe area and fixed headers

The cover display is a tall phone. Fixed headers and bottom bars should respect insets:

.site-header {
  padding-top: env(safe-area-inset-top, 0px);
}

.site-footer-cta {
  padding-bottom: env(safe-area-inset-bottom, 0px);
}

Our viewport tool includes safe-area context on supported browsers. Pair with CSS viewport units (vh, dvh, svh) when full-height sections fight the Safari toolbar.

Viewport meta tag and PWA considerations

Keep the standard responsive tag unless you have a deliberate reason not to:

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

Do not lock maximum-scale=1 unless accessibility requirements force you to. Users on cover and inner displays both benefit from pinch zoom.

If you ship a standalone web app (apple-mobile-web-app-capable), test unfold transitions there too. Chromeless UI changes how much vertical space you actually get.

Testing workflow (about 30 minutes)

1. Desktop Safari responsive mode is a smoke test only. It will not emulate fold state changes.
2. On a Duo (or borrow one), open your URL in Safari folded. Note innerWidth from the viewport checker.
3. Unfold without reloading. Scroll, open menus, submit a form. Width should reflow without horizontal scroll.
4. Repeat in landscape on inner.
5. Hit your top three pages, not just the homepage. Category and checkout templates break first.
6. Log widths in your analytics as ranges, not a single "mobile" bucket. Foldables will pollute "mobile" if you only store one number.

Compare hardware specs with iPhone Duo vs Galaxy Z Fold8 if you support Samsung foldables too. The CSS story rhymes; the exact widths do not.

How this fits the wider foldable web platform

Apple is not the first vendor with two viewports. Android foldables already forced the same lesson; see Android CSS viewport sizes and the foldable screen size hub.

Standards-minded work (viewport segments, match-media for fold posture) is still uneven across browsers. Progressive enhancement remains the safe bet: fluid layout, resize listeners, and real-device tests beat waiting for one perfect media feature.

FAQ

Do I need a separate mobile site for iPhone Duo?

No. One responsive site is correct. You need extra breakpoints and resize-aware JS, not a second hostname.

What CSS viewport width does iPhone Duo use?

It depends on cover vs inner and on Safari chrome. Plan for phone-width on the cover and tablet-width on the inner, then measure with the viewport checker on hardware. We do not list a single verified CSS size until it is tested on device.

Which breakpoint should I add for the inner display?

Many teams add a layout step between 40rem and 56rem (640–896px) where a two-column inner width becomes comfortable. Tune the value after you log real Duo widths in Safari.

Will window.matchMedia('(min-width: 768px)') fire when I unfold?

If the inner CSS width crosses 768px, yes. If your inner width stays below that threshold because of scaling or chrome, your tablet rules never run. That is a common Duo bug.

The short answer

Your website can work on iPhone Duo if it tolerates viewport changes and you design for both the 6.3-inch cover and the wide 7.6-inch inner panel. Test unfold without reload, add a mid-width breakpoint band, and measure CSS pixels instead of copying 2670 ÷ 3 from a spec sheet.

Next: check your viewport live, responsive site audit workflow, iPhone Duo display specs, and all foldable screen sizes.