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
| Request |
Read and produce |
| Design review, layout, bars, fold handling |
Layout and controls; findings tied to affected flows |
| Lost state, multiple windows, simultaneous displays, camera |
Continuity, scenes, and camera; ownership and lifecycle plan |
| Implementation with an older SDK or deployment target |
Versions and sources; verified API gate and fallback |
| Readiness audit or release evidence |
Verification; completed report template |
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
- Follow one real task through the affected screens. Record where navigation,
edits, selection, media, and presentation state live before changing layout.
- 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.
- Prefer system navigation and presentations when they fit the app. Audit
custom controls and content that sits in the center or near an edge.
- 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.
- 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.
- 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.
1---2name: iphone-duo-design3description: Use when designing, adapting, implementing, or auditing an iOS app for iPhone Duo, including resizing, folding, vertical bars, reserved regions, state continuity, multiple scenes, camera behavior, and accessibility. Produce evidence-based readiness findings with SDK gates and fallbacks. Do not use for generic iPhone work without Duo or adaptive-layout requirements, Android foldables, Microsoft Surface Duo, Google Duo, or claims of Apple certification.4---56# iPhone Duo design and readiness78Help an app keep its identity and functionality while its usable space changes.9This skill works with any coding assistant that can read Markdown. Shell,10browser, Xcode, and simulator tools are optional capabilities, not host-specific11dependencies. When a tool is unavailable, provide the exact remaining check12and keep its result unverified.1314## Establish the target1516Before changing code, inspect the app's deployment targets, Swift language mode,17selected Xcode/SDK, UI framework, scene configuration, and principal user flows.18For design-only work, record any unknowns instead of choosing a deployment target19for the user. Preserve existing platform support unless the user requests a change.2021Read [versions and sources](references/versions-and-sources.md) before proposing22Duo-specific symbols. Refresh the official sources when implementation depends23on their current availability. The source snapshot is dated September 17, 2026;24it is not a claim about the SDK available in a future session.2526Keep three evidence categories separate:2728- Apple documentation or SDK declarations establish API contracts.29- This skill's engineering recommendations guide implementation and testing.30- A build, preview, simulator run, or device run proves only what it exercised.3132A request for "Duo compliant" means a review against documented design guidance33and the app's requirements. Do not issue an Apple certification, guarantee App34Review approval, or call an untested app fully ready.3536## Choose the work3738| Request | Read and produce |39| --- | --- |40| Design review, layout, bars, fold handling | [Layout and controls](references/layout-and-controls.md); findings tied to affected flows |41| Lost state, multiple windows, simultaneous displays, camera | [Continuity, scenes, and camera](references/continuity-scenes-camera.md); ownership and lifecycle plan |42| Implementation with an older SDK or deployment target | [Versions and sources](references/versions-and-sources.md); verified API gate and fallback |43| Readiness audit or release evidence | [Verification](references/verification.md); completed [report template](references/readiness-report.md) |4445For a narrow task, load only its references. The [adaptive editor example](examples/AdaptiveEditor.swift)46uses established APIs and shared edit state. It does not implement new Duo APIs47or prove behavior on Duo hardware.4849## Work in this order50511. Follow one real task through the affected screens. Record where navigation,52 edits, selection, media, and presentation state live before changing layout.532. Fix container sizing and state ownership first. Use environment traits and54 local view or scene geometry. Do not select a layout from a device-name55 string, global screen bounds, or a guessed hinge angle.563. Prefer system navigation and presentations when they fit the app. Audit57 custom controls and content that sits in the center or near an edge.584. Add Duo-specific APIs only where they improve an identified flow. Verify59 their complete signatures and platform availability in official docs and60 the selected SDK. A runtime availability check does not make an unknown61 symbol compile with an older SDK.625. Keep a usable fallback. Explain both build-time exclusion for older SDKs63 and runtime availability for older OS versions; retain the app's existing64 navigation and task access in the fallback.656. Exercise transitions during active work, then check final layouts. Use the66 verification matrix appropriate to the changed flow rather than collecting67 unrelated screenshots.6869## Review rules that catch real defects7071- Keep task state above layout alternatives. A resize must not create a second72 draft, restart capture, repeat a purchase, or discard a navigation path.73- Treat each scene's navigation and presentation state independently. Shared74 documents need an explicit conflict policy, not a global "current window".75- Keep every action reachable when controls overflow, a keyboard appears, or76 the layout collapses. Test the escape route from every modal presentation.77- Give controls useful names in accessibility and overflow presentations.78 Check reading order and focus after movement, not just at launch.79- Use hardware or SDK capability checks for optional features. A regular size80 class does not identify a particular device or prove accessory availability.81- For games, web views, or custom rendering engines, apply the same geometry,82 input, and state checks at the native host boundary. Do not invent framework83 plugins, browser fold APIs, physical dimensions, or review requirements.8485## Deliver the result8687For code changes, report the changed behavior, minimum versions, fallback,88tests performed, and remaining evidence gaps. For an audit, rank actionable89findings by user impact and attach a source or reproduction to each finding.90Use `verified`, `failed`, `blocked`, or `not applicable` per matrix row.9192Keep unavailable SDK/device checks explicit while completing useful current-SDK93work. Recommend additional features only when they serve the app's actual tasks.94Do not add camera access, a second display experience, or sensor tracking merely95because the device supports it.
fal3