What the iPhone Duo reports to CSS, folded and open
Two viewports, one device, and a breakpoint your layout will never render at. Check both states in the browser you already have open.
Apple's foldable goes on sale on 23 October. Almost nobody writing CSS this month has held one, and the first week of traffic from it will land on layouts that were never rendered at either of its sizes. The iPhone Duo simulator puts a page inside both panels at once so you can see what breaks before the hardware does it for you.
How it works
- Give it a page. Paste a URL, or switch to the HTML tab and drop in markup straight from your editor.
- Pick a state. Folded shows the cover panel, Unfolded shows the inner one, and Side by side puts both on screen together.
- Read the row underneath. It names the framework tier each viewport lands on, and the one the device skips over.
The two numbers that matter
Closed, the cover panel reports a viewport of 466 by 678 CSS pixels. Open, the inner panel reports 890 by 626, and it is landscape. Both run at a device pixel ratio of 3, which puts the physical grids at 1398 by 2034 and 2670 by 1878. That works out near 457 and 430 pixels per inch across a 5.4 inch cover and a 7.6 inch interior.
Apple kept the two panels at roughly the same shape, about 1.45 to 1 one way and 1.42 to 1 the other, so opening the phone is closer to a scale change than a reshuffle. The orientation still flips. A hero section that assumed portrait forever gets 626 pixels of height to work with, and a sticky header plus a cookie bar can eat a third of that before any content appears.
The breakpoint nobody renders
Here is the part that catches people. Unfolding takes the viewport from 466 to 890 in one gesture, a jump of 424 pixels with no intermediate stop. Tailwind's sm tier switches on at 640 and md at 768, so the device leaves your unprefixed base styles and arrives at md without ever sitting at sm. Bootstrap 5 does the same thing: below its 576 threshold when closed, past 768 when open.
If you have styling that only exists at sm, this device never shows it. If your md rules assume a laptop, or at least a tablet with a tall window, they now run on something 626 pixels high. Neither case throws an error. Both just look wrong, and the simulator's breakpoint row is there so you can see which one you are in without opening devtools and dragging a corner.
Where the crease falls
The hinge runs down the middle of the inner panel, which puts it at roughly 445 pixels in. On a three column grid that is the seam between columns and nothing lands on it. On a two column grid it runs straight through the gutter, which is fine. On a centred call to action it runs straight through the button, which is not.
The crease overlay draws that band over the preview so you can check it in a second. Turn it off when you want a clean screenshot. It is a visual aid, not a media query: the CSS standard for this, horizontal-viewport-segments, ships in Chromium and Safari does not support it yet, so on the device that actually has the hinge the only reliable signals are width, height and orientation.
Simulator, not emulator
Those words get used as if they mean the same thing, and the gap between them decides what you can trust here. This tool reproduces the viewport, the pixel ratio and the panel geometry, then lets your own browser engine render the page. An emulator runs the actual operating system and the actual Safari build, which means Xcode on a Mac.
For layout work the viewport is what decides the outcome, and a browser at 890 by 626 will make the same grid decisions Safari does. For anything touching Safari's own behaviour, the keyboard, or scroll physics, the frame here will mislead you. Use it to catch the layout problems early and cheaply, then confirm on the real thing.
One limit worth knowing about the URL tab: plenty of sites send X-Frame-Options or a frame-ancestors policy, and when they do your browser refuses the embed and the panel stays blank. That is the site talking, not the tool, and nothing running inside a page can override it. Your own staging environment usually can be framed, and when it cannot, pasting the markup into the HTML tab always works.