Help the existing app work across changing containers, then adopt device capabilities where the requested experience benefits. Preserve the app's framework, architecture, minimum OS support, and feature scope unless the user asks to change them.
Establish the evidence boundary
Read support and migration before making availability or compatibility claims. This skill records research from 2026-09-15, including announced iOS 27.1 features whose reference pages and SDK were not available for validation in that research environment.
- Distinguish build SDK, deployment target, runtime version, and hardware capability.
- Prefer current Apple declarations and release notes for exact availability; use Apple HIG for design intent and sessions for announced behavior.
- If Cupertino MCP is available, search and read its documents. Missing search results can mean a stale index: use the official source links rather than guessing or declaring the API nonexistent.
- Confirm exact declarations before emitting new-API implementation code. An
if #availablecondition cannot make an unknown symbol compile against an older SDK. - Without a suitable SDK/runtime, implement verified adaptive improvements and report the remaining device-specific validation separately.
Choose the relevant references
| Task | Read |
|---|---|
| Audit, compatibility, migration plan | Support and migration |
| Layout/design review or HIG questions | Human Interface Guidelines |
| SwiftUI implementation | SwiftUI |
| UIKit or hosting-controller implementation | UIKit |
| Stack/split/tab navigation, routes, presentations | Navigation |
| System/custom bars, overflow, vertical controls | Toolbars |
| Reserved regions, arrangements, hinge, multi-scene/camera experiences | Duo capabilities |
| Test plan or verification of changes | Testing |
| Source refresh, unsupported claims, provenance | Sources |
Read only the applicable modules; mixed-framework work usually needs both framework references and the relevant topic reference.
Work from the app's actual constraints
- Inspect targets, selected Xcode/SDK, deployment versions, scene configuration, navigation owners, and existing tests. Identify the screen and behavior requested before proposing a broad migration.
- Trace layout decisions based on device identity, global screens, orientation, or fixed dimensions. Determine whether each decision actually concerns available space, content readability, or a physical interaction.
- Prefer the appropriate system container. Preserve selection, routes, drafts, and long-lived work while changing presentation. Do not replace every single-screen flow with a split view.
- Make the smallest relevant change. Ordinary layout can usually improve without hinge APIs; conversely, a specifically requested hinge feature need not trigger an unrelated whole-app rewrite.
- Verify supported configurations with the existing test infrastructure. Separate compilation, simulated resizing, and real Duo behavior in the report.
Review invariants
- Available container geometry is not the physical screen size. A regular size class is not proof of a particular device or fold state.
- Safe-area insets are independent on each edge. Extending artwork under system chrome does not authorize obscuring interactive content.
- Application state must not depend on whether a column is currently visible. Shared domain data and per-scene navigation state have different lifetimes.
- A system-provided navigation bar belongs to its container. Do not manufacture duplicate bars or navigation stacks to imitate another presentation.
- Announced capability does not imply availability on every device, scene, SDK, or OS version.
For reviews, report actionable findings with file locations, the failing configuration, evidence, a proposed correction, and a verification step. For implementation, summarize changes, fallback behavior, checks actually run, and unresolved limitations. Do not claim support for configurations you could not test.