fit-iphone-duo

The problem

A guide for apps, a gap for the web

I was reading Apple’s design guidelines and found a new one: designing for iPhone Duo, Apple’s book-style foldable. In depth, with the reasons behind every rule, but written for apps.
Then I found a skill for it, super clean, for building apps with agents. Nothing like it for websites. If foldables end up in more hands, we’ll care about them the way we care about mobile first today.

An app on iPhone Duo

Apple’s APIs nudge controls off the fold
Told when the phone folds
A clean agent skill already exists

A website in Safari

Nothing moves off the fold by itself
Never told it folded: the APIs are behind flags
No up-to-date skill for it

Same device. Apps get help. Websites get new sizes.

Hesitation

Does the web even need this?

I stepped back first. A decent responsive site should cope without a dedicated fix. Was anything here really pressing, or was it a solution looking for a problem?
So I tried the online previewers and the one web skill out there, to see whether someone had solved it already, and how well. If they had, there was nothing to build.

What convinced me

Safari keeps a column for itself

The previewers all made the same mistake: the screen’s pixels divided by three, called the page. But Safari doesn’t give a page the whole screen. On the closed phone its controls take a column down the right, so a page gets 382px, not 466.
WebKit had published the real sizes on 23 October. They hold two sizes nobody showed: 368px tall when the closed phone turns sideways, and 385px wide in Split View. And on the open screen, a centred button lands right on the crease, where Apple says it’s hard to tap.
That was the gap: the real sizes, and a way to fix what breaks at them.

The sizes WebKit published for Safari 27.1, to scale. Where each bar sits is estimated.

Research

Read first, then cut

Apple’s guide and its four Tech Talks, WebKit’s notes, nine previewers, nine agent skills and the articles that measured what breaks. Every source saved, and rated by how far to trust it.
Apple writes for apps, so each rule needed a reading for the web. Some things don’t belong in a web skill at all: native APIs, cameras, layouts that only work with the fold flags on, and any kind of device detection.

Apple’s rules for apps, read for the web
Apple says	On the web
Build your app to resize	Opening the phone resizes the page without a reload. Never read the width once and keep it.
Keep interactive elements out of the fold	Small controls stay off the centre line of the open screen. Text, images and long rows may cross it.
Prefer an even number of columns	Two or four columns on the open screen, so a gap takes the crease, not a card.
Move only what’s necessary	The smallest fix that holds at every width. No redesign nobody asked for.
Controls sit on the trailing side	Safari puts its own column there, so the page gets 382 wide, and Safari paints your background colour behind it.
Avoid metrics tied to a specific screen	No device detection. The user agent says “iPhone” at every size, even 951 wide.

The idea

A prompt away

You don’t have to fit your site to iPhone Duo today. But when you want to, it shouldn’t be much work. You shouldn’t have to remember five sizes, where Safari keeps its bars, or what Apple says about the fold.
So the skill carries all of it. Say “make my site work on iPhone Duo”, and your agent finds what breaks, shows you, and fixes it in your own code.

Audit Five sizes, in WebKit every page with controls, the crease drawn in
Triage A level for each finding safe fix, my pick, needs you, or leave
Your go One word safe fixes and picks are made; questions wait for answers
Prove Audit again fixed, still there or new, item by item

nothing in your code changes before your go

You answer what’s yours. The skill does the rest.

Approach

Fix the cause, never the device

The quick fix is a patch: detect iPhone Duo, add a block of CSS for its widths. It breaks on the next foldable, and the user agent says “iPhone” at every size anyway.
So the skill fixes the cause, and only that: a layout that holds from 382 to 951, an even number of columns, a pair of buttons instead of one centred alone. It’s Apple’s own rule: move only what’s necessary.
Some rows have no clean fix, like five links centred in a footer. For those there’s one labelled last resort: a rule for touch screens at the open width only. My own footer needed it.

A patch for the device

Detect the device, then branch
A block of CSS for its widths
Breaks on the next foldable

A fix at the causethe skill

Holds at any width, 382 to 951
The smallest move that works
Never reads the user agent

Fit the layout, not the phone.

Design call · output

Decide from pictures, not text

The first report was text, plus screenshots to read alongside it. I asked what would make it quicker to grasp, and for a “shall I just do it?” mode for people who’d rather leave the decisions to the agent.
Now every finding is a card with the problem outlined on a screenshot, sorted into four levels. “Go” makes the safe fixes and the agent’s picks. Anything that changes content waits for you.

One card from the report. On the left, the open screen with a red dashed line down the middle, the crease, running straight through a lone Start writing, free button, outlined in blue. On the right: Control on the crease, marked Needs you and To fix, 200px wide across the crease at x 475.5. Under Your call, the question: add a second button so the gap lands on the crease, or move the one button left on wide screens? Under Options, why: a pair is the smaller change, but it adds a call to action, which is a content decision. Then the file and line. — A content change is never the agent’s call. It asks.

The support act

A playground that tells the truth

