Apple's WebKit team on October 23, 2026 published "WebKit Features for Safari 27.1," a post by Jen Simmons that coincides with the arrival of iPhone Duo, Apple's first folding iPhone. According to WebKit, the device runs the same engine and the same web technologies as every other iPhone, with one user-facing change, two experimental APIs for developers and a table of viewport sizes that range from 382 to 951 CSS pixels wide.

In Short

Apple's new folding iPhone went on sale with a version of Safari that shows websites on two different screens, one narrow and one almost tablet-sized. That matters to anyone who builds web pages or places ads on them, because the same page now has to fit a much wider range of shapes on a single phone. Nothing about tracking or cookies changed in this release, and two new tools for detecting the fold are switched off unless a user turns them on.

A release defined by what it leaves out

Most WebKit feature posts run long. Safari 18.4, by comparison, arrived on March 31, 2025 with 84 new features and 184 fixes. The Safari 27.1 post is short, and it says so openly. "The 'big news' here is no news," according to the post. "It's Safari, with the same WebKit engine and the same web technologies as every other iPhone. Your websites and web apps work on iPhone Duo just like they do everywhere else."

The post opens with a single line: "Today iPhone Duo arrives, and with it, Safari 27.1." That date matches what Apple said in September, when the $1,999 iPhone Duo was presented with pre-orders from October 16 and availability from October 23 in more than 70 countries and regions, with a further 28 following on October 30. The phone ships with iOS 27.1, has a 5.4-inch outer display and a 7.6-inch inner display, and in the EU arrives without Siri AI.

The WebKit post describes Safari 27.1 entirely through iPhone Duo. It does not say whether the version also reaches other iPhones, iPads or Macs, and it lists no bug fixes, no deprecations and no changes to storage, cookies, link handling or tracking prevention. For an industry that has spent the autumn reading WebKit's output line by line, that silence is itself a data point, though not one that can be read as a decision either way.

The one change users will see

Only one behaviour changes for people browsing, according to WebKit. "Now, when someone holds iPhone Duo partially folded like a book while looking at a PDF on the web, Safari 27.1 automatically shows PDFs as two pages side by side," the post states. "When they open the screen flat or close it fully, Safari switches back to one page."

The change applies to PDFs viewed in the browser. The post does not extend it to ordinary web pages, which keep whatever layout their authors give them.

Five poses, five viewports

The core of the post is a description of how the screen behaves. iPhone Duo has two displays. The outer one is used when the phone is closed and, like other iPhones, works in portrait or landscape with Safari's tab bar at the bottom by default. The inner one, used when the phone is open, also rotates, but places the tab bar at the top, "similar to iPad or Mac," according to WebKit. In landscape on the inner display, users can place two windows side by side, which gives each one a narrow portrait viewport. As on other iPhones, the tab bar shrinks when the user scrolls.

"Across the possible combinations, the viewport width (in CSS pixels) in Safari 27.1 can range from 382 to 951. And the height can range from 368 to 902," the post states. WebKit published the following figures, with heights given as both the small viewport height (SVH, with full browser controls showing) and the large viewport height (LVH, with controls collapsed):

Pose Width SVH LVH
Outer display, portrait 382 580 618
Outer display, landscape 594 368 406
Inner display, portrait (one tab) 669 867 902
Inner display, landscape (one tab) 951 585 620
Inner display, two windows side by side 385 571 609

A few things stand out in the table. The gap between SVH and LVH, which reflects how much space the shrinking tab bar returns to the page, is 38 pixels on the outer display and in split view, and 35 pixels on the inner display with a single tab, according to PPC Land's arithmetic on WebKit's figures. The narrowest width, 382 pixels, is the closed phone in portrait. The split-view window, at 385 pixels, is only three pixels wider, so a page opened beside another app on the large inner screen gets almost exactly the space of the small outer screen.

The outer display in landscape is the shortest viewport in the set, at 368 pixels with controls visible. WebKit acknowledges the shape elsewhere in the post: "You might have noticed the outer display of iPhone Duo is wider and shorter than other iPhone displays."

What the numbers mean for ad slots

The post does not discuss advertising. Still, the widths have a direct bearing on which fixed-size placements can render without scaling. By PPC Land's own calculation against common display sizes, a 300-pixel-wide medium rectangle fits in every pose on the list. A 728-pixel leaderboard fits only on the inner display in landscape, at 951 pixels, and not on the inner display in portrait, at 669. A 970-pixel billboard fits in none of the five. The same physical phone can therefore move a visitor between a mobile-sized slot and a desktop-sized one in the course of a single session, simply by unfolding.

