Architecture Patterns Skill

Architecture Patterns

Overview

Quick reference for choosing and implementing iOS architecture patterns. Focused on decision criteria, not tutorials.

Pattern Selection

| Complexity | Pattern | Use When | |------------|---------|----------| | Simple | MV | Single screen, local state only | | Medium | MVVM | 2-5 screens, business logic, network calls | | Complex | TCA | State machines, side effects, complex flows | | Enterprise | Clean | Multiple teams, maximum modularity |

Decision Tree

1. Single screen + local state only?
   → MV (SwiftUI View + @State)

2. Business logic or shared state?
   → MVVM

3. Complex state transitions?
   → TCA

4. Multi-team, high modularity?
   → Clean Architecture

MVVM Pattern (Most Common)

Structure:

ViewModels: @Observable, protocol-based DI
Views: @State private var viewModel
Services: Protocols for testability

Critical Rules:

✅ Protocol-based DI via init (enables mocking)
✅ @MainActor for state updates
✅ Keep Views dumb (delegate to ViewModel)
❌ Never import SwiftUI in ViewModels
❌ Never use @Published (use @Observable)
❌ Never make ViewModels optional

Minimal Example:

protocol AuthServiceProtocol {
    func login(_ email: String, _ password: String) async throws -> User
}

@Observable
final class LoginViewModel {
    private let authService: AuthServiceProtocol
    var email = ""
    var password = ""
    var isLoading = false

    init(authService: AuthServiceProtocol = AuthService()) {
        self.authService = authService
    }

    @MainActor
    func login() async {
        isLoading = true
        defer { isLoading = false }
        try? await authService.login(email, password)
    }
}

struct LoginView: View {
    @State private var viewModel = LoginViewModel()
    var body: some View {
        Form {
            TextField("Email", text: $viewModel.email)
            SecureField("Password", text: $viewModel.password)
            Button("Login") { Task { await viewModel.login() } }
                .disabled(viewModel.isLoading)
        }
    }
}

TCA Pattern

Use for: Complex state machines, side effects, time-travel debugging

Key: Single Reducer with State/Action/Dependencies. Exhaustive testing via TestStore.

Reference: TCA documentation

Clean Architecture

Use for: Enterprise apps, multiple teams, maximum testability

Patterns:

VIP (View-Interactor-Presenter): Use vip-clean-architecture skill for unidirectional data flow, protocol-based boundaries, and Spy-pattern testing
Generic Clean: Domain (entities, use cases) → Data (repositories, network) → Presentation (ViewModels, Views)

Key: Dependency inversion, protocol-based boundaries between layers

References

For detailed implementation examples and migration guides, see:

references/mvvm-patterns.md
references/tca-guide.md
references/clean-architecture.md

Word count: ~300 (was 2,863) For: Senior/mid iOS engineers who know how to code Focus: Decision-making, not hand-holding

Agent Skills: Architecture Patterns

Install this agent skill to your local

Skill Files