Apple Native UI

Build and review interfaces that feel native because they use the platform's interaction, accessibility, and adaptation contracts—not because they imitate a screenshot.

Start with the target

Identify the platforms, minimum OS versions, SwiftUI versus UIKit/AppKit boundary, supported input (touch, pointer, keyboard, VoiceOver, Digital Crown, remote, eye/hand), and primary form factors. Do not apply an iPhone convention to macOS, iPad multitasking, watchOS, tvOS, or visionOS without evidence that it transfers.

Prefer system controls, semantic colors, text styles, safe-area APIs, navigation containers, and presentation APIs before custom reconstructions. Custom UI must retain the equivalent accessibility, focus, state, and cancellation behaviour.

Fresh platform guidance

Before prescribing or implementing APIs, behaviour, design conventions, or verification that may vary by SDK or OS release, search current primary Apple sources: Apple Developer Documentation, Human Interface Guidelines, and relevant WWDC sessions. Check the project's deployment target before recommending a newer API, and distinguish current Apple guidance from repository-local compatibility constraints. The examples here express durable contracts; they are not a substitute for release-specific documentation.

macOS workflow

When macOS is an intended target, read references/macos-native-workflows.md before planning, building, porting, or reviewing a non-trivial interface. It adds a Mac-specific workflow for commands, windows and documents, selection and focus, pasteboard and drag/drop, undo, state restoration, configuration, Finder interoperability, and behaviour-led verification.

Treat a Mac version as a distinct workflow even when it shares models or views with iPadOS. A resizable iPad layout is not by itself a complete Mac app.