- WebKit says Safari 27.1 on iPhone Duo uses the same engine as other iPhones, and that responsive sites should look and work great.
- Two fold-aware web features, the Device Posture API and the Viewport Segments API, are developer previews behind feature flags, and WebKit says they may still change.
- Ask your team whether layouts adapt to any width, whether code guesses devices by user-agent, and whether the site has been tested in the iPhone Duo simulator.
A new screen shape, and no to-do list
A new device usually sends the web team a list of work. WebKit, the browser engine behind Safari, says iPhone Duo does not. In its post on Safari 27.1, WebKit calls the "big news" "no news". Under the hood, this is the Safari that other iPhones already run, with the same engine and the same web technologies.
This shows something about web costs. The price of a new screen shape is set long before the screen exists. It depends on how a site was built, not on the device.
What changes for the user
WebKit describes one user-facing change. When someone holds iPhone Duo partly folded, like a book, while viewing a PDF, Safari shows two pages side by side. When the screen is flat or fully closed, Safari goes back to one page.
Nothing in that behavior asks a website owner to do anything. That is the point.
The range of screen sizes, and how WebKit frames it
iPhone Duo has two displays. The outer display is used when the phone is closed. The larger inner display is used when it is open.
On the outer display, Safari runs upright or sideways and keeps its tab bar along the bottom edge. The inner display also turns either way. There, Safari moves the tabs to the top, an arrangement iPad and Mac users already know. With the inner display on its side, users can open two windows next to each other. Each window then gets a narrow, portrait-shaped viewport.
Across all these poses and window setups, WebKit lists page widths from 382 up to 951 CSS pixels. Heights in the same setups span 368 to 902. A CSS pixel is the unit browsers use to lay out a page, not a physical dot on the screen.
WebKit offers these numbers as context. It tells developers they "don't need to worry about all these numbers" and should not design around them. Its advice is plain. Use responsive design: media queries, CSS Grid and Flexbox. Avoid user-agent sniffing, which means guessing the device from the label the browser sends. Use feature detection instead.
How the two fold features work
For teams that want to go further, Safari 27.1 on iPhone Duo previews two web features. Both sit behind feature flags, under Settings > Apps > Safari > Advanced > Feature Flags.
The Device Posture API tells a page whether the screen is partly folded. It reports one of two postures. "Folded" means the device is partly folded, in a book or laptop pose. "Continuous" means the screen is flat, which covers both fully open and fully closed. Developers can read it in CSS with the device-posture media query, or in JavaScript with navigator.devicePosture.
The Viewport Segments API is more complex. It describes the separate portions of the display on either side of the fold. It adds media queries that count how many segments sit side by side or stacked. It also adds six environment variables for sizing content to each segment's edges. In JavaScript, window.viewport.segments returns one rectangle per segment.
WebKit says there may still be time to change how these work. That is a reason to treat them as experiments.
The open question: the space behind the controls
The outer display is wider and shorter than other iPhone screens. To give content more vertical room, iOS moves controls to the side. Web content does not currently extend behind those controls. Safari stretches the page's background color to fill the space.
WebKit would like designers to use that space. One option is the viewport-fit="cover" setting, which pushes the page to the screen edges. It relies on developers keeping important content away from system controls. WebKit says that as it researches how current sites are built, it sees "a lot of projects that fail to inset all four edges correctly". It is investigating something "more foolproof".
This shows how the way sites are built today can shape how a browser maker designs new features. WebKit is weighing a safer design because many current sites do not inset all four edges correctly.
What to ask your team
First, does our layout adapt to any width, or is it tuned to a list of known devices? Second, does any code detect devices by user-agent? WebKit advises against that.
Third, has someone tested the site in the iPhone Duo simulator? WebKit says Xcode 27.1 or later includes Device Hub, where a team can create one. Our suggestion is to check layouts across the 382 to 951 pixel width range. WebKit does not set that range as a test plan.
Fourth, are we building customer-facing features on the fold APIs? They are behind flags and may change, so a trial is safer than a commitment. Teams can send feedback to WebKit's Jen Simmons on Bluesky or Mastodon.
A site built to fit any screen has little to redo when a new one arrives. A site built for a list of screens must start a new list.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: WebKit.
