swiftui-advanced
Use when implementing gesture composition (simultaneous, sequenced, exclusive), adaptive layouts (ViewThatFits, AnyLayout, size classes), or choosing architecture patterns (MVVM vs TCA vs vanilla, State-as-Bridge). Covers advanced SwiftUI patterns beyond basic views.
When & Why to Use This Skill
This Claude skill provides expert guidance on advanced SwiftUI development, focusing on complex gesture composition, adaptive layout strategies, and architectural decision-making. It helps developers optimize performance and choose between MVVM, TCA, or vanilla SwiftUI patterns to build robust, scalable iOS applications.
Use Cases
- Implementing complex user interactions by composing simultaneous, sequenced, or exclusive gestures.
- Designing responsive and adaptive UI layouts that handle various screen sizes and orientations using ViewThatFits and AnyLayout.
- Evaluating and selecting the most appropriate architectural pattern (MVVM vs. TCA vs. Vanilla) based on project complexity and testability requirements.
- Identifying and resolving performance bottlenecks in SwiftUI views by optimizing view body execution and state management.
| name | swiftui-advanced |
|---|---|
| description | Use when implementing gesture composition (simultaneous, sequenced, exclusive), adaptive layouts (ViewThatFits, AnyLayout, size classes), or choosing architecture patterns (MVVM vs TCA vs vanilla, State-as-Bridge). Covers advanced SwiftUI patterns beyond basic views. |
SwiftUI Advanced
Advanced SwiftUI patterns for gesture composition, adaptive layouts, architecture decisions, and performance optimization.
Reference Loading Guide
ALWAYS load reference files if there is even a small chance the content may be required. It's better to have the context than to miss a pattern or make a mistake.
| Reference | Load When |
|---|---|
| Gestures | Composing multiple gestures, GestureState, custom recognizers |
| Adaptive Layout | ViewThatFits, AnyLayout, size classes, iOS 26 free-form windows |
| Architecture | MVVM vs TCA decision, State-as-Bridge, property wrapper selection |
| Performance | Instruments 26, view body optimization, unnecessary updates |
Core Workflow
- Identify pattern category from user's question
- Load relevant reference for detailed patterns and code examples
- Apply pattern following the decision trees and anti-patterns
- Verify using provided checklists or profiling guidance
Decision Trees
Gesture Composition
- Both gestures at same time? ->
.simultaneously - One must complete before next? ->
.sequenced - Only one should win? ->
.exclusively
Layout Adaptation
- Pick best-fitting variant? ->
ViewThatFits - Animated H/V switch? ->
AnyLayout - Need actual dimensions? ->
onGeometryChange
Architecture Selection
- Small app, Apple patterns? -> @Observable + State-as-Bridge
- Complex presentation logic? -> MVVM with @Observable
- Rigorous testability needed? -> TCA
Common Mistakes
Gesture composition order matters —
.simultaneouslyand.sequencedhave different trigger timing. Swapping them silently changes behavior. Understand gesture semantics before using.ViewThatFits over-used — ViewThatFits remeasures on every view change. For animated H/V switches, use
AnyLayoutinstead. Use ViewThatFits only for static variant selection.onGeometryChange triggering unnecessary updates — Reading geometry changes geometry, which triggers updates, which changes geometry... circular. Use
.onGeometryChangeonly with proper state management to avoid loops.Architecture mismatch mid-project — Starting with @Observable + State-as-Bridge then realizing you need TCA is expensive. Choose architecture upfront based on complexity (small app = @Observable, complex = TCA).
Ignoring view body optimization — Computing expensive calculations in view body repeatedly kills performance. Move calculations to properties or models. Profile with Instruments 26 before optimizing prematurely.