Your website on the iPhone Duo: the slow-resize test

Apple announced the iPhone Duo on 9 September: a 5.4-inch phone that opens into a 7.6-inch screen, in shops from 23 October, from $1,999. (Apple Newsroom) Both displays share the same aspect ratio, Safari can run two windows side by side on the inner screen, and an Apple Pencil is coming later this year.

Here is what that means for your website: nothing new, if it was built properly. And a very visible problem if it was not.

What actually changes on a foldable

Three things, none of them exotic.

• The viewport changes while the page is open. Someone reads your site on the outer screen, opens the phone, and the same page is suddenly about 40% wider and taller. No reload. Your layout has to re-flow live, mid-scroll, with a form half filled in.
• Your site may get half a screen. Split View puts two apps side by side on the inner display. Your page next to their e-mail is a viewport narrower than a phone, at tablet height.
• Hover and precision arrive on a phone. With a pencil or a trackpad-style pointer, "tap" and "hover" are no longer the same thing. A menu that only opens on hover, or only on tap, breaks one way or the other.

Samsung's Fold and Flip, Google's Pixel Fold and Motorola's Razr have been doing all of this for years. The Duo just makes it mainstream — and puts it in the hands of the people who spend $1,999 on a phone, which is a precise description of the customers most of our clients want.

The test: resize the window, slowly

You do not need the phone. Open your site on a laptop, make the browser window narrow — phone width, about 360 pixels — and drag the edge slowly out to full width, then slowly back. Watch it like a film.

A site built properly behaves at every single width along the way. There is no moment where it is broken, no width where it "hasn't decided yet". Text scales smoothly, images keep their subjects, the navigation turns from a menu into a row and back without flashing, nothing sticks out sideways, nothing overlaps.

What you usually see instead:

• A horizontal scrollbar appearing somewhere around 700 pixels.
• Headlines that jump from small to huge at one exact width, because the design has three fixed sizes instead of one that scales.
• A hero image that crops the person's head as the box changes shape.
• A sticky header that lands on top of the first heading.
• A "100vh" section that is either cut off or leaves a gap, because a phone's viewport height moves with its address bar.
• Cards that are one column at 767 pixels and three at 768 — with a dead zone in between where they are too wide or too narrow.
• A menu that opened fine at desktop width and is now stuck open, half off-screen, after the resize.

Every one of those is exactly what happens on a foldable, in your customer's hand, without them touching the window. A foldable is a slow resize you cannot control. That is why we have always built to pass this test, on every project, before any device existed to force it.

How we build so it passes

• Fluid, not stepped. Type sizes and spacing are computed from the viewport with clamp() — one continuous scale from 320 pixels to a 5K monitor — instead of three breakpoints and a prayer for the widths in between.
• Layouts that decide for themselves. Grids that fit as many columns as the space allows (auto-fit with a minimum), and flex rows that wrap, so there is no magic width where things flip.
• Components that respond to their box, not the screen. With container queries a product card knows it is 240 pixels wide and rearranges itself, whether it is on a phone, in Split View, or in a sidebar. On the ordering site we are finishing for an Amsterdam butcher the card's flags collapse into a single dot the moment the card gets narrower than 250 pixels — the card decides, not the device.
• Heights that respect the real viewport. dvh/svh units instead of vh, and safe-area insets so nothing hides behind a camera notch or a hinge.
• Pointer-aware, not device-aware. We ask the browser "does this pointer hover?" and "is it coarse or fine?" — not "is this an iPhone?". Menus, tooltips and sheets work with a thumb, a pencil and a trackpad.
• Everything re-measures on resize. Drawers, sheets, sticky bars, the 3D layer — all of it listens for a size change and recalculates. We caught one of these ourselves this month: a product sheet that froze after a window resize mid-drag. Fixed the same day, precisely because a resize mid-interaction is what an unfold is.
• The galaxy too. Our homepage renders a Three.js scene into text characters; the character grid is sized from the viewport and rebuilt on every resize, so it fills a 5.4-inch screen, a 7.6-inch one and a 32-inch monitor with the same density. The engineering is here.
• Tested where it counts. Real phones on the desk, DevTools' foldable and dual-screen emulation for the hinge cases, and the slow resize, every time, before a client sees anything.

About the hinge

Browsers are adding ways to know where the fold is — the Device Posture API and viewport segments in CSS — so a layout can avoid putting a button under the crease or place two panels on two halves. Support is partial and mostly Chromium so far. We treat them as enhancements: nice when they are there, never something the layout depends on. A site that passes the slow-resize test does not need to know there is a hinge.

What this means if you are buying a site

Ask any agency one question: can I resize it? Then do the test above on the last three sites they shipped. If it breaks at some width on a laptop, it will break on a foldable, on a tablet in a stand, in Split View, and on the next screen shape nobody has announced yet.

Ours don't, and never have. Send us your URL and we will send back a screen recording of the slow resize — your site, phone width to desktop and back. It takes us five minutes and it tells you everything.