swift-design-system-pro

Set up or review the UI foundation of an Apple app: icons, tokens, and core components. This is the deep companion to the always-on apple-iconography.md and apple-design-system.md rules — the rules steer while writing; this skill scaffolds a design system from scratch or audits a whole app against one.

Applies to SwiftUI (with UIKit interop notes). Pick the mode from the request:

• Bootstrap — a new app, or an app with no design-system module: generate the module skeleton using references/bootstrap.md, then fill tokens and components with the user's brand inputs (accent color, brand font, corner style). Ask only for inputs you can't infer; default to system colors and text styles when none are given, and say so.
• Audit — an existing app: find and rank what breaks Dark Mode, Dynamic Type, Increase Contrast, RTL, VoiceOver, and visual consistency; propose an incremental migration.
• Write/fix — make the changes directly and summarize them in the same file-by-file format.

Review process (audit mode):

1. Inventory with the searches in references/bootstrap.md ("Audit searches") — literal colors, fixed font sizes, raw symbol strings, Bundle.main asset loads, one-off button implementations. Count before reading files; the counts set priorities.
2. Audit icons using references/iconography.md — symbol facade, availability, sizing, rendering modes, effects, custom symbols, icon accessibility, the app icon.
3. Audit tokens and theming using references/tokens-and-theming.md — color roles and appearance variants, type scale and custom fonts, spacing/shape scales, Liquid Glass adoption, environment theming.
4. Audit components using references/components.md — styles vs wrapper views, duplicates to converge, statelessness, built-in accessibility, previews and the gallery.

If doing a partial review, load only the relevant reference files.

Core Instructions

• Meaning over pixels. Tokens and icons are named by role (surfaceElevated, .delete), never by value (gray200, "trash"). A finding that just swaps one literal for another literal is not a fix.
• System first. Prefer system semantic colors, text styles, SF Symbols, system button styles, and system containers; every custom piece is something the team maintains through each OS release. Recommend custom only where the system genuinely has no equivalent.
• Adaptation is the test. For every token and component ask: does it survive Dark Mode, Increase Contrast, the largest accessibility text size, RTL, Reduce Motion/Transparency, and a window resize? Report the setting that breaks it.
• The design system is a module with a direction. It depends on nothing app-specific; features depend on it. Flag inverted dependencies (components importing feature models or view models).
• Incremental, never big-bang. Migration plans move one screen or one token family at a time and keep the app shipping; never propose a rewrite of every view in one pass.
• Severity by user impact: broken (invisible text/icon in an appearance, blank symbol, truncated controls at large text, unlabeled icon-only control, app icon rejected) > inconsistent (duplicate components, off-scale spacing, mixed symbol styles) > polish (rendering-mode tuning, effect choice).
• Cross-reference, don't duplicate: deep VoiceOver/keyboard audits belong to swift-accessibility-pro; view-body performance and modern-API sweeps to swiftui-pro; resizable-window behavior to swift-adaptive-layout-pro.