iPhone Duo app bugs: how to capture and report them

To report an app bug on iPhone Duo, capture the failing screen and write down how you reached it: which display you started on, whether you folded or rotated the phone, and what happened to the task you were doing. Include the app build and installed iOS version. If the problem happens during a transition, a short recording and the starting state are more useful than a screenshot of the aftermath alone.

Apple's first foldable iPhone reached customers on 23 October 2026. Its developer launch guidance points teams to Xcode 27.1 and Device Hub to inspect apps across poses and orientations. That gives QA teams a new set of conditions to record when an existing flow stops working.

What changes on iPhone Duo matter for app testing?

The Duo has inner and outer displays, can be used partially folded and supports two apps in Split View. Apple's design guidance describes layouts that adapt to the available space, with controls moving to the side in some configurations. It also calls for continuity as people move between displays.

Those changes give you useful places to look for failures. The checks below are suggested test scenarios, not a list of confirmed defects in the Duo or your app.

Try this in your app	Look for	Record with a failure
Start a form on the outer display, then open the phone	Lost text, changed selection or an unexpected navigation reset	Starting field, keyboard state and display transition
Rotate while a sheet or menu is open	A clipped dialog, covered action or unusable dismissal control	Orientation before and after, plus the open sheet
Partially fold the inner display during a task	Text or a control that becomes hard to see or tap	How the device was held and which control was affected
Use the app beside another app in Split View	Content or actions that stop fitting in the app's space	Which side your app occupied and how much space it had
Open the keyboard near the end of a form	A submit button you cannot reach or a field you cannot see	Focused field, text size and whether scrolling helps
Open an in-app camera or scanner, then change orientation	A preview or result that no longer matches the task	Camera used, orientation and the saved result, if relevant

Choose flows your customers rely on: sign-in, checkout, composing a message or uploading a photo. A failure that prevents finishing one of those tasks gives developers a clear place to start.

How do you tell a bug from an unfamiliar layout?

Check whether the action still exists before reporting it as missing. Apple's Design for iPhone Duo session explains how controls, sheets and content adapt as the available space changes. A button moving doesn't by itself establish a defect.

For example, look in the overflow menu when a toolbar action disappears. If you can still save the form there, record a discoverability concern if appropriate. If neither the visible toolbar nor the menu offers a working save action, report that blocked task.

Early coverage also needs a date and an app version. A 24 October hands-on review described older apps appearing with large black bars. That observation doesn't establish that every unused area is a bug or that a particular app still behaves that way after an update. Show what your installed build does and explain the practical effect: is content merely narrower, or is a required control cut off?

Avoid guessing the cause in the title. “Checkout loses the delivery note when opening the phone” is something an engineer can investigate. “Duo breaks our state management” assumes an explanation you haven't established yet.

How should you capture the evidence?

When should you take screenshots?

Use screenshots for a stable layout failure. Keep enough of the screen to show the app's position and surrounding controls. Mark the affected area on a copy, keeping the original available to the team.

Apple's screenshot instructions use a quick press and release of the side and volume-up buttons together. Capture the starting layout as well as the failed result when the difference helps explain the bug.

Write “outer display, keyboard open” or “inner display, landscape, app on the left” beside the image. A screenshot doesn't tell the developer which physical pose produced it.

When should you record the screen or film the phone?

For a flicker, reset or sequence of misplaced controls, start recording before the failing action. Open Control Centre, tap Screen Recording, wait for the countdown and return to the app. Apple's recording guide explains how to add the control if it isn't present. Some apps restrict recording.

Play back the saved clip before sending it. Check that it includes the transition and the failed result; don't assume a recording continues across every display change. If the clip stops or the physical movement explains the failure, film the phone with a second device. Separate before and after screenshots are still useful when you can't record the whole sequence.

Say when you opened Control Centre or a reporting sheet. If leaving the app changes the symptom, that is part of the reproduction sequence. Keep the clip focused on one attempt, use test data and review notifications, the neighbouring app and any audio before sharing it.

What should you send to your developers?

Use one report per distinct failure. Copy this into your team's issue tracker or reporting form:

Summary: [task] fails after [display, fold or rotation action]
App version and build:
Installed iOS version:
Device: iPhone Duo [physical device / simulated configuration]
Starting display and orientation:
Starting pose: [closed / fully open / partially folded; describe it]
App space: [full screen / Split View, side and approximate share]
Starting state: [screen, test account role, relevant saved data]
Keyboard, text size and relevant settings:

Steps:
1.
2.
3.

Expected result:
Actual result and task blocked:
Frequency: [observed failures / attempts, or unknown]
Recovery: [what restores the flow, if known]
Evidence: [before image / after image / clip and useful timestamp]
Comparison: [result without the transition, or on another device]

For a fictional checkout example, a useful summary would be: “Delivery note disappears after opening Duo from the outer display.” The steps would identify the focused field, the unsaved text and the moment the phone opened. The expected result would be that the text remains; the actual result would describe the empty field. A comparison run that stays on the outer display would help narrow the investigation without claiming a root cause.

Don't replace an unknown result with an assumption. “Failed once; not retried yet” is useful. “Affects all Duo users” needs evidence a single test cannot provide. The good bug report guide covers the general fields, while the device test matrix helps assign these checks across a release.

Where does BugScreen fit in a Duo testing round?

For apps using BugScreen's iOS SDK, reports include device, OS and app-version/build context. The collected-data guide describes those fields. Add the display, pose and transition to the description yourself: device metadata doesn't describe the sequence that exposed a layout failure.

Before relying on your installed SDK version for a Duo test round, open the reporter from each display and send a sample screenshot through to your team. The companion app offers a separate reporting route, but it cannot read the tested app's logs or build metadata; supply that app's build yourself.

Send the evidence through the route your team has agreed. For TestFlight builds, the TestFlight feedback guide explains Apple's native route. If your team wants to try BugScreen for its QA intake, create a workspace and run a sample report through to the person who will investigate it.