swiftui-expert-skill
Write, review, or improve SwiftUI code following best practices for state management, view composition, performance, modern APIs, Swift concurrency, and iOS 26+ Liquid Glass adoption. Use when building new SwiftUI features, refactoring existing views, reviewing code quality, or adopting modern SwiftUI patterns.
Author
Category
Development ToolsInstall
Download and extract to your skills directory
Copy command and send to OpenClaw for auto-install:
SwiftUI Expert - SwiftUI Code Review and Best Practices Guide
Skill Overview
SwiftUI Expert is a professional SwiftUI code assistant that helps developers write, review, and improve SwiftUI code, covering state management, view composition, performance optimization, modern API migration, Swift concurrency, and implementing iOS 26+ Liquid Glass styles.
Suitable Scenarios
1. Building New SwiftUI Features
When developing new SwiftUI features, this skill guides you to choose the right state management approach (e.g., @Observable vs ObservableObject), use modern SwiftUI APIs (such as NavigationStack and the Tab API), and adopt best-practice view composition patterns—ensuring the code aligns with Apple’s best practices from the very beginning of the design.
2. Refactoring Existing SwiftUI Code
For legacy SwiftUI code, this skill can systematically assess code quality, identify deprecated APIs (such as foregroundColor and NavigationView), recommend modern alternatives, extract complex views to improve maintainability, and optimize performance bottlenecks (such as reducing unnecessary state updates and using stable ForEach identities).
3. SwiftUI Code Review and Team Collaboration
Provides a standardized SwiftUI code review checklist for teams, covering multiple dimensions including state management, modern API usage, view structure, performance optimization, list patterns, layout best practices, and iOS 26+ features—helping the team maintain consistent code quality and coding standards.
Core Features
1. Smart State Management Guidance
This skill offers a detailed guide for choosing property wrappers, prioritizing the modern @Observable macro over the traditional ObservableObject. It clearly distinguishes when to use @State, @Binding, and @Bindable, and emphasizes the importance of the @MainActor thread-safety annotation to help you avoid common state management pitfalls.
2. Modern API Migration Assistant
Systematically identifies and replaces deprecated SwiftUI APIs, including using foregroundStyle() instead of foregroundColor(), using NavigationStack instead of NavigationView, using the Tab API instead of tabItem(), and adopting the new onChange() syntax and containerRelativeFrame() layout approach—ensuring the code always uses the latest APIs.
3. Performance Optimization Specialist
Deeply analyzes SwiftUI view performance issues and provides end-to-end optimization recommendations, from view composition and state passing to ForEach stability and layout computation. It includes expert tips such as using LazyVStack/LazyHStack for long lists, avoiding side effects in body, reducing unnecessary state updates, and using POD views to speed up diffs.
Common Questions
When should I use @Observable instead of ObservableObject?
For new code, you should always prefer the @Observable macro over the ObservableObject protocol. @Observable is the modern state management approach introduced in iOS 17+, with better performance, more concise syntax, and improved handling of nested objects. When using @Observable, you should use @State (not @StateObject) to hold an object instance, and mark it with @MainActor when needed to ensure thread safety. Only consider using the traditional ObservableObject when your project must support versions prior to iOS 17.
Why isn’t SwiftUI ForEach recommended to use .indices?
Using .indices as the identity for ForEach can lead to unstable behavior: when array elements change, indices may change too, preventing SwiftUI from correctly tracking view identities. This can cause animation glitches or lost state. The recommended approach is to add an id property to your data model that conforms to Identifiable, or use \.id as the identity parameter. This ensures SwiftUI updates, moves, or deletes the corresponding views correctly when data changes.
How do I troubleshoot and optimize poor SwiftUI view performance?
First, use Self._printChanges() to debug and identify the causes of unintended view updates. Common performance issues include: running expensive computations in body, passing oversized configuration objects, using unstable ForEach identities, overusing AnyView, and performing redundant state updates in hot paths. Optimization strategies include: extracting subviews to reduce the update scope, using LazyVStack/LazyHStack for long lists, pre-filtering data to avoid inlined filtering inside ForEach, using POD views to speed up diffs, and adding value-change checks in hot paths such as scroll callbacks.
How do I choose the correct property wrapper in SwiftUI?
The core principle for choosing a property wrapper is understanding data ownership and flow. Use @State for internally owned view state (must be declared private); use @Binding when a child view needs to modify parent view state; use @Bindable to provide two-way bindings for injected @Observable objects. For simple read-only values, pass them directly with let. For read-only values that require reactive listening, use var with .onChange(). Special note: values passed through should never be declared as @State or @StateObject, since they accept only initial values.
What’s the difference between NavigationStack and NavigationView?
NavigationStack is the modern navigation API introduced in iOS 16+, replacing the deprecated NavigationView. Key advantages include: support for type-safe navigationDestination(for:), a cleaner API design, better performance, and programmatic control over the navigation stack. New projects should always use NavigationStack; only consider NavigationView if you need to support versions prior to iOS 16.
What should I focus on during SwiftUI code review?
Code review should cover multiple dimensions: whether state management uses @Observable instead of ObservableObject, whether property wrapper selection is correct, whether deprecated APIs are used (such as foregroundColor and cornerRadius), whether views are overly complex and need to be split, whether ForEach uses stable identities, whether there are performance risks (such as side effects in body), whether @State/@StateObject are declared as private, and whether iOS version compatibility is handled correctly. This skill provides a complete review checklist covering state management, modern APIs, forms and navigation, scroll views, text formatting, view structure, performance, list patterns, and layout.