architecture-patterns

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)
        }
    }
}