iOS Architecture
Understand architecture as deliberate decisions about responsibilities, dependencies, state, and change.
Before you begin
Learning stage
Architecture is the set of decisions that determines where responsibilities live, how parts communicate, who owns state, and which direction dependencies point. An app has an architecture even when nobody designed one; accidental architecture simply makes those decisions inconsistently and discovers their cost later.
Useful boundaries isolate reasons to change. Presentation changes because product design changes, domain rules change because the business changes, and data access changes because APIs or storage change. These concerns do not need a layer for every type, but they should not be fused automatically inside one screen object.
Judge an architecture by the work it enables. Can a developer locate behavior, replace a dependency, test an important rule, understand state ownership, and add a feature without editing unrelated code? The best design is usually the smallest one that answers today's real pressures while leaving clear seams for likely change.
Learning stage
A small feature becomes easier to reason about when loading, business decisions, and rendering have visible ownership.
struct Course: Identifiable, Equatable {
let id: UUID
let title: String
let completedLessons: Int
let totalLessons: Int
var canReceiveCertificate: Bool {
totalLessons > 0 && completedLessons == totalLessons
}
}
protocol CourseLoading {
func courses() async throws -> [Course]
}
@MainActor
final class CourseListModel {
enum State: Equatable {
case idle, loading, loaded([Course]), failed(String)
}
private let loader: any CourseLoading
private(set) var state: State = .idle
init(loader: any CourseLoading) {
self.loader = loader
}
func load() async {
state = .loading
do { state = .loaded(try await loader.courses()) }
catch { state = .failed("Courses could not be loaded.") }
}
}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
Choose a sign-in or course-list feature and list its UI state, domain decisions, data access, navigation, and side effects. Assign one owner to each.
Hint: If two components both believe they own the same state, make that conflict explicit.
Activity 2
Ask how the design reacts to a new API, offline cache, alternate UI, and revised completion rule. Record which files should change for each scenario.
Hint: A good boundary contains change; it does not promise zero edits.
Learning stage
Answer each question before revealing the explanation.
QUESTION 1
Decisions about responsibilities, state, boundaries, and dependencies
Names and folders may communicate architecture, but the actual runtime relationships and ownership are what matter.
QUESTION 2
By how clearly and safely it supports important behavior and likely change at an acceptable cost.
Pattern purity is less useful than understandable ownership, testable decisions, and fast feedback.
Learning stage
Explain the decision, dependency direction, trade-offs, and evidence—not only the pattern name.
Short answer: Clear ownership and dependency boundaries that make important behavior easy to understand, test, and change without unnecessary ceremony.
I begin with feature workflows, state, side effects, and expected change. I keep domain decisions independent where that provides value, inject external dependencies, and let the UI render explicit state. I evaluate the result through change scenarios and tests, then add abstraction only when it removes demonstrated coupling or duplication.
Possible follow-ups
Learning stage
Architecture is deliberate ownership and dependency design. Its value appears when behavior is understandable and change remains local, safe, and proportionate to the app's needs.