iPhone Duo UI Testing Checklist: From Adaptive Layout to Store Screenshots
A valid PNG size proves one part of an asset pipeline. It does not prove that the app preserves a draft, keeps controls reachable, or displays the right content after a fold. Use this practical checklist to connect UI verification with the screenshots you plan to publish. The test matrix below is our recommended workflow, not an additional Apple submission requirement.
Define one repeatable task before testing poses
Start with a task that matters to the app: opening a saved item, editing a draft, completing a practice session, or inspecting a document. Record the build, test account, language, sample data, and selected item. Then repeat the same task through the states you intend to support.
This makes failures easier to compare. “The selected document changes after opening the device” is actionable; “the wide screen feels wrong” is not. Keep a short recording for state-transition failures and a still image for final-layout failures. They answer different questions.
Use a focused display and orientation matrix
Cover both displays in supported orientations, then include partial folding and resizing for the important workflows. Apple’s preparation and layout sessions explain why the app may have different available regions as the device and window change. The table below is a starting point; add cases for the actual controls and content in your app.
| State | What to inspect | Evidence |
|---|---|---|
| Outer, portrait | Focused task and access to primary actions | Screenshot + task result |
| Outer, landscape | Overflow and readable labels | Screenshot |
| Inner, portrait | Hierarchy and use of additional space | Screenshot |
| Inner, landscape | Related content and side controls | Screenshot |
| Partially folded | Critical content near the center | Short recording |
| Window resized / Split View | State, controls, and minimum usable layout | Short recording |
Check continuity with content you can recognize
Use a recognizable item title and a small unsaved edit. Move from outer to inner, rotate, and return. Verify the selected item, navigation position, draft text, and active tool each time. For media or timed tasks, verify the behavior your app promises through the transition.
Avoid fixing a screenshot by reopening the app into a favorable state while leaving the underlying transition broken. Reproduce the failure from the recorded start state, fix the cause, and rerun the same sequence. Store the passing sequence with your release notes so a later build can repeat it.
- Selected content remains identifiable.
- Unsaved changes remain intact.
- Back and close actions still lead to the expected state.
- The primary action remains reachable, including through overflow.
- The interface does not briefly expose private or debug content.
Inspect custom UI, larger text, and translated labels
Prioritize the parts the system cannot arrange for you: custom navigation chrome, canvas controls, charts, and overlays. Apple’s reserved-region guidance explains how the fold and cameras affect space; use the current layout environment rather than a guessed constant for a camera or hinge.
Repeat the most demanding state with larger text and the longest supported labels. Look for truncated commands, controls moved away from the content they affect, and dialogs whose completion action becomes hard to find. A screenshot with normal English text is not evidence for every localization. Check the locales you intend to ship.
Capture real UI after the flow passes
Use separate capture folders for outer and inner displays. Keep the same sample item when comparing layouts, but capture each display independently. Remove debug overlays and private account data, let animations settle, and preserve a clean original before adding marketing copy.
In App Asset Kit, select iPhone Duo, the display, and the orientation that matches those captures. Inspect the preview for accidental cropping. A panorama layout creates multiple output tiles from one scene, so review the export order as well as the number of inputs.
Deliver evidence, editable sources, and an explicit status
A useful handoff contains the build identifier, capture matrix, original images, approved captions, editable design project, and exported files. Add a brief note about which flows passed and which states are still excluded. This lets a reviewer check the claim behind a screenshot without rebuilding your whole process.
Separate local readiness from upload readiness. As of September 11, 2026, Apple says dedicated Duo asset upload support is coming later this year. Mark the package “prepared for the published dimensions” until the actual submission path is available and verified.
App Store Connect release notes ↗
| Layer | Pass condition |
|---|---|
| App | Named workflow passes through the target states |
| Source | Genuine display, locale, and build are recorded |
| Copy | Every claim is visible or demonstrable in the build |
| Export | Exact pixels; no alpha; readable full-size output |
| Submission | Current Duo upload availability checked separately |
Frequently asked questions
Does passing screenshot validation prove Duo compatibility?
No. File checks cover dimensions and encoding. App compatibility also requires testing layout, interactions, state, and transitions.
Must every test case become a store screenshot?
No. QA evidence can cover many more states than the final marketing set. Publish only useful, accurate product evidence.
Should I capture outer and inner screenshots separately?
Yes. Use each display’s genuine adapted interface and maintain a separate source set for each.
What should I do if a Duo simulator is unavailable?
Review the layout with the tools available and document the gap. Do not label a resized screenshot as a verified Duo device capture. Complete device or simulator verification when available.