That shift also has consequences for viewability, which depends on how much of an ad sits on screen. A placement measured as in view on the tall inner display in portrait, at 867 pixels of usable height, may fall below the fold on the 368-pixel outer landscape view. The WebKit post contains no data on how people actually hold the device, so the distribution across these poses is unknown.

Avoid sniffing the user agent

WebKit's guidance on the numbers is to ignore them. "However, you don't need to worry about all these numbers," the post states. "Instead, lean into the wisdom of Responsive Web Design techniques." It recommends layouts that "simply work on every sized screen from the extremely large to the very tiny," built with media queries, CSS Grid and Flexbox.

The post then adds a sentence with a narrower audience: "Avoid UA sniffing to detect devices, and use feature detection instead." The phrase links to Mozilla's MDN documentation on alternatives to user agent sniffing. User agent strings are what many ad servers, analytics tools and device targeting systems read to decide whether a visitor is on a phone, a tablet or a desktop. The post does not say what user agent string Safari 27.1 on iPhone Duo sends, or whether it differs from other iPhones, so whether existing device classifications will place the unfolded phone in the phone or tablet bucket is not something the source answers.

For testing, WebKit points to Xcode 27.1 or later, which includes Device Hub, a tool for creating an iPhone Duo simulator. "You don't need iPhone Duo in hand to test your website or web app," according to the post. On October 5, Apple told app developers that iPhone Duo screenshots will be required for App Store submissions from April 2027, and pointed them to the same Device Hub tooling. The web side carries no comparable requirement.

Two APIs behind feature flags

For developers who want to design around the fold itself, Safari 27.1 includes previews of two specifications: the Device Posture API and the Viewport Segments API. Both are off by default. According to WebKit, they are enabled under Settings > Apps > Safari > Advanced > Feature Flags, by turning on "Device Posture API" and "Viewport Segments API."

That placement matters. Feature flags are set by the person holding the phone, not by the website. A site that relies on either API will see it only on devices whose owners have gone into Safari's advanced settings and switched it on, which in practice limits the audience to developers and testers. WebKit frames the release as a request for input. "If you try out these features, let us know what you think," the post states. "Do they unlock the ability to create the kind of experiences you want to create for iPhone Duo? Would you want them to work a bit differently instead?" It later adds that "there may still be time to evolve how they work."

Device Posture API

The simpler of the two reports whether the screen is partially folded. It is exposed in CSS through a device-posture media query and in JavaScript through navigator.devicePosture. According to WebKit, both return one of two values:

  • folded, when the device is partially folded, in a book or laptop pose
  • continuous, when the screen is flat, a state that covers both a fully open phone and a fully closed one

The second definition is worth noting. A closed iPhone Duo and a fully opened one both report as continuous, so the posture value alone does not tell a page which display it is on. Width, through ordinary media queries, does that job. In JavaScript, navigator.devicePosture.type returns the current value and a change event fires when it changes. The post's CSS example switches a layout to two equal grid columns when the device reports as folded.

Viewport Segments API

WebKit calls the second API "more complex." It describes the display's segments, which the post defines as "the separate portions on either side of the fold." With the flag on, Safari 27.1 supports two media queries, horizontal-viewport-segments and vertical-viewport-segments, which match the number of segments laid out side by side or stacked top to bottom. A value of 2 on the horizontal query corresponds to the phone held like a book. A value of 2 on the vertical query corresponds to the phone held like a laptop.

The API adds six CSS environment variables for sizing content to the edges of each segment: viewport-segment-width, viewport-segment-height, viewport-segment-top, viewport-segment-right, viewport-segment-bottom and viewport-segment-left. Each takes two indexes, a column and a row, counted from 0 at the top left. When two segments sit side by side, the left one is 0 0 and the right one is 1 0. When they are stacked, the top is 0 0 and the bottom is 0 1. WebKit's example builds a two-column grid whose columns each match the width of one side of the fold.

In JavaScript, window.viewport.segments returns an array of DOMRect objects, one per segment. WebKit advises reading it again whenever the posture changes or the window resizes, and its sample code listens for both events.

The post links each API to its MDN reference page. It does not say whether other browsers support them, and it gives no timeline for removing the flags.

The space behind the controls

The final technical section concerns an area Safari does not yet let websites use. On the wider, shorter outer display, iOS moves system controls to the side to give content more vertical room. "In Safari 27.1, web content does not currently extend to fill the space behind these controls," according to WebKit. Instead, Safari samples the page and extends its background colour into that space, as it does on other platforms.

WebKit says it wants to change that, and explains why the obvious route gives it pause. The existing mechanism is the HTML viewport meta tag with viewport-fit="cover", which lets a page draw edge to edge and relies on developers using environment variables to move important content away from system controls. "But as we research how today's sites are built, we see a lot of projects that fail to inset all four edges correctly," the post states. "We are investigating if there's a better way to accomplish the same result - something more foolproof and perhaps easier for you to use." No date or proposal is attached. The post ends that section with "stay tuned."

For publishers and ad operations teams, the practical reading is narrow. Sticky headers, anchored ad units and other fixed elements on the outer display currently sit inside a viewport that stops short of those controls. If WebKit later opens the space, layouts that do not handle insets could see content drawn behind system controls, which is precisely the failure the post says it found in existing sites.

What the post does not cover

Since September, WebKit has been the subject of sustained attention in advertising. Safari 27 shipped with iOS 27 on September 14, and on September 30 PPC Land reported that Safari 27 blocks The Trade Desk's ad delivery domain through a domain-blocking hook WebKit merged in February, with identity providers including ID5, LiveRamp and Permutive reportedly on the same list. On October 5, Apple asked The Trade Desk to test an iOS 27.2 beta build while the WebKit bug ticket stayed open. And on October 19, WebKit published "Blocking Identity Resolution Infrastructure," explaining that Safari 27 blocks identity firms that turn email addresses into tracking IDs on iOS 27, iPadOS 27, macOS 27 and visionOS 27.

The Safari 27.1 post addresses none of this. It does not mention the domain list, the Trade Desk ticket, identity resolution, click identifiers or cookies. Because the only fix Apple has publicly pointed The Trade Desk to sits in an iOS 27.2 beta, the absence of any reference in a 27.1 post is consistent with that timeline, but the post itself gives no indication either way. The WebKit post also does not say whether the blocking behaviour reported for Safari 27 is present on iPhone Duo; it says only that the device runs "the same WebKit engine and the same web technologies as every other iPhone."

There is one more open question the source does not raise. The two new APIs expose information about the physical shape and state of a device: whether it is folded, and the exact dimensions of each half of the screen. Safari's earlier privacy work has treated such signals carefully. In Safari 26, Advanced Fingerprinting Protection became the default for all browsing and, for scripts classified as tracking tools, blocks or adds noise to high-entropy APIs including Canvas, WebGL, Web Audio and precise screen measurements. Whether posture and segment values will receive similar treatment if the APIs leave the flags is not addressed in the post. While they sit behind settings that ordinary users are unlikely to touch, their usefulness for canvas fingerprinting-style identification of devices is limited by how few phones will have them switched on.

Why it matters to the marketing community

For most advertisers, Safari 27.1 changes little on day one. There is no new tracking restriction, no cookie change and no new measurement surface. What iPhone Duo adds is a device whose screen width can more than double in a second, from 382 to 951 CSS pixels and whose shortest view is 368 pixels tall. Creative built for fixed slots, device rules keyed to user agent strings, and fixed overlays all meet that range for the first time on an iPhone.

The price, $1,999, and the absence of any sales data mean the device's audience is unknown, and WebKit's post offers no projection. The App Store screenshot rule for April 2027 is Apple's clearest signal so far that it expects the form factor to persist. On the web, Apple has chosen to wait: the fold-aware APIs are previews, edge-to-edge drawing is under study, and the company's stated position is that sites built responsively need do nothing at all.

Timeline

Summary

Who: Apple's WebKit team, in a post by Jen Simmons, addressing web designers and developers building for Apple's folding iPhone Duo.

What: Safari 27.1 ships on iPhone Duo with the same engine as other iPhones, side-by-side PDF pages when the phone is half folded, viewports from 382 to 951 CSS pixels wide and 368 to 902 tall, and developer previews of the Device Posture API and Viewport Segments API behind feature flags. Web content does not yet extend behind the outer display's side controls. The post contains no tracking, cookie or privacy changes.

When: October 23, 2026, the day iPhone Duo went on sale.

Where: Safari on iPhone Duo, across its outer and inner displays, in the more than 70 countries and regions where the device launched first.

Why: A folding phone gives one device a wide range of screen shapes. WebKit wants sites to rely on responsive design and feature detection rather than device detection, and is seeking developer feedback on fold-aware APIs and on how pages might use the space behind system controls before committing to a design.