Apple announced the iPhone Duo, its first foldable, on September 10th. Most of the coverage is about the hinge and the $1,999 price tag. I want to talk about something narrower: what the two displays actually measure, and what that does to CSS you have already written. Short version: Folded and unfolded, both displays sit at roughly 1 : 1.42. Not 9 : 19.5. Not close to it. Logical resolution works out to about 466 x 678pt folded and 890 x 626pt unfolded. The web standard for foldables, CSS Viewport Segments, is Chrome and Edge only. Safari does not support it. So the first foldable device that runs Safari ships without the API designed to detect folds. That is the interesting part. The numbers Straight from Apple's spec sheet: Inner (unfolded) Outer (folded) Size 7.6" (7.58" actual) 5.4" (5.36" actual) Resolution 1,878 x 2,670 px 1,398 x 2,034 px Density 430 ppi 460 ppi Body 164.6 x 117.8 mm 84.1 x 117.8 mm Run the ratios. The outer display is 1,398 : 2,034, which is about 1 : 1.45. The inner display becomes landscape when you open it, so 2,670 : 1,878, about 1.42 : 1. Apple matched the aspect ratio across both displays. Folded, it is passport-shaped. Unfolded, it is the same shape rotated and roughly doubled. Here is the part that surprised me. I assumed the folded state would be a normal narrow phone screen that existing mobile CSS would absorb, and that only the unfolded state needed thought. It is not. At 1 : 1.45, the folded state is already outside what your mobile breakpoints assume. A typical iPhone is around 1 : 2.16. This is a different shape in both states. Converting to CSS pixels Apple does not publish logical resolution, so divide the advertised resolution by 3: State Logical resolution (approx.) Outer, portrait about 466 x 678pt Inner, landscape about 890 x 626pt Treat these as estimates. Safari's actual viewport will be smaller once the address bar and toolbar are subtracted, and the only way to know for sure is to read window.innerWidth and innerHeight on a real device. Still, the estimates are enough to see three problems. 466pt is an awkward width. Typical iPhones in portrait land between 390 and 440pt. The Duo folded is wider than all of them, but only 678pt tall. If you gate your mobile layout on something like max-width: 480px, the folded state lands right on the edge of that rule. 890pt landscape will match your tablet styles. But only 626pt of height comes with it. Tall hero sections and full-screen modals that assume a tablet's vertical room will feel cramped. The viewport changes mid-session. Not through rotation, through folding. Any code that measures the viewport once on first paint and holds onto that value will be wrong the moment the user opens the device. And anything that lands under the hinge, a button or a form field, becomes awkward to touch. The standard exists. Safari doesn't implement it. There is a spec for exactly this problem: CSS Viewport Segments. When the viewport is physically split, you get the segment count and each segment's geometry from both CSS and JavaScript. .layout { display: flex; flex-direction: column; } /* two segments side by side = opened like a book */ @media (horizontal-viewport-segments: 2) { .layout { flex-direction: row; } .list { width: env(viewport-segment-width 0 0); } /* reserve the hinge itself so nothing straddles it */ .hinge { width: calc(env(viewport-segment-left 1 0) - env(viewport-segment-right 0 0)); } .detail { width: env(viewport-segment-width 1 0); } } const segments = window.viewport?.segments ?? []; segments.forEach((segment, index) => { console.log(`segment ${index}: ${segment.width}px x ${segment.height}px`); }); On a non-folding device you get a single-element array describing the whole viewport, so you do not need a separate branch. Support, though: Browser Support Chrome / Chrome for Android 138+ (June 2025) Edge 138+ Firefox No Safari / Safari on iOS No The foldable API lives in Chromium. The foldable iPhone does not run Chromium. Whether iOS 27's Safari changes that is worth watching in the release notes, but as of today, you cannot build on it. Which leaves one workable strategy: make your layouts survive any width and any aspect ratio, without asking the browser where the fold is. Boring advice. It also happens to be the advice that pays off on every device, not just this one. What to actually do Branch on container width, not viewport width. Media queries ask how big the viewport is. Container queries ask how much room this element was given. When unexpected widths show up, the second question is the more robust one. .card-area { container-type: inline-size; } @container (min-width: 640px) { .card { display: grid; grid-template-columns: 200px 1fr; gap: 16px; } } Audit your hard-coded breakpoints. Look for values like max-width: 767px that were picked with a specific device in mind. Unfolded, this thing can match either your phone styles or your tablet styles and look wrong under both. The number matters less than what you are switching at that number. Stop caching the first measurement. If you read window.innerWidth once during init and keep it, folding breaks you. Use resize or a ResizeObserver. let layoutMode = resolveLayoutMode(window.innerWidth); window.addEventListener('resize', () => { const next = resolveLayoutMode(window.innerWidth); if (next !== layoutMode) { layoutMode = next; applyLayout(layoutMode); } }); Check landscape. iOS 27 is bringing landscape layouts back to system apps that had been portrait-only, which reads as groundwork for the inner display. If you have pages nobody has opened sideways in two years, now is a good time. Test without hardware. Register 466 x 678 and 890 x 626 as custom devices in Chrome DevTools and toggle between them. For segment behaviour specifically, there is a polyfill: foldable-devices/viewportsegments-css-polyfill. The native side iOS 27's frameworks reportedly include a foldState property and an angleDegrees value for the hinge, neither of which existed in iOS 26. And at WWDC 2026, Apple pushed developers to design for a range of sizes and aspect ratios instead of specific screen dimensions. The wider rollout of window resizing for iPhone apps is part of the same direction. If you ship a hybrid app with a WKWebView in it, this lands on both sides of the stack. A resizable native container means the web view inside it has to be resizable too. Should you build foldable support now? Probably not as a line item. Foldables are still a low single-digit percentage of smartphone shipments, and the Duo's initial supply is expected to be limited. Building dedicated branching for it is hard to justify today. What I would actually do, in order: Now: open your existing site at 466 x 678 and 890 x 626, fix whatever visibly breaks. Next refactor: move hard-coded breakpoints toward container queries. Later: segment-aware layouts, once Safari's support status changes. Framing this as "foldable support" invites scope. Framing it as a responsive-design health check gets the same work done and is easier to explain to whoever is paying for it. Wrapping up The thing I keep coming back to is that the folded state is already off-spec. I expected the interesting problem to be the unfolded screen, and the actual finding was that both states are shapes we have not designed for. New form factors keep rewarding the same thing: layouts that were never that attached to specific numbers in the first place. References Apple - iPhone Duo specs MDN - horizontal-viewport-segments MDN - Viewport: segments Chrome for Developers - Support foldable devices with the Viewport Segments API web-features - Viewport segments