Swiftui Expert Skill

This is a comprehensive reference guide for writing production SwiftUI code with current best practices baked in. Use it when you need authoritative answers on state management (@State vs @Binding vs @Observable), view composition patterns, performance optimization for lists and animations, or iOS 26+ Liquid Glass adoption. The decision tree walks you through reviewing, improving, or implementing features with specific checks at each step. What I like here is the specificity: it tells you exactly when to use which property wrapper, how to avoid common animation pitfalls like the deprecated animation modifier without a value parameter, and performance traps like inline filtering in ForEach. The accessibility guidance is also concrete (prefer Button over onTapGesture, use @ScaledMetric for Dynamic Type). Treat this as your SwiftUI facts layer when you want to avoid cargo culting Stack Overflow patterns.

skills.sh installs: 296
GitHub stars: 39.4K
last updated: Jun 3, 2026

View on GitHub

Install

$ npx -y skills add sickn33/antigravity-awesome-skills --skill swiftui-expert-skill --agent claude-code

Installs into .claude/skills of the current project.

Files

SwiftUI Expert Skill

When to Use

Use when writing, reviewing, or refactoring SwiftUI code for iOS or macOS, including state management and @Observable data flow, view composition and invalidation/performance, lists and ForEach identity, environment usage, localization, animations, Liquid Glass adoption, API migrations and analysis of explicitly selected Instruments traces.

Operating Rules

Consult references/latest-apis.md at the start of every task to avoid deprecated APIs
Prefer native SwiftUI APIs over UIKit/AppKit bridging unless bridging is necessary
Focus on correctness and performance; do not enforce specific architectures (MVVM, VIPER, etc.)
Encourage separating business logic from views for testability without mandating how
Follow Apple's Human Interface Guidelines and API design patterns
Only adopt Liquid Glass when explicitly requested by the user (see references/liquid-glass.md)
Present performance optimizations as suggestions, not requirements
Use #available gating with sensible fallbacks for version-specific APIs