Swift Architecture Skill
Pick and implement the right iOS architecture (MVVM, TCA, Clean, VIPER, and others) for a SwiftUI or UIKit feature.
Overview
swift-architecture-skill is an agent skill for the Build phase that selects and applies Swift, SwiftUI, and UIKit architectures with concrete implementation and review guidance.
Install
npx skills add https://github.com/efremidze/swift-architecture-skill --skill swift-architecture-skillWhat is this skill?
- selection-guide.md routes constraints to a best-fit architecture before coding
- Ten dedicated references: MVVM, MVI, TCA, Clean, VIPER, Reactive, MVP, Coordinator, plus routing index
- Explicit paths for SwiftUI-light features vs UIKit VIPER/MVP modules
- TCA guidance for complex composition, child features, and strict effect orchestration
- Reactive guide for Combine- or RxSwift-heavy event pipelines
- 10 architecture reference guides including selection-guide, MVVM, MVI, TCA, Clean, VIPER, Reactive, MVP, and Coordinator
Adoption & trust: 1k installs on skills.sh; 40 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are starting or refactoring an iOS feature but cannot tell whether MVVM, TCA, VIPER, or Coordinator will survive your navigation and state complexity.
Who is it for?
Indie iOS apps adding non-trivial screens, navigation graphs, or reactive pipelines where ad-hoc MVVM will not scale.
Skip if: Greenfield Markdown docs, backend-only services, or Android/Kotlin projects outside the Swift stack.
When should I use this skill?
Use this skill to select and apply the right architecture for Swift, SwiftUI, and UIKit features, then provide concrete implementation guidance and review checks.
What do I get? / Deliverables
You commit to a documented architecture with pattern-specific implementation steps and review checks aligned to SwiftUI or UIKit constraints.
- Recommended architecture with rationale
- Implementation outline per pattern file
- Review checklist for structure and effects
Recommended Skills
Journey fit
Architecture choices bind during Build when solo builders structure new iOS screens, navigation, and state before TestFlight or App Store ship. Frontend subphase covers SwiftUI and UIKit presentation layers, coordinators, and presenter/view boundaries emphasized in the skill.
How it compares
Pattern router and implementation playbooks for native iOS, not a generic mobile codegen or cross-platform Flutter guide.
Common Questions / FAQ
Who is swift-architecture-skill for?
Solo iOS developers and small teams shipping SwiftUI or UIKit apps who want agent help choosing architectures and applying them with review criteria.
When should I use swift-architecture-skill?
During Build while designing features—simple screens via MVVM, deterministic reducers via MVI, complex graphs via TCA, large UIKit modules via VIPER, or decoupled flows via Coordinator.
Is swift-architecture-skill safe to install?
It is architecture guidance without mandated shell or network access; review the Security Audits panel on this Prism page and the efremidze repository before enabling broader agent permissions.
SKILL.md
READMESKILL.md - Swift Architecture Skill
interface: display_name: "Swift Architecture Skill" short_description: "Architecture guidance for Swift, SwiftUI, and UIKit iOS projects" default_prompt: "Use this skill to select and apply the right architecture for Swift, SwiftUI, and UIKit features, then provide concrete implementation guidance and review checks." # Reference Index Quick navigation for the Swift Architecture skill. ## Core Routing | File | Use it for | |---|---| | `selection-guide.md` | choosing the best-fit architecture from user constraints | | `mvvm.md` | low-to-medium complexity features with lightweight state binding | | `mvi.md` | reducer-style state machines without adding a framework dependency | | `tca.md` | complex, highly composable features with strict effect orchestration | | `clean-architecture.md` | strict layer boundaries and replaceable infrastructure | | `viper.md` | large UIKit modules needing explicit role separation | | `reactive.md` | Combine or RxSwift stream-heavy features and event pipelines | | `mvp.md` | UIKit-first passive views with presenter-driven rendering | | `coordinator.md` | decoupled navigation flows and deep-linkable screen orchestration | ## Problem Router - "I need help choosing an architecture" → `selection-guide.md` - "The feature is simple and screen-scoped" → `mvvm.md` - "I want deterministic state transitions without TCA" → `mvi.md` - "The feature has complex state, child composition, and strict effects" → `tca.md` - "I need use cases, repositories, and clean boundaries" → `clean-architecture.md` - "This is a large UIKit module with clear presenter/interactor/router roles" → `viper.md` - "The problem is stream-heavy or driven by Combine/RxSwift" → `reactive.md` - "I want a passive UIKit view with a presenter" → `mvp.md` - "The main issue is navigation flow and screen coordination" → `coordinator.md` # Clean Architecture Playbook (Swift + SwiftUI/UIKit) Use this reference when a Swift codebase needs strict layer boundaries and use-case-driven business logic. ## Core Dependency Rule Dependencies point inward: ```text Frameworks / UI -> Interface Adapters -> Use Cases -> Entities (Domain) ``` Rules: - inner layers must not import or depend on outer layers - domain remains pure Swift - frameworks are implementation details and replaceable ## Canonical Layer Layout ```text Domain/ Entities/ UseCases/ Data/ Repositories/ API/ Persistence/ Presentation/ Features/ App/ ``` Guidance: - keep entities and use-case protocols in `Domain` - keep repository implementations and external adapters in `Data` - keep views/view models/controllers in `Presentation` - keep DI composition root and app bootstrap in `App` ## Entities Entities model core business concepts and rules. ```swift struct User: Equatable { let id: UUID let name: String } ``` Rules: - no SwiftUI/UIKit imports - no persistence or network behavior - avoid framework-specific types unless unavoidable ## Use Cases Use cases orchestrate business actions through abstractions. ```swift protocol LoadUserUseCase { func execute(id: UUID) async throws -> User } final class LoadUser: LoadUserUseCase { private let repository: UserRepository init(repository: UserRepository) { self.repository = repository } func execute(id: UUID) async throws -> User { try await repository.fetch(id: id) } } ``` Rules: - one business responsibility per use case - no UI details - no direct framework usage unless abstracted ## Repository Boundary Define repository protocols in `Domain`; implement them in `Data`. ```swift protocol UserRepository { func fetch(id: UUID) async throws -> User } ``` Data-layer implementations can coordinate: - API clients - local persistence - mapping DTOs to domain entities ## Dependency Injection Pattern Compose live dependencies in the app or feature assembly layer. ```swift enum UserFeatureAssembly { static func makeLoadUserUseCase() -> LoadUserUseC