/apple-design

name: apple-design
description: Use when the user asks for SwiftUI, UIKit, AppKit, iOS, iPadOS, macOS, watchOS, visionOS, Liquid Glass, HIG, SF Symbols, App Store deliverables, Apple settings/forms, branded Apple apps, React Native iOS, Flutter Cupertino, or Electron/Tauri macOS shells. Builds Apple-platform apps across system-like SwiftUI, branded SwiftUI, React Native, Flutter Cupertino, and desktop web shells while preserving UX decisions, native idiom, desktop archetype, originality seed, state coverage, Dynamic Type, accessibility, and HIG/Liquid Glass rules. ALWAYS ask which track first. SKIP when the target is only Android, Windows, or web-in-browser.

apple-design — pick the track first

Apple platforms have multiple stacks with different visual ceilings and cost. **Ask the user which one before any code.**

What This Skill Can Do

• Choose the right Apple track: strict SwiftUI, branded SwiftUI, React Native, Flutter Cupertino, or Electron/Tauri for macOS.
• Design iPhone task flows, iPad/macOS productivity surfaces, menu-bar utilities, document apps, settings, inspectors, media apps, and desktop-class workbenches.
• Preserve UX briefs, state coverage, action hierarchy, keyboard flow, Dynamic Type, focus, accessibility, and safe areas.
• Apply HIG, Liquid Glass, SF Symbols, SF typography, NavigationSplitView, DocumentGroup, inspectors, sheets, toolbars, and platform-specific motion.
• Add originality through composition, content, and state treatment without replacing native controls with web-style chrome.

Step 0 (MANDATORY) — Ask the user which track

> Which track for this app? > > **1. System-like native (SwiftUI strict + Liquid Glass + HIG)** — feels like Settings, Notes, Reminders, Mail. Best for: utilities, productivity. Visual ceiling: medium. Stays App Store-friendly. Examples: Things 3, NetNewsWire, Soulver. > > **2. Branded native (SwiftUI + HIG + custom identity)** — native chrome (Liquid Glass, SF Symbols, Dynamic Type) but bespoke content surface (custom typography, hero atmospheres, magazine layouts). Best for: consumer/media/creative apps that want fit-in *and* identity. Visual ceiling: high. Examples: Ivory, Reeder, Mela, Craft, CARROT Weather. > > **3. React Native (New Architecture + Fabric + Hermes)** — real UIKit views, decent native feel, JavaScript codebase, cross-platform with Android. Liquid Glass partial via `expo-glass-effect`. Best for: cross-platform apps with web-team velocity. Examples: Discord mobile, Coinbase, Microsoft Office mobile. > > **4. Flutter Cupertino** — Skia-painted UIKit-look. Always one OS behind, no Liquid Glass. Cross-platform. Best for: utility apps where pixel control beats native feel. Visual ceiling: high if you bring your own design language; low if you try to mimic iOS. > > **5. Electron / Tauri 2 (macOS only — no iOS)** — web stack desktop apps. Tauri 2 (~5MB, WKWebView) or Electron (~150MB, bundled Chromium). Same React/Tailwind/Motion code as web. Best for: cross-platform desktop with brand-first identity. Examples: Spotify, Discord, VSCode, Slack, Figma desktop, Linear. > > Which? Or describe priorities (App Store, brand vs HIG fit, cross-platform reach) and I'll pick.

If brief gives a strong signal (e.g. "iOS App Store launch" → 1 or 2; "cross-platform with our existing React team" → 3 or 5; "web team building desktop-only" → 5), state your pick + reasoning in one sentence. If ambiguous, ask.

Step 0b — Once picked, route

| Track | Reference docs | Default stack | |---|---|---| | 1. System-like SwiftUI | `../../references/apple-hig.md` + `../../references/liquid-glass.md` | SwiftUI 7 + Xcode 26 + iOS 26 SDK strict | | 2. Branded SwiftUI | Same as 1 | Same as 1 + custom display font + hero atmospheres + bespoke surfaces | | 3. React Native | `../../references/web-fonts.md` + cross-platform docs | RN 0.78+ New Arch + Expo Router + react-native-screens | | 4. Flutter Cupertino | None for native fidelity (will feel imported) | Flutter 3+ stable | | 5. Tauri 2 / Electron (macOS) | `../../references/web-fonts.md` + `../../references/web-motion.md` + `../../references/web-bans.md` + `../../references/awwwards-ceiling.md` | React 19 + Tailwind v4 + Motion |

For tracks 3, 4, 5: web/cross-platform anti-slop rules apply. Read the web design references.

State the chosen aesthetic direction and track in one sentence at top of response, then proceed.

Step 0c — UI decision brief

Before code, read:

• `../../references/ui-patterns/surface-taxonomy.md`
• `../../references/ui-patterns/ui-decision-brief.md`
• `../../references/ui-patterns/desktop-app-archetypes.md`
• `../../references/ui-patterns/native-desktop-app-quality-contract.md`
• `../../references/ui-patterns/originality-engine.md`
• `../../references/ui-patterns/design-recipes.md`
• `../../references/ui-patterns/anti-default-contrasts.md`
• `../../references/ui-patterns/visual-hierarchy.md`
• `../../references/ui-patterns/motion-budget.md`

Write the UI decision brief and, for macOS/iPad desktop-class work, the desktop archetype brief, native desktop quality brief, and compact layout sketch. For original/non-generic Apple work, also write the originality brief: subject, product world, main object, composition archetype, repeated motif, one weird move, and restraints. Pick the app shape before picking controls: command center, library/collection, workbench, monitoring cockpit, menu-bar utility, media/consumer, document/knowledge, or setup/preferences. Define window model, command model, resize behavior, native controls, keyboard/focus paths, state coverage, and platform evidence. If the sketch becomes generic sidebar + detail, use anti-default contrasts and rewrite it around the main object. iPhone task flows need thumb reach and progressive disclosure; iPad/Mac productivity surfaces need NavigationSplitView, inspector, keyboard flow, command surfaces, and stable density; media/consumer apps may use branded content surfaces while preserving HIG controls,