iOS Architecture
Model features as explicit state, actions, transitions, and effects so updates remain traceable and testable.
Before you begin
Learning stage
State is information that can change and affects behavior or rendering. Durable domain state may outlive a screen, presentation state describes a feature workflow, and ephemeral state such as focus or an animation phase may remain local to a view. Promote state only when another owner genuinely needs it.
Unidirectional flow follows a repeatable loop: the user or system emits an action, a transition computes new state, effects interact with the outside world, and the view renders the resulting state. One mutation path makes changes easier to trace than several views and callbacks modifying shared values independently.
A reducer is useful when transitions are complex enough to benefit from pure input-output logic. It should not start network work secretly. Instead, the store interprets commands or launches effects through injected dependencies and feeds results back as actions. Cancellation, stale responses, duplicate loads, and main-actor rendering remain explicit parts of the design.
Learning stage
A small store keeps transitions synchronous and sends asynchronous results back through actions.
@MainActor @Observable
final class CourseListStore {
struct State: Equatable {
var courses: [Course] = []
var isLoading = false
var errorMessage: String?
}
enum Action: Equatable {
case appeared
case retryTapped
case coursesResponse(Result<[Course], CourseLoadError>)
}
private let repository: any CourseRepository
private var loadTask: Task<Void, Never>?
private(set) var state = State()
init(repository: any CourseRepository) { self.repository = repository }
func send(_ action: Action) {
switch action {
case .appeared where state.courses.isEmpty, .retryTapped:
state.isLoading = true
state.errorMessage = nil
loadTask?.cancel()
loadTask = Task { [weak self, repository] in
do {
let courses = try await repository.courses(policy: .remoteOnly)
self?.send(.coursesResponse(.success(courses)))
} catch is CancellationError {
return
} catch {
self?.send(.coursesResponse(.failure(.unavailable)))
}
}
case let .coursesResponse(.success(courses)):
state.isLoading = false
state.courses = courses
case .coursesResponse(.failure):
state.isLoading = false
state.errorMessage = "Courses are unavailable."
default:
break
}
}
}Learning stage
Connect the architectural concept to maintainable iOS features and real change scenarios.
Learning stage
Identify abstractions and dependencies that add coupling, ambiguity, or unnecessary ceremony.
Learning stage
Apply the design to a small feature and evaluate it through observable change scenarios.
Activity 1
Classify course search values as durable domain, feature presentation, derived, or ephemeral UI state. Assign an owner and lifetime to each.
Hint: Search results may be feature state while field focus can remain local.
Activity 2
Write tests for appeared → success, appeared → failure → retry, duplicate appearance, and cancellation by a newer request.
Hint: Assert each intermediate state, not only the final result.
Learning stage
Answer each question before revealing the explanation.
QUESTION 1
Actions enter through a known path, update state, and the UI renders that state
A predictable mutation path makes behavior traceable and tests easier to write.
QUESTION 2
A duplicate stored value can drift out of sync and creates another mutation responsibility.
Compute derived values unless performance evidence justifies a controlled cache.
Learning stage
Explain the decision, dependency direction, trade-offs, and evidence—not only the pattern name.
Short answer: It makes state changes explicit and testable, but adds action and transition structure that small features may not need.
I use one state owner and one mutation path when workflows have asynchronous effects, several states, or debugging pressure. Actions describe events, transitions update state, and effects return results as actions. I keep local UI state local and avoid a single global store. The trade-off is more vocabulary and boilerplate, so I scale the pattern to feature complexity.
Possible follow-ups
Learning stage
Unidirectional flow makes feature behavior observable: actions describe events, one owner transitions state, effects report results, and views render the outcome.