Primary topic Mobile UX
Apple’s first foldable iPhone does not require a special version of your website. That is the useful takeaway from WebKit’s October 23, 2026 announcement of Safari 27.1, released alongside iPhone Duo. The browser uses the same WebKit engine and web technologies as Safari on other iPhones. Regular responsive pages are meant to work without detecting a new device or adopting a new API.
There are two additions worth knowing about: Safari now changes its PDF presentation when the phone is folded like a book, and developers can experiment with APIs that describe the fold and the regions on either side of it. The catch is important: the Device Posture API and Viewport Segments API are developer previews behind feature flags, not capabilities ordinary Safari visitors can be expected to have enabled.
For site owners, the immediate question is less exciting than building a dual-screen interface, but more consequential: does the page still work when a wide display becomes a narrow browser window, or when the browser’s available height suddenly changes?
The screen gets bigger. The web viewport doesn’t always.
Imagine someone opening an article on the outer display, unfolding the phone to read on the inner display, then placing two windows side by side. The device has not changed, but the amount of room available to each webpage has changed dramatically. This is the distinction responsive design already understands: a browser window, not a product name, determines how much space a page can use.
WebKit’s published Safari 27.1 measurements put the outer display’s portrait viewport at 382 CSS pixels wide. An inner-display portrait window is 669 CSS pixels wide, while a single inner-display landscape window reaches 951. Put two windows side by side on that inner landscape display, however, and each gets a viewport just 385 CSS pixels wide. The outer display in landscape offers 594 pixels of width, but far less height.
That means the same phone can present what looks to your CSS like a compact handset, a moderately wide reading window, or something approaching a tablet-sized canvas. More importantly, the 385-pixel split window is nearly as narrow as the 382-pixel outer display. A layout that assumes an unfolded phone must have room for a sidebar can fail precisely when the user starts multitasking.
These figures are CSS pixels, not the resolution of either physical panel. They describe the space Safari gives web content in the configurations WebKit documented. They are useful test points, not an invitation to write device-specific breakpoints or identify iPhone Duo from its user agent. The safer approach is the one WebKit recommends: fluid grids, flexible content, and layout decisions based on the viewport.
What to test on an existing mobile site
Start with a real task, not a screenshot of your homepage. On a news site, open a story, expand an image, use search, and continue reading after a resize. On a store, open a product, select an option, and reach the checkout controls. A site can look acceptable at every static width while still breaking when a menu stays open, a chart retains its old dimensions, or a fixed button covers a form field.
- Check the two narrow cases: 382 and 385 CSS pixels. Make sure navigation, article text, consent notices, tables, filters, and checkout controls remain usable without accidental horizontal scrolling. In a split window, don’t assume the site is on the outer display.
- Check the wider layouts: 669 and 951 CSS pixels. See whether your sidebar, cards, image gallery, or reading column actually benefits from the extra width. A two-column layout is only an improvement if both columns remain readable.
- Check short windows, not just narrow ones. The outer display in landscape has a small viewport height of 368 CSS pixels according to WebKit. Full-height menus, sticky buy buttons, video controls, and large consent dialogs can consume nearly all of that space.
- Change the window while a task is in progress. Open and close the device, rotate it, and enter or leave side-by-side mode. Watch for clipped content, displaced overlays, stale canvas dimensions, lost form input, or interfaces that need a reload before they fit.
A basic responsive grid remains the right starting point. For example, a reading layout can keep its article in one column until there is enough room for a secondary rail:
.story-layout {
display: grid;
grid-template-columns: minmax(0, 1fr);
gap: 1rem;
}
@media (min-width: 48rem) {
.story-layout {
grid-template-columns: minmax(0, 2fr) minmax(15rem, 1fr);
}
}The 48-rem threshold here is an example of a content-driven breakpoint, not an iPhone Duo setting. If the rail needs more room, move the breakpoint; if it contributes little to the task, leave it below the story. The real test is whether the design still makes sense between the familiar phone and tablet sizes, including when text is enlarged.
You can run those checks without buying the hardware. WebKit points developers to Device Hub in Xcode 27.1 or later, which includes an iPhone Duo simulator. Open your site in the simulated Safari browser and switch among the device’s poses and window arrangements. Simulator checks are particularly useful for layout and API experiments; they do not replace real-device testing for touch behavior, performance, or other hardware-dependent details.
The height problem deserves as much attention as the fold
Safari’s published viewport chart includes both SVH, the smaller viewport height when browser controls take up more room, and LVH, the larger height available when those controls retract. On the outer display in portrait, those figures are 580 and 618 CSS pixels. In inner-display landscape, they are 585 and 620. This is normal mobile-browser behavior, but it becomes easier to miss when testing a new device only at its largest size.
Consider a menu designed as a full-screen panel with a permanently visible confirmation button at the bottom. If it is sized as though the browser controls were already hidden, the button may sit outside the space the user can actually see. A full-page layout also needs to cope with the software keyboard, which can further reduce the visible area.
For sections that should fill the available page without hiding their own content, a flexible min-height: 100svh is often safer than a rigid height: 100vh. The dvh unit can be useful when a surface must track the changing visible viewport, though it can also cause resizing as browser controls move. MDN’s explanation of small, large, and dynamic viewport units makes the trade-off clear. Whatever unit you choose, keep critical controls reachable and allow content to scroll when space is tight.
The fold-aware APIs are for prototypes, not required site updates
The experimental APIs answer a different question from responsive CSS. Ordinary media queries can tell a page that it is 385 pixels wide. They cannot tell it whether one browser viewport is being divided by a physical fold, or where that division lies. That distinction matters for an interface intentionally designed to put a page of text on one side of a book-like device and supporting tools on the other.
Device Posture: is the screen partially folded?
With the preview enabled, the Device Posture API offers a CSS device-posture media query and a JavaScript navigator.devicePosture interface. Safari reports folded for partial folds such as book or laptop poses, and continuous when the screen is flat. Crucially, continuous covers both a fully opened and a fully closed display. It does not mean “large screen.”
Posture alone also does not say whether the halves sit left and right or above and below. A reader interface that reacts only to folded could put its controls in the wrong place when the user rotates the device. For precise placement, the page needs information about the available segments as well.
Viewport Segments: where are the usable regions?
The Viewport Segments API describes the distinct regions within a single viewport separated by a fold or hinge. CSS can query horizontal-viewport-segments: 2 for two regions side by side, or vertical-viewport-segments: 2 for two stacked regions. Indexed env() values, such as env(viewport-segment-width 0 0) and env(viewport-segment-width 1 0), expose their dimensions; JavaScript can inspect window.viewport.segments.
The distinction between segments and windows is easy to miss. Two side-by-side browser windows on the inner display have two separate narrow viewports. That does not make them the two segments of one webpage. Segment-aware layout is for a single web experience interacting with a fold, not a way to spread your site across someone else’s window.
As of Safari 27.1 on iPhone Duo, developers must explicitly enable both previews under Settings > Apps > Safari > Advanced > Feature Flags, selecting “Device Posture API” and “Viewport Segments API.” WebKit says their behavior may still evolve. MDN also marks the segment APIs as experimental and not available across all widely used browsers. A production site must therefore remain complete and usable when these features are absent.
There is still value in experimenting. A reading app might place text in one region and annotations in the other; a learning interface might put a demonstration above controls in laptop pose. Build either as an optional enhancement to a working one-column or flexible layout. If the API is unavailable, the user should not lose the article, the video, the form, or the primary action.
Why Safari won’t yet let webpages fill the strip behind the outer controls
There is another iPhone Duo detail that site developers cannot fix with a fold media query. On the outer display, Safari moves controls to the side to preserve vertical room. In Safari 27.1, webpage content does not extend into the strip behind those controls. Safari instead extends the webpage’s background color into that space.
That can make a page appear to have an unusually large empty margin, even when its content fits the actual viewport correctly. It is not evidence that the site needs a wider CSS canvas. Nor is adding viewport-fit=cover a documented way to claim that strip today.
Safari has long supported viewport-fit=cover and env(safe-area-inset-*) for designing around display edges, as WebKit explained in its iPhone X safe-area guidance. But the new outer-control region is a separate design question. WebKit says it is considering how to allow content farther into that area without encouraging sites to hide text or buttons beneath controls. Its concern is practical: existing edge-to-edge layouts often fail to account correctly for insets on all four sides.
For now, check that backgrounds look intentional, that important content stays within the usable viewport, and that any existing safe-area padding works on all edges. Do not redesign the page around an extension API Apple has not shipped or promise stakeholders a full-width outer-display layout that Safari does not currently offer.
PDFs get the immediate, user-visible improvement
The clearest change that Safari 27.1 actually gives users by default is in PDF reading. When an iPhone Duo is partly folded like a book, Safari shows a PDF as two pages side by side. Open the device flat or close it fully, and the PDF returns to a single-page presentation. That behavior comes from Safari, not from a new CSS rule that a publisher needs to implement.
If your publication offers reports, instruction manuals, catalogs, or downloadable documents as ordinary PDF links, this is a reason to check how a representative document reads in Safari’s built-in presentation, not a reason to create a custom two-page viewer. If your site already renders PDF pages inside its own JavaScript or canvas-based interface, do not assume that interface automatically acquires Safari’s behavior; it has its own layout to test.
The benefit is straightforward for readers: a document originally designed around facing pages can now appear that way when the phone is held like a book. A browser feature can improve the reading experience without requiring every publishing platform to reinvent document navigation.
What should change now—and what can wait?
Change now: repair layouts that depend on a particular phone width, assume an open foldable always has a wide viewport, or let fixed panels cover content in a short window. Test the actual browsing journey at the documented narrow, wide, and short sizes. Make sure layout changes do not discard user input or render critical controls unreachable. These are ordinary responsive-design issues, but the new display combinations make them easier to expose.
Prototype, if your product needs it: posture-aware reading, teaching, media, or productivity layouts that genuinely benefit from separating two regions around a fold. Use Safari’s feature flags and the iPhone Duo simulator to learn how the APIs behave. Keep the nonexperimental layout as the default and avoid making the new APIs essential to reading, buying, or completing a task.
Wait: for the fold-aware APIs to become normal Safari capabilities before treating them as a broadly available interface contract, and for Apple to define a safe way to use the outer-display space behind Safari’s side controls. Nothing in the October 23 announcement establishes a new mobile SEO ranking requirement, device-specific URL strategy, or reason to replace a responsive website with a separate iPhone Duo edition.
Safari 27.1’s most useful lesson is not that every site should imitate a book. It is that the difference between a phone and a tablet is increasingly the wrong question. The right one is whether a reader can keep using your site as the space available to it changes—and, for now, that is something the web’s established layout tools can already handle.