Swift iOS architecture guidance and playbooks for MVVM, MVI, TCA, Clean Architecture, VIPER, MVP, Coordinator, and Reactive patterns. Use when designing, implementing, refactoring, or reviewing the architecture of a SwiftUI or UIKit feature, module, or codebase.
swift-architecture-skill is an architecture-guidance skill for Swift iOS codebases. It helps select and apply the right architectural pattern for a SwiftUI or UIKit feature, module, or whole codebase, covering MVVM, MVI, TCA, Clean Architecture, VIPER, MVP, Coordinator, and Reactive patterns. It solves the recurring problem of choosing an architecture that fits actual constraints rather than defaulting to a favorite or over-engineering a small feature.
The skill starts by capturing task type, UI stack, minimum deployment target (iOS 17+ enables @Observable while iOS 16 needs ObservableObject), scope, state and effect complexity, team familiarity, and existing conventions. It then routes: if the user names an architecture it runs a fit check first; otherwise it infers the best fit from a selection guide. It offers a Quick Recommendation Mode for single features and a Deep Refactor Mode for multi-module migrations, and maps each pattern to a detailed reference playbook. Playbooks (for example Clean Architecture) include dependency rules, canonical layer layouts, entity/use-case/repository patterns, dependency injection, DTO-to-domain mapping, structured concurrency and cancellation, presentation boundaries, anti-patterns with fixes, and testing strategy with example Swift code. Guardrails discourage unnecessary architecture switches and adding heavy dependencies like TCA unless the user accepts the trade-off.
It targets iOS engineers and tech leads designing, refactoring, or reviewing SwiftUI/UIKit architecture. It is pure guidance and example code with no execution, network, or credential handling.
MVVM, MVI, TCA, Clean Architecture, VIPER, MVP, Coordinator, and Reactive, each with its own reference playbook, plus a selection guide for choosing among them.
It treats your choice as the initial candidate and runs a fit check against your UI stack, state complexity, effect needs, team familiarity, and existing conventions before committing, recommending an alternative if it mismatches.
Yes. It captures the minimum iOS version because iOS 17+ enables @Observable while iOS 16 requires ObservableObject, which affects presentation-layer choices.
No. Its guardrails explicitly avoid forcing an architecture switch when the current local pattern is a reasonable fit, and it prefers the smallest change that solves the request.
Only with your consent. It will not introduce frameworks like TCA unless you explicitly accept the trade-off or your codebase already uses them.
Quick Setup:
.claude/skills/Repository
efremidze/swift-architecture-skill