Swift Apps

Engineer native-feeling Apple-platform software with SwiftUI-first patterns, clear state ownership, platform fidelity, accessibility, and performance discipline. Default to direct, readable code that works with Apple frameworks instead of layering web-style abstractions onto SwiftUI.

Choose The Track

• New feature or screen: Define the target platform, app archetype, primary action, core states, navigation model, and data ownership before writing code. Then load references/architecture-and-state.md and references/ui-patterns.md.
• Refactor or cleanup: Preserve behavior, simplify structure, reduce indirection, and make state ownership obvious. Then load references/architecture-and-state.md.
• Bug fix: Reproduce first with a failing test when the project has a workable test harness. Enumerate 2-3 hypotheses before changing code. Then load references/performance-and-debugging.md and any domain-specific reference.
• Performance or jank: Start code-first, then move to profiling if review is inconclusive. Load references/performance-and-debugging.md.
• Liquid Glass or new design-system APIs: Use native materials and availability gating, not custom blur imitations. Load references/liquid-glass.md.
• macOS-specific work: Treat menu commands, keyboard flows, windows, sidebars, toolbars, and text behavior as product requirements, not polish. Load references/macos-quality-bar.md.
• Version-sensitive API questions: When the exact current API shape matters, load references/official-docs-map.md first and trust Apple docs over memory.

Apply The Core Rules

1. Prefer system structure before custom structure. Use NavigationStack, NavigationSplitView, TabView, List, Form, Table, Commands, and built-in materials before custom containers.