SwiftUI Expert Skill

Operating Rules

• Treat each View type as an invalidation boundary: give it only the data it reads and keep frequently changing dependencies close to the smallest affected subtree
• Search references/latest-apis.md when writing, reviewing, or migrating API usage; look up only the APIs relevant to the task
• Replace hard-deprecated APIs with modern equivalents. During feature work, flag soft-deprecated APIs and leave them in place (see references/soft-deprecation.md)
• 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
• For layout and rendering inputs, read the value nearest the SwiftUI view that consumes it; do not substitute process-global screen state

Task Workflow

Review existing SwiftUI code

• Read the code under review and identify which topics apply
• Flag deprecated APIs (compare against references/latest-apis.md); replace hard-deprecated APIs, and flag soft-deprecated APIs without rewriting them unless the user asked to migrate
• Run the Topic Router below for each relevant topic
• Validate #available gating and fallback paths for version-specific features
• For broad codebase reviews, first identify smaller focus areas and present them one at a time; if the user requests a whole-codebase review, divide it into a TODO list