iPhone Duo design

Help the user create one coherent app experience across the outer and inner displays, folding, rotation, and multitasking. Preserve the user's product purpose and visual direction.

This skill combines Apple's six launch Tech Talks, the September 16 and 17, 2026 Group Labs, and the Duo Human Interface Guidelines. It is an independent synthesis, not an Apple-authored skill. Read [sources](references/sources.md) for provenance and toolchain limitations.

Start with the task

Identify whether the user wants a new design, a review, or an implementation handoff. Read [design principles](references/principles.md) for the rules and exceptions. Read [review checks](references/review-checks.md) when auditing or validating. Use [example prompts](references/example-prompts.md) when the user needs a reusable brief.

Read the relevant sections of [Group Lab guidance](references/group-labs.md) for Q&A clarifications, migration choices, custom layouts, and testing advice. Its L-series IDs supplement the D-series principles; dated lab answers do not establish current SDK behavior.

Before proposing or reviewing a design, read Apple's current Designing for iPhone Duo Human Interface Guidelines alongside the local principles. Consult Dynamic layouts for resizing, continuity, reserved regions, and content arrangements; consult Vertical controls for hardware-relative placement, grouping, compression, and overflow. Follow the page's related guidance where it applies to the requested feature.

Use the live HIG to check this package's dated synthesis. If guidance differs, explain the relevant context or exception and prefer current Apple documentation for design decisions. If the page is unavailable, continue with the local references and identify which current guidance could not be verified.

Establish the app's primary task, navigation hierarchy, important actions, content types, and supported SDK. Infer routine choices from supplied designs or code; ask only when a missing decision materially changes the result. A static mockup, runnable prototype, and tested app provide different levels of evidence.

Decisions to preserve

• Adapt to available space and size classes. Use system geometry and reserved regions for layout; hinge-angle readings are for deliberate interactions or effects.
• Use system navigation and presentation behaviors as the baseline. Treat side bars as a space and reachability decision, including their documented exceptions.
• Keep ordinary interactive foreground content within the usable safe area and clear of active reserved regions. Handle asymmetric insets independently. Background artwork can extend farther; the references describe when custom immersive layouts can use additional space.
• Preserve the task and navigation context as the layout changes. Expose useful additional content on the inner display when the hierarchy supports it.
• Displace controls and bounded content around a fold when useful. Preserve continuous reading and scrolling; a fold is not a universal gutter through every layout.
• Plan overflow as part of the interface. Supply titles for symbol controls and retain access to every applicable action.
• Add camera accessories, multiple scenes, and hinge interactions only when they serve the requested app.

Generate a design

Describe the core flow, then show how the same flow behaves at compact and regular sizes, in a partially folded pose, and in a constrained multitasking region. Choose additional states based on the actual feature: a sheet, keyboard, long toolbar, camera preview, or second window.

Specify control placement, overflow order, content alignment, column behavior, and transitions. Explain exceptions with a concrete task benefit. For example, retain a cart total as meaningful text rather than turning it into an ambiguous symbol.

Use the checks to review the proposal before delivery. Mark proposed behavior as a design decision; reserve claims of successful runtime behavior for observed tests. Include actionable implementation notes only when requested or needed for the handoff.

Review a design

Inspect the supplied artifacts before prescribing changes. Report each material finding with its affected state, observed problem, consequence for the user, smallest useful fix, and rule/source reference. Use pass, fail, not tested, or not applicable. Missing screenshots or code are not evidence of a defect.

Prioritize blocked tasks, obscured controls, lost context, and inaccessible actions over visual refinements. The priorities and checks in this skill are an operational rubric derived from Apple guidance, not Apple certification criteria.

Evidence and implementation boundaries

Use stable rule IDs from the principles reference. Distinguish explicit Apple guidance, derived checks, and product-specific choices. Consult the linked Apple video passage when a rule's meaning or exception matters.

Verify API names, signatures, and availability against the target SDK before generating production code. The source inventory records what was available or announced when each session was recorded. A concept shown in a talk, lab answer, or HIG page does not prove the user's installed SDK supports it. Do not invent dimensions, angle thresholds, camera capabilities, or compiling API examples.

For physical comfort, folding behavior, and camera direction, identify what still needs device testing. A static review can assess a design proposal; it cannot certify those behaviors.