TLDR
Apple's iPhone Duo adds an inner display, an outer display, side-positioned controls, and Split View, so a user can gain or lose screen space in the middle of a task. Your iOS app testing needs to cover layout transitions, state survival, and Safari viewport behavior, not just a successful launch.
This guide covers what you can test before the simulator ships, a minimum iPhone Duo test matrix for native iOS and mobile web, and how to turn test runs into release evidence.
Apple’s new iPhone Duo introduces a different set of iOS app testing considerations for mobile teams. With inner and outer displays, side-positioned controls, and Split View support, an app can move between very different layouts while the user is in the middle of a task.
That means “the app launches successfully” is not enough. Your app needs to keep its layout, controls, and user state intact as the available screen space changes.
What changes with iPhone Duo app testing?
Apple’s iPhone Duo announcement highlights several new interaction patterns: an inner display, an outer display, controls that can shift to the side of the device, and Split View for using apps next to each other.
For testers, the important implication is simple: a user may have less space available even when the device is open.
For native apps, Apple’s developer guidance calls out several assumptions that teams should revisit:
- Layout logic based only on device orientation
- References to one “main” screen
- Safe-area calculations that assume opposite edges have matching insets
- Cached screen dimensions and hard-coded edge spacing
Instead, Apple recommends using size classes and the geometry of the current scene. In other words, your app should respond to the space it has now, not to an assumed phone shape.
It is also worth separating compatibility from optimization. Apple says existing apps can run without being recompiled, but apps built with newer SDKs may use the available display differently. When testing, record the SDK used to build the app separately from its minimum deployment target and the iOS version used at runtime.
Is there an iPhone Duo simulator yet?
Not yet. Apple’s iPhone Duo developer hub has announced an Xcode 27.1 beta with iPhone Duo support. Apple’s Prepare your app for iPhone Duo tech talk shows the coming simulator in Device Hub, with on-screen controls to open, close, rotate, and fold the device.
A description of upcoming tooling is not evidence that it is already available. Use the current availability status to plan your work realistically. We will update this section when the beta ships.
What can you test now?
The key is to start preparing now. A missing simulator should delay device-specific sign-off, not the work of defining risks, creating test cases, or strengthening your existing regression suite.
If a configuration is unavailable, mark it as not run, not passed.
Native iOS: test transitions, not just screens
Record your starting point
For every build, record:
- App version and build number
- Build SDK
- Minimum deployment target
- Runtime iOS version
- Simulator or physical device
- Whether the app supports multiple scenes or windows
- Journeys that rely on custom navigation, camera views, or full-screen content
Start with a small set of critical journeys rather than taking screenshots of every screen. A checkout flow that loses a delivery address after a display change matters far more than a minor spacing inconsistency on a decorative page.
Review layout assumptions before the simulator arrives
Ask the iOS team to review code that depends on orientation, cached screen dimensions, or fixed edge padding. Apple’s layout guidance explains why current scene geometry and size classes are more reliable inputs than a presumed device shape.
This review gives QA a more targeted set of behaviors to test. For example:
- Does a selected detail panel disappear after the layout changes?
- Does a toolbar move somewhere users cannot reach?
- Does a popover remain anchored to the correct control?
- Does a modal still fit within its active scene?
Change the layout mid-journey
Once supported tooling is available, test the same journey on the outer display, inner display, and in Split View. Change the device pose or available space while the user is actively completing a task.
Do not only change layouts from the home screen. Put the app into meaningful states first:
- Keep a selected record open
- Leave a form partially completed
- Trigger a validation error
- Open a dialog or menu
- Start a checkout or submission flow
Then change the available space and continue the journey.
Check the business outcome as well as the interface. The right record should still be selected, draft data should remain intact, and one submission should create one intended result.
For apps that adapt to partially folded positions, review Apple’s adaptive-layout guidance. It covers reserved regions and arrangement APIs. Avoid inventing a fixed “hinge area” in your tests or assuming that every app needs to calculate layouts from raw device angles.
Mobile web: test Safari separately
Native iOS size classes and scene APIs do not apply to websites. If your company offers both a native app and a mobile web experience, each needs its own testing strategy.
Start with your current responsive breakpoints. Test just above and below each one, particularly while a menu, dialog, or form is open. Where your product requires it, make sure the current route and unsaved draft data survive resizing.
Thunders’ responsive testing guide covers the broader foundation for testing layouts across mobile, desktop, and browsers.
Pay special attention to fixed controls and the on-screen keyboard. As MDN explains, the visual viewport can shrink when a keyboard opens or when a user zooms, without the layout viewport changing in the same way.
That means a button positioned at the bottom of the page is not always visible at the bottom of the screen.
If your design uses CSS safe-area variables, handle each edge independently and include sensible fallbacks. MDN’s CSS env() reference documents these variables. But their existence does not confirm that Safari on iPhone Duo exposes a particular hinge, posture, or viewport-segment API.
Desktop resizing is still useful preparation. But complete your device-specific pass in the real Safari environment once it is available. Record the iOS version and observed viewport dimensions instead of copying hardware pixel dimensions into a browser preset.
A minimum iPhone Duo test matrix
Use this as a starting point, then add risks that are specific to your product. Duo-specific actions depend on access to Apple’s supported simulator or physical hardware.
For stateful journeys, verify the saved data or backend result, not only the confirmation message. A success toast can still hide a duplicate submission or incomplete update.
Turn test runs into release evidence
For every failure, capture:
- Starting configuration
- Transition or pose change
- App build and SDK
- Runtime OS
- Expected outcome
- Actual outcome
- Screenshot or recording
A screenshot of the broken end state is useful. A recording that shows how the issue happened is usually far more valuable for transition-related defects.
Keep your existing-device regression coverage, too. An improvement for the expanded display must not remove a critical control from the smaller one.
Repeatable business flows are strong candidates for an end-to-end regression suite that runs on every release, not as a one-off pass. Device-dependent gestures, display transitions, and usability checks still need an environment that explicitly supports them.
Before release, agree on which failures are blockers. Lost user data, incorrect transactions, and inaccessible critical actions should take priority over cosmetic differences. If a configuration remains unavailable, document the gap and name the person accepting that release risk.
Automation can make testing more repeatable. It cannot turn an untested environment into evidence.
Where Thunders fits in
You do not have to wait for new hardware to start. Thunders tests web, mobile, API, and desktop applications from one platform, including iOS and Android apps on real devices and emulators. You describe the journey in plain language, and Thunders generates the test, runs it, and keeps it working as your UI changes.
That makes the preparation work in this guide immediately useful:
- Automate your existing iOS, Android, and responsive web checks now, so you have a reliable baseline before Duo testing begins
- Move from one-off testing to continuous testing, running your critical journeys on every release so a fix for one device never silently breaks another
- Extend the same suite to iPhone Duo configurations as support becomes available, instead of rebuilding your test strategy every time hardware changes
Quality is not a single pass before launch. The teams that ship with confidence are the ones testing continuously, on every build, across every environment their users actually have.
Create a free Thunders account to start automating your current checks today, or book a demo and our team will walk you through the setup, the environments we cover, and the next steps for iPhone Duo.
