Short answer: Testing for iPhone Duo comes down to three layouts and one transition: the outer screen, the inner screen, half of the inner screen in Split View, and whatever happens to the page or the app when someone unfolds the phone mid-task. Safari gives a website no event, no media query and no API for the fold, so to a site the Duo is three viewports and a resize. A native app gets more from iOS 27.1, which also means more to get wrong. Both are testable before the device ships on 23 October.
What the Duo is, from a tester's point of view
Apple announced iPhone Duo on 9 September: a 5.4-inch outer display, a 7.6-inch inner display with the same aspect ratio, iOS 27.1, from $1,999, in stores from 23 October. TrendForce expects about 5 million units this year, which would make Apple the second foldable brand after Samsung in its first quarter on sale.
Apple publishes pixel resolutions only, so the working CSS sizes below are the tech-specs resolutions divided by the 3x scale factor. They're derived; measure a real device before you hard-code anything.
| Layout | Working CSS size | What it is |
|---|---|---|
| Closed | about 466 × 678 | A normal narrow phone with a vertical Dynamic Island on the side |
| Open | about 626 × 890, rotates to 890 × 626 | Wider than any iPhone, narrower than an iPad mini |
| Split View | about half the open width, 445 in landscape, 313 in portrait | Your site or app beside another app |
Apple's developer material settles the rest of this article. The inner display is a different size class: the outer screen behaves like any iPhone, compact width in portrait. The inner one has regular horizontal and vertical size classes, the same category as an iPad, so sidebars appear in apps and tablet breakpoints fire on websites. Split View puts two apps side by side on the inner display, including two windows of Safari; one launch-event hands-on reported the split fixed at 50/50, Engadget said apps can be resized on the fly, and Apple hasn't said. And the layout changes while it's in use: Apple's line is that content reacts as it folds, reorients when turned to the side, and switches to the appropriate display when flipped over.
For a website: Safari can't see the fold
The web platform has two APIs for foldables, CSS Viewport Segments and the Device Posture API, and Chrome has shipped both since 125. WebKit's standards-positions tracker lists no position on either, and the WebKit Features for Safari 27.0 post, published a week after the Duo announcement, doesn't mention foldables. There are no Safari 27.1 release notes yet.
So the working assumption for launch day: Safari on the Duo reports as an iPhone, gives you the viewport it has at that moment, fires resize when that changes, and knows nothing about the hinge. The one Duo-specific promise in the HIG is that safe-area insets are asymmetric: the camera reservation sits on one side, and in Split View each app's controls hug its outer edge. A layout that assumes the left inset equals the right one is wrong on this device.
What to check, per layout. Closed, your existing mobile tests already cover it. Open, check which breakpoint fires and whether it's the one you'd choose: a phone layout stretching one column across the open screen, or a tablet layout putting a sidebar on a phone held in one hand. Split View is where tablet-first CSS falls apart, because your min-width: 600px query no longer matches while your pointer and hover queries still say tablet, and anything positioned against the screen edge is now positioned against a bank app. Run the checkout there before a customer does.
Then the unfold. Start a form or scroll into a product page closed, unfold, and look for a dropped scroll position, a modal centred for the small screen sitting top-left on the large one, or a 100vh hero sized for one toolbar now covering the fold line. Fold back. Rotate. Apple tells native developers to check every pose and rotate in each one; the same loop applies to a page.
Underneath all of that sits the ordinary iOS list, which breaks more sites than the fold will. 100vh computed with the toolbar collapsed (fix: dvh, in Safari since 15.4). position: fixed drifting when the keyboard opens. Native wheel pickers for dates and selects. Video that autoplays only muted and inline. And Intelligent Tracking Prevention blocking third-party cookies and capping script-written storage at seven days, which is what breaks cross-domain logins. None of it reproduces in desktop Chrome with the device toolbar on. Outside the EU, every browser on an iPhone is WebKit, because Apple's guidelines require it.
For a native app: the Duo changes more
A website gets a resize event. An app gets a new size class on the inner display and orientation rules that don't honour its supported interface orientations. It also gets asymmetric safe areas with a camera reservation that moves, Split View with controls on the outer edge, a UIHingeInteraction with a continuous hinge angle, and the ability to open multiple windows of itself on the inner display only. Apple's own instruction is to check how your app appears on both displays, closed, open or partially folded, and rotate in each pose, and to stop using UIInterfaceOrientation or the device idiom for layout decisions.
That's a lot of new states, and the way most teams test native apps won't scale to it. A hand-written XCUITest or Appium script encodes one screen's element tree. The Duo gives you the same screen in four poses with controls on different edges, so a script that found the "Pay" button at the bottom on the closed screen is looking in the wrong place on the open one. The maintenance tax that was already the problem with scripted mobile suites gets multiplied by the number of poses.
How QA.tech covers it
It won't test what a simulator can't show, and that list is below. QA.tech, an agentic testing platform, tests native iOS and Android apps with the same agent that tests websites. You give it a goal in plain language and it works the app through taps, swipes, typing, hardware buttons and deep links, the way a user would. Because it looks for the goal, a control that moved to the side edge on the open screen is still the control it's looking for.
Mobile tests run on cloud-hosted iOS Simulators and Android Emulators from a simulator build of your app. A mobile device preset sets the platform, device model, OS version, orientation and location, so the same test cases run across the models you care about without rewriting them. Native builds run on pull requests too: CI uploads the simulator build and pins the run to it, since an app has no preview URL.
For the Duo specifically. The test cases you write today are built to carry over: a goal like "complete checkout with a saved card" doesn't change because the layout went from one column to two. That's the design argument for goal-based test cases on a device that re-lays itself out when it folds; we haven't run it on a Duo yet. The Duo simulator exists in the Xcode 27.1 beta with controls to open, close, rotate or fold the device. Which models are available in the cloud is what the device-preset list shows; check it, or ask us, before you plan around Duo. What the simulator won't give you on any platform is hardware: camera, biometrics, NFC, multi-touch and pinch. Real devices are listed as coming soon.
For the website, web tests run in Chromium only, so nothing here is a Safari test and there's no hinge. What it does is the part most teams never get to: your real flows, at the three Duo widths, on every pull request, with no scripts to maintain. Create three device presets from the table above (device type mobile, touch on), add them to your PR test plan or pass one per run, and when a PR mentions mobile or responsive changes the agent can switch to a mobile preset on its own. It won't catch a 100vh bug or an ITP cookie failure; those need a WebKit session, and nothing in this article replaces one. What the agent removes is the chance that a desktop-only change quietly broke the checkout at Split View width and nobody looked.
Frequently asked questions
Does my website need to change for iPhone Duo? Probably not in code, but it needs checking at the three widths in the table above, which it has never run at. If a tablet breakpoint fires on the open screen and puts a sidebar on a phone, that's the change to make.
Can Safari detect when iPhone Duo is folded? Not as of launch. WebKit has no stated position on the CSS Viewport Segments or Device Posture APIs, and nothing in the Safari 27 feature list covers foldables. A page gets a resize event when the viewport changes and nothing about the hinge.
Can QA.tech test my native app on iPhone Duo? Yes, on cloud iOS Simulators from a simulator build, with device presets for model, OS version and orientation. The Duo simulator is in Apple's Xcode 27.1 beta; check the device-preset list or ask us for current Duo status. Goal-based test cases written for today's iPhones are designed to run unchanged.
Is there an iPhone Duo simulator? Yes, in the Xcode 27.1 beta, with controls to open, close, fold and rotate the device. Apple's release notes list slow first launches.
What is the iPhone Duo viewport size? Apple hasn't published one. From the pixel specs at 3x: about 466 by 678 CSS pixels closed and 626 by 890 open, with Split View at about half the width. Measure on a real device before relying on them.