Swiftui architecture
Skill Enryun/SwiftUI-Architecture-Agent-Skill/skills/swiftui-architecture
Scaffold and extend SwiftUI apps using Factory, Manager, UseCase, ViewModel, and View layers with protocol-first dependency injection. Use when starting a new SwiftUI project, adding a feature module, reviewing layer boundaries, folder structure, or clean architecture on iOS or macOS.From its SKILL.md
npx -y skills add Enryun/SwiftUI-Architecture-Agent-Skill --skill swiftui-architectureAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
5.2 KB, ~1.1k tokens by cl100k_base, as published. Nobody here has run it
SwiftUI Architecture
Use this skill for new SwiftUI apps, new features, and architecture reviews.
When not to use
- Single-screen prototypes → prefer simple MVVM.
- Projects committed to TCA, VIPER, or other architectures unless explicitly migrating.
Architecture decision table
Use the smallest structure that keeps responsibilities clear.
| Situation | Recommended |
|---|---|
| Small screen (simple UI state, no real business rules) | Simple MVVM: View + ViewModel |
| Medium feature (business logic growing, rules, orchestration) | View + ViewModel + UseCase |
| Feature with infra (API/storage/filesystem/device) | Manager protocol(s) + UseCase + ViewModel |
| Multiple implementations / platform differences (availability/config selection, complex wiring) | Add a Factory for construction + composition |
Non-negotiable rules
- Unidirectional dependencies:
- Runtime flow is
View → ViewModel → UseCase → Manager. App/Factory wire dependencies at construction (Factory optional when wiring inAppis enough).
- Runtime flow is
- Protocol-first: Initializers take protocol types, not concrete managers/use cases.
- ViewModels are
@MainActor+@Observable; use a nestedViewStateenum. - ViewModels never access managers — only use case protocols.
- Views never access use cases or managers — only the view model.
- Factories wire, they don't decide business outcomes — construction and composition only; no business logic.
- Recommend-first: Propose folder tree + types before creating files.
Scaffold workflow
Phase 1 — Propose (no file creation)
-
Confirm feature name and domain (e.g.
Catalog/ItemList). -
List files to add under:
Pages/Factory/(optional)Manager/UseCase/Component/Constants/Utility/
Adapt roots to the project's existing layout.
-
Output:
- Folder tree
- Protocol names per layer
- Dependency graph (what
Appor factory wires) ViewStatecases for the ViewModel
-
Stop and ask for approval.
Phase 2 — Implement (after approval)
- Create protocols before implementations.
- Wire composition root in
Appor domain factory. - ViewModel + View last.
- Extract shared UI to
Component/only when used by 2+ features.
New feature checklist (short)
- Factory — if selecting manager implementations (availability/config)
or assembling UseCase + ViewModel for
App(skip if wiring once inAppis enough) - Manager —
Interface/+Implementation/(+Model/if needed) - UseCase —
[Feature]UseCaseProtocol+[Feature]UseCase - ViewModel —
[Feature]ViewModel+ViewState - View —
[Feature]View - DI wired at App/factory
Layer quick reference
| Layer | Responsibility |
|---|---|
| Factory | Dependency construction & composition: build managers (incl. availability/config when needed); may expose make[Feature]ViewModel() so App stays thin |
| Manager Common | Logging, navigation, networking, storage |
| Manager Feature | App-specific system/integration APIs |
| UseCase | Business logic; orchestrate manager protocols |
| ViewModel | UI state, user actions → use case |
| View | SwiftUI layout only |
Testing guidance
- UseCase tests: mock Manager protocols; verify business rules and orchestration.
- ViewModel tests: mock UseCase protocol; verify
ViewStatetransitions and user-intent handlers. - View tests: prefer previews and snapshot-style checks; keep Views thin and deterministic.
Migration guidance
If adopting this architecture in an existing codebase:
- Existing MVVM: introduce a UseCase when business logic grows beyond UI state shaping.
- ViewModel calling managers directly: wrap manager calls behind a UseCase protocol; ViewModel depends on the UseCase only.
- No factories today: add a Factory when you need implementation selection
(availability/config/platform) or when wiring in
Appbecomes noisy.
Anti-patterns (reject if suggested)
// BAD — ViewModel → Manager
final class ItemListViewModel {
private let fileManager = FileSystemManager()
}
// GOOD
final class ItemListViewModel {
private let useCase: ItemListUseCaseProtocol
}
// BAD — View → UseCase
Button("Load") { Task { await useCase.load() } }
// GOOD
Button("Load") { Task { await viewModel.load() } }
Additional resources
Read only what you need:
What ships with it: 8 files
19.3 KB alongside SKILL.md
references/
- anti-patterns.md1.8 KB
- concurrency.md1.5 KB
- dependency-flow.md2.3 KB
- examples.md3.6 KB
- folder-structure.md2.6 KB
- layer-overview.md3.8 KB
- naming-conventions.md1.4 KB
- new-feature-checklist.md2.2 KB