The skill is the product. The playground is where you see the problem first and check the fix after: your site at the five sizes, Safari’s bars where they sit, the crease drawn in, on a device sized from Apple’s own dimensions.
Open or close it, and your page resizes without a reload, through the in-between size Safari reports mid-fold, as on the device. Anything that’s an estimate is labelled on screen.

The playground with the phone closed. A sample page, Fold Notes, fills 382 by 580 of the screen, and Safari’s controls run down a column on the right, with the Dynamic Island, the time and the back, forward, share, bookmarks and tabs buttons. Under the device: 382 by 580 CSS px, no crease, and a toolbar to switch between Closed, Closed wide, Open, Open tall and Split View. — The sample page follows its own advice: on the open screen, the crease falls between its two buttons.

The playground with the phone open and folded. The same page fills the wide screen with Safari’s bars at the top and bottom, and a red dashed crease runs down the middle, between its two buttons. A Fold note above explains: partly folded, the screen curves here and small controls are hard to tap; keep buttons, links and fields off this line, while text and images can cross it. — The sample page follows its own advice: on the open screen, the crease falls between its two buttons.

Try your site in the playground

With AI

I made the calls, Claude did the legwork

We worked as a pair in Claude Code. Claude researched, built and tested; I made the calls, from options with a recommendation. Research came before any code, and every call is written down with its reason.
Outside skills were audited first, never applied blindly. A reviewer that wrote none of the code read it, and every test was proven by planting the bug it should catch.

The calls, and why
The call	Why
The playground first	It shows the problem in a minute, and it became the skill’s test bench.
WebKit’s real sizes	Screen pixels divided by three isn’t what Safari gives a page.
WebKit for the audit, Xcode optional	The same engine family as Safari, on any OS. Most people don’t have Xcode 27.1, so the Safari pass runs only where it can, and says when it didn’t.
Fix the cause, not a patch block	A patch for one device’s widths breaks on the next one.
The fold APIs as an extra, never required	They sit behind Safari flags that are off by default. Almost no visitor has them.
“Go” covers safe fixes and picks only	Fast for people who’d rather delegate. Anything that changes content stays the owner’s call.
Estimates labelled where you see them	Being more honest than the previewers is the whole point.

Results

Tested on real sites, then on mine

Five real sites first. Each of the big four had something on the crease, like Tailwind’s ⌘K search and Stripe’s Resources menu. Early false alarms went: links inside sentences may cross the fold, and two columns of text aren’t a grid.
Then my own site, the one I know by heart. The first list said four things must be fixed, and three were the skill’s own mistakes. Six fixes to the skill later, the whole loop ran on it: audit, triage, my answers, fix, audit again. Two CSS files changed, and nothing left to change.

5 Real sites, first strivelabs.ai, Tailwind, Bootstrap, Wikipedia and Stripe. About a minute each
3 of 4 False alarms, on my own site The first “must fix” list was mostly the skill’s mistakes. Six fixes to the skill followed
10 → 0 Left to change, on my homepage 6 fixed in two CSS files, 4 left on purpose, each with its reason
33 Self-test checks Three pages with problems planted on purpose, and the judgement calls

Credits

Built on others’ work

Most of what this skill knows, someone else found first. Apple wrote the rules, WebKit published the numbers, and others measured, built and shared before me.

Learnt from

AppleDesigning for iPhone Duo, and its four Tech TalksThe rules: the fold, even columns, move only what’s necessary.
WebKitFeatures for Safari 27.1The five sizes Safari gives a page, and the fold APIs behind flags.
mirzaaghazadehiphone-duo-skillsThe clean skill for apps that got me asking about the web.
tyoukyou23 on dev.toI measured what Safari actually gives your web page on iPhone DuoThe mid-fold resize, measured on the simulator.
chuspeeismiphone-duoThe glass fold the playground borrows, without Three.js.
Emil KowalskiDesign engineering and animation skillsThe audits that polished the playground.

Misses & lessons

What I’d tell day-zero me

MissTrusted an online previewer’s idea of the screen.

LessonAsk where the numbers come from. Screen pixels divided by three isn’t what Safari gives a page.
MissAssumed a decent responsive site needs nothing.

LessonMostly true. The breaks hide at the edges: a 368px-tall screen, the crease, a width read once.
MissRan the first audit on my own site and believed the list.

LessonTest on a site you know by heart. You spot a false alarm in a second.
MissShipped a report you had to cross-read with screenshots.

LessonThe output is the product. Pictures and a plan get decisions made.

Limits & next

Honest about what’s left

The audit runs in WebKit through Playwright, not in Safari itself, and the playground runs in your own browser. Both say so where you can see it.
A few numbers are still estimates: where the crease sits on the open, tall screen, and where Safari draws its bars. The skill’s Safari simulator pass is written, but it has never run, because I skipped installing Xcode.

NextA real device, the simulator pass, and more sites from the people who try it.

At a glance

The aim

My part

Considered