Preparing your app for iPhone Duo: layouts, state and purchase flows

A useful iPhone Duo review starts in the middle of a task. Select a subscription plan, open the device, rotate it and return to the purchase screen. Is the same plan still selected? Can you read the full billing amount? Does the app still know whether a purchase is waiting, canceled or complete?

Those questions connect the new form factor to the work that matters for an app business: helping people finish what they started. This checklist is for product, design and engineering teams preparing an existing iPhone app. It is based on Apple's materials available on October 3, 2026, and proposes tests to run in your own app; it does not claim results from hands-on device testing.

Establish the release and tooling baseline

Apple announced iPhone Duo on September 9, with pre-orders starting October 16 and availability beginning October 23 in its first launch markets, including the US and UK. The device has an outer display and a larger folding inner display, and ships with iOS 27.1. On this article's publication date, the consumer launch is still ahead. Apple's announcement.

Apple's developer hub currently points to Xcode 27.1 beta, design resources, workshops and preparation sessions. Record the exact Xcode, SDK and OS build used in your review, and revisit the release notes before submission. Keep simulator findings separate from any later hardware verification. Get ready for iPhone Duo.

Start with a short readiness record:

• Which app build and dependencies are under test?
• Which screens contain custom navigation, fixed dimensions or embedded SDK interfaces?
• Which tasks must work before the team considers the release ready?
• Who owns a failure in each task, including a problem inside a third-party component?

For a subscription app, a sensible first pass is onboarding, the core paid feature, the offer screen, purchase restoration and account management. Add a representative free-user journey so that subscription testing does not hide problems elsewhere.

Adapt to the available space

Apple's preparation session distinguishes compatibility from using the full display: building with the iOS 27.1 SDK enables the full-screen experience. It recommends size classes and local scene geometry, and warns against assumptions based on a single main screen. Safe-area insets can be asymmetric. Prepare your app for iPhone Duo.

Turn that guidance into a focused audit. Look for a fixed-width offer card, a footer positioned using a cached screen height, or a custom control that assumes equal left and right insets. These are inspection targets, not proof that a particular app is broken.

For each layout, define what must remain visible and what may scroll. A subscription comparison can use extra room to make differences easier to scan, while still allowing the same decision in a narrower window. Do not make an essential action available only in the expanded layout.

Apple's design session describes compact and regular layouts, partial-fold arrangements and side-by-side app use. It also advises keeping functionality consistent across poses. Use those configurations to challenge the design rather than drawing an unrelated interface for every device position. Design for iPhone Duo.

Recheck navigation and custom controls

Controls may move between horizontal and vertical arrangements. Apple's bar guidance covers the shared space used by app and system controls, custom view adaptation and overflow behavior. A custom toolbar needs deliberate review even if the main content already resizes. Raise the bar with iPhone Duo.

Try to complete a task with the least convenient combination of content and space. Use a long product name, a translated action label and a visible keyboard. Open the overflow menu, dismiss a sheet and navigate back. Confirm that the selected item remains understandable throughout.

Write failures as observable behavior: “The restore action cannot be reached with the keyboard visible” is actionable. “The small layout feels crowded” needs a reproducible example before an engineer can fix it.

Preserve the task across transitions

A layout change should not unexpectedly restart onboarding, discard an edit or replace a selected plan. Define the expected continuity explicitly, including what happens when the app moves into the background during the transition.

Apple distinguishes hinge data for interactions from layout APIs. Its multiple-display session also explains that the availability of new scenes changes with the display in use. If your app supports multiple scenes, test scene creation and failure handling as well as visual resizing. Multiple displays and scenes on iPhone Duo.

Use this matrix as a starting point. These are proposed acceptance criteria for your product, not reported device benchmarks.

Keep business state independent of a particular arrangement of views. During review, pay special attention to code that starts work when a screen appears: reconstructing a view must not accidentally repeat a payment request or submit a form again.

Verify purchase outcomes separately from presentation

StoreKit distinguishes a successful purchase result, a pending result and a user-canceled purchase. A successful result includes transaction verification information. Pending purchases that later succeed are delivered through transaction updates. These states should drive the app's outcome handling. A sheet disappearing or the app returning to the foreground is not sufficient evidence of payment. StoreKit purchase results and pending purchases.

Use StoreKit testing to exercise transaction scenarios instead of relying on repeated happy-path purchases. Apple provides local testing and automation through StoreKit Test, including subscription and Ask to Buy scenarios. StoreKit Test.

For your own review, include cancellation of the purchase sheet, pending approval, a later successful update, restoration and a failed request. Combine these with the layout transitions above. Check both the displayed message and access to the paid feature. Keep canceling a purchase distinct from canceling an existing subscription.

The offer itself should remain understandable in every layout. Our subscription UX checklist covers price, consent and cancellation in more depth. Here, the additional question is whether resizing changes the information or action available to the user.

Include accessibility and store presentation

Apple's Accessibility Inspector supports testing system accessibility settings, including text and contrast-related behavior. Use it alongside manual interaction testing. Testing system accessibility features.

In each important layout, increase text size and traverse the interface with VoiceOver. Check that a visual rearrangement still has a sensible reading order, a named purchase action and reachable error messages. Repeat critical tasks with the supported locales most likely to expose longer labels. These checks should describe what a person can accomplish, not just whether the screen looks balanced.

Before preparing store assets, consult Apple's current screenshot specification, which includes separate dimensions for the iPhone Duo inner and outer displays. Capture the app at the required sizes rather than stretching an older phone screenshot. App Store Connect screenshot specifications.

Decide what to ship and what to measure

Separate release blockers from optional enhancements. Lost form data, an unreachable action or incorrect purchase confirmation blocks the affected journey. A richer expanded layout can follow once those journeys work reliably.

Measure confirmed outcomes separately from attempts. A resize that reconstructs a screen should not create another purchase conversion. Use fixed categories for layout and outcome analysis; keep user-entered text, payment details and transaction identifiers out of general analytics. Record how duplicate events are prevented in your own implementation.

AppCradle's RevenueCat reporting guide explains the imported subscription metrics available for business review. Those reports provide context; they do not establish which device transition caused a problem. Pair them with your app's QA evidence and supported diagnostics.

If you change the offer presentation after fixing compatibility, document the hypothesis and guardrails using the monetization experiment planning guide. Keep the release date, tested configurations and unresolved limitations in the team's review notes. The useful outcome is a task that remains understandable and complete as the available space changes.