sickn33/antigravity-awesome-skills/hig-patterns

Apple HIG: Interaction Patterns

Read .claude/apple-design-context.md if the project provides it; treat it as project context, not a required global configuration. Ask only for missing platform, task and user constraints.

Key Principles

1. Minimize modality. Use modality only when it is critical to get attention, a task must be completed or abandoned, or saving changes is essential. Prefer non-modal alternatives.

1. Provide clear feedback. Important state changes need perceivable feedback; combine accessible visual/status text with optional sound or haptics, without announcing every incidental interaction. Activity indicators for indeterminate waits, progress bars for determinate, haptics for physical confirmation.

1. Support undo over confirmation dialogs. Destructive actions should be reversible when possible. Prefer undo when an action is genuinely reversible. Irreversible deletion, payments or external sharing may still need clear scope and confirmation.

1. Launch quickly. Display a launch screen that transitions seamlessly into the first screen. Avoid branding-only launch screens; a brief optional splash after launch can be appropriate if it does not obstruct the task. Restore previous state.

1. Defer sign-in. Let users explore before requiring account creation. Support Sign in with Apple and passkeys.

1. Keep onboarding brief. Keep the flow as short as the task permits; three screens is a heuristic, not an Apple requirement. Let users skip. Teach through progressive disclosure and contextual hints.

1. Use progressive disclosure. Show essentials first, let users drill into details. Don't overwhelm with every option on one screen.

1. Respect user attention. Consolidate notifications, minimize interruptions, give users control over alerts. Marketing notifications require explicit opt-in and an easy opt-out; never mark them Time Sensitive.

Reference Index

Pattern Selection Guide

Output Format

1. Recommended pattern with rationale, citing the relevant reference file.
2. Step-by-step implementation covering each screen or state.
3. Platform variations for targeted platforms.
4. Common pitfalls that violate HIG for this pattern.

Questions to Ask

1. Where in the app does this pattern appear? What comes before and after?
2. Which platforms?
3. Designing from scratch or improving an existing flow?
4. Does this involve sensitive actions? (Destructive operations, payments, permissions)

Related Skills

• hig-foundations -- Accessibility, color, typography, and privacy principles underlying every pattern
• hig-platforms -- Platform-specific pattern implementations
• hig-components-layout -- Structural components (tab bars, sidebars, split views) for navigation patterns
• hig-components-content -- Content display within patterns (charts, collections, search results)

Built by [Raintree Technology](https://raintree.technology) · [More developer tools](https://raintree.technology)

When to Use

Use to design or review Apple interaction flows such as onboarding, data entry, document handling, search, media playback, account management or undo. Choose the target platform and OS release before applying a reference.

Example

User request:

Review an iPad document editor’s autosave, background interruption and undo flow.

Describe recoverable edits, visible save failures, a safe conflict state and accessible actions. Cite the relevant local references and state which behaviors still need a native test.

Limitations

• Use this skill only when the task clearly matches the scope described above.
• Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
• Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.

Implementation boundaries

HIG design guidance is not proof of API availability or security. Validate external drag/drop files and URLs, enforce account/tenant authorization on sharing and deep links, and keep sensitive content out of search indexes, previews and logs. A masked field does not encrypt data; client-side format validation is not server validation.

Background work, notifications, audio and haptics depend on OS capabilities, user settings and system budgets. Do not promise completion, uninterrupted playback or notification delivery. Preserve work and show retry/offline/failure states. An agent must not send notifications, delete accounts, share files, record audio or alter device settings merely because the design reference describes that feature; those actions need the user task scope.