Foldable phones and your website. What actually changes

Apple announced the iPhone Duo on 9 September. Pre-orders open 16 October and prices start at $1,999, for a 7.6-inch inner display and a 5.4-inch outer one that share an aspect ratio.

A less glamorous number matters more to your website.

Counterpoint has foldables growing by about a fifth this year, which still leaves their share of the phone market somewhere around two percent, and two percent invites you to ignore the whole thing. Except that in a single visit this phone takes the window width from under 470 points to nearly 900, with no reload anywhere in between.

One visit, two window widths

On an ordinary phone the window width is settled once and stays put, so whatever measures it during load is right for the rest of the session.

Foldables end that. Someone reads half an article, opens the device, the browser fires a resize, and your layout is expected to repaint instantly and land on the same paragraph.

When a page only sorts itself out after a refresh, you have found the bug. Something measured the width once and has been trusting that number ever since. Usually a carousel, a virtualised table, a charting library, or code of your own that called window.innerWidth and kept the answer.

The API everyone will recommend does nothing on an iPhone Duo

Search for foldable advice and you will be pointed at the Viewport Segments API. The horizontal-viewport-segments media query and the env(viewport-segment-*) variables let you lay content out around the hinge so no button or sentence ever lands on the crease.

Two problems. MDN lists the feature as experimental and explicitly outside Baseline, meaning it does not work in some of the most widely used browsers. And Safari does not implement it at all, nor Device Posture.

So on the device that started this conversation, the web knows nothing about the hinge. It sees a window of a certain width and that is the end of it. Chrome and Samsung Internet have an answer here, and the device that raised the question runs neither.

What is left is the part that works everywhere. A layout with no device breakpoints, flowing from the width of whatever contains it.

What actually breaks

Horizontal scrolling goes first. Fixed pixel widths survive at 390 points because nobody ever tried them there, and they surface at 466. A table with a min-width, a 480-pixel modal, a sticky header holding three items in a row.

Then the 768 breakpoint. An open foldable sits around 890 points, so it collects the desktop layout. In one hand. On a touchscreen. Hover-triggered dropdowns stop working from that moment, and a 28-pixel button is not something a thumb can hit.

Line length is the quiet one, which is why it survives longest. A single column of text with no max-width looks fine at 390 and runs to a hundred and twenty characters per line at 890.

The last one only shows up on Samsung and the Chinese foldables, where a modal centred on screen lands squarely on the hinge. The fix only exists where Apple is not, because those browsers do implement segments.

Testing this without buying a two-thousand-dollar phone

Open your site and drag the edge of the window. Slowly, from 1,200 points down to 440. No refresh.

Nearly every fault above shows up during the drag and vanishes on load, which is precisely why fixed-size testing misses it. DevTools with a device preset does the same thing a reload does, creating a window and loading the page into it.

Four widths are enough.

Apple has not published web viewport values. The 466 and 890 figures are a third-party estimate worked back from the panel resolution, and the 600 to 700 band is my recommendation rather than any phone's spec. Test against them, and keep them out of the code.

What to do with the list

The drag produces a list. Usually three or four items, and one of them is a table.

Worth noticing that none of them was caused by a foldable. They have been sitting there for years with nobody in a position to see them, because a test device has one width and that width does not move during the test. What the two-thousand-dollar phone brought is a reader who moves that width deliberately.

The same person turns up on a tablet with resizable windows, in Windows split view, and any time a browser gets dragged into a third of a wide monitor. Container queries have been Baseline since February 2023 and a component that sizes itself against its parent survives all of it, which we went through in the piece on the end of device breakpoints. If your site predates 2023 it almost certainly runs on device-shaped media queries, and what still holds from that era is covered in our take on responsive work.

If you would rather not work through the list alone, we will look at it with you. It tends to be repairs in three components rather than a new build.