agentsclimarketplace

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

Install
npx -y skills add Enryun/SwiftUI-Architecture-Agent-Skill --skill swiftui-architecture

Assembled 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.

SituationRecommended
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

  1. Unidirectional dependencies:
    • Runtime flow is View → ViewModel → UseCase → Manager.
    • App/Factory wire dependencies at construction (Factory optional when wiring in App is enough).
  2. Protocol-first: Initializers take protocol types, not concrete managers/use cases.
  3. ViewModels are @MainActor + @Observable; use a nested ViewState enum.
  4. ViewModels never access managers — only use case protocols.
  5. Views never access use cases or managers — only the view model.
  6. Factories wire, they don't decide business outcomes — construction and composition only; no business logic.
  7. Recommend-first: Propose folder tree + types before creating files.

Scaffold workflow

Phase 1 — Propose (no file creation)

  1. Confirm feature name and domain (e.g. Catalog / ItemList).

  2. List files to add under:

    • Pages/
    • Factory/ (optional)
    • Manager/
    • UseCase/
    • Component/
    • Constants/
    • Utility/

    Adapt roots to the project's existing layout.

  3. Output:

    • Folder tree
    • Protocol names per layer
    • Dependency graph (what App or factory wires)
    • ViewState cases for the ViewModel
  4. Stop and ask for approval.

Phase 2 — Implement (after approval)

  1. Create protocols before implementations.
  2. Wire composition root in App or domain factory.
  3. ViewModel + View last.
  4. 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 in App is 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

LayerResponsibility
FactoryDependency construction & composition: build managers (incl. availability/config when needed); may expose make[Feature]ViewModel() so App stays thin
Manager CommonLogging, navigation, networking, storage
Manager FeatureApp-specific system/integration APIs
UseCaseBusiness logic; orchestrate manager protocols
ViewModelUI state, user actions → use case
ViewSwiftUI layout only

Testing guidance

  • UseCase tests: mock Manager protocols; verify business rules and orchestration.
  • ViewModel tests: mock UseCase protocol; verify ViewState transitions 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 App becomes 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

Keep looking

Skills are one crate of 326,851. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.