Foldable phones and your website. What actually changes

Apple introduced the foldable iPhone Duo. For a website, the useful question is what happens to layout and page state when the available space changes.

Test width changes during reading or while a form is partly filled in. A screenshot taken after a reload does not cover that transition.

One visit, two window widths

Even an ordinary phone can change viewport width when rotated. A foldable adds another way for that change to happen during a visit.

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

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

Segment APIs need a fallback

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.

MDN lists horizontal-viewport-segments as experimental and outside Baseline. Support depends on the browser and device posture. Use segments as an enhancement where available, while keeping the layout usable without them.

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 side by side, each of them written when one width was all any page ever had.

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, which nobody notices until the layout arrives on something you can touch.

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.

On devices with separate viewport segments, also check the position of modal dialogs. A physical display crease alone does not establish that the browser exposes segment information.

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.

Dragging can reveal faults that disappear after a reload. You can also resize the responsive viewport in DevTools without reloading. A fixed device preset alone does not test the transition.

Use these as starting checkpoints.

The table provides illustrative test widths, not confirmed web viewport dimensions for a particular phone. Test the transitions between them too.

What to do with the list

The drag produces a list. Record the width and steps that reproduce each fault.

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 the test device has one width that never moves 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 on any wide monitor where the browser sits in one third of the screen. 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.

An older site does not automatically need rebuilding. Check resizing first, then fix components that keep their initial dimensions. Our responsive design article provides more context.

If you would rather not work through the list alone, we will look at it with you. The review determines the scope. It may not require a new build.