iPhone Duo design and readiness

Help an app keep its identity and functionality while its usable space changes. This skill works with any coding assistant that can read Markdown. Shell, browser, Xcode, and simulator tools are optional capabilities, not host-specific dependencies. When a tool is unavailable, provide the exact remaining check and keep its result unverified.

Establish the target

Before changing code, inspect the app's deployment targets, Swift language mode, selected Xcode/SDK, UI framework, scene configuration, and principal user flows. For design-only work, record any unknowns instead of choosing a deployment target for the user. Preserve existing platform support unless the user requests a change.

Read versions and sources before proposing Duo-specific symbols. Refresh the official sources when implementation depends on their current availability. The source snapshot is dated September 17, 2026; it is not a claim about the SDK available in a future session.

Keep three evidence categories separate:

• Apple documentation or SDK declarations establish API contracts.
• This skill's engineering recommendations guide implementation and testing.
• A build, preview, simulator run, or device run proves only what it exercised.

A request for "Duo compliant" means a review against documented design guidance and the app's requirements. Do not issue an Apple certification, guarantee App Review approval, or call an untested app fully ready.

Choose the work

For a narrow task, load only its references. The adaptive editor example uses established APIs and shared edit state. It does not implement new Duo APIs or prove behavior on Duo hardware.

Work in this order

1. Follow one real task through the affected screens. Record where navigation, edits, selection, media, and presentation state live before changing layout.
2. Fix container sizing and state ownership first. Use environment traits and local view or scene geometry. Do not select a layout from a device-name string, global screen bounds, or a guessed hinge angle.
3. Prefer system navigation and presentations when they fit the app. Audit custom controls and content that sits in the center or near an edge.
4. Add Duo-specific APIs only where they improve an identified flow. Verify their complete signatures and platform availability in official docs and the selected SDK. A runtime availability check does not make an unknown symbol compile with an older SDK.
5. Keep a usable fallback. Explain both build-time exclusion for older SDKs and runtime availability for older OS versions; retain the app's existing navigation and task access in the fallback.
6. Exercise transitions during active work, then check final layouts. Use the verification matrix appropriate to the changed flow rather than collecting unrelated screenshots.

Review rules that catch real defects

• Keep task state above layout alternatives. A resize must not create a second draft, restart capture, repeat a purchase, or discard a navigation path.
• Treat each scene's navigation and presentation state independently. Shared documents need an explicit conflict policy, not a global "current window".
• Keep every action reachable when controls overflow, a keyboard appears, or the layout collapses. Test the escape route from every modal presentation.
• Give controls useful names in accessibility and overflow presentations. Check reading order and focus after movement, not just at launch.
• Use hardware or SDK capability checks for optional features. A regular size class does not identify a particular device or prove accessory availability.
• For games, web views, or custom rendering engines, apply the same geometry, input, and state checks at the native host boundary. Do not invent framework plugins, browser fold APIs, physical dimensions, or review requirements.

Deliver the result

For code changes, report the changed behavior, minimum versions, fallback, tests performed, and remaining evidence gaps. For an audit, rank actionable findings by user impact and attach a source or reproduction to each finding. Use verified, failed, blocked, or not applicable per matrix row.

Keep unavailable SDK/device checks explicit while completing useful current-SDK work. Recommend additional features only when they serve the app's actual tasks. Do not add camera access, a second display experience, or sensor tracking merely because the device supports it.