iOS Architecture
Create boundaries that keep policy independent from UI frameworks, storage, networking, and other implementation details.
Before you begin
Learning stage
Separation of concerns gives components focused reasons to change. A view formats and presents information, a use case applies a business decision, and a repository obtains or stores data. Separation is valuable when these concerns change independently; splitting two lines into separate types without such pressure only adds navigation cost.
Dependency direction determines which decisions are protected. High-level policy should not require knowledge of URLSession, UserDefaults, or a particular view controller. Instead, policy states the capability it needs through a narrow protocol, and the application composition root supplies a concrete implementation.
A useful protocol describes a consumer's requirement rather than copying every method from an existing service. Prefer capability-shaped interfaces such as CourseFetching or ProgressSaving. Keep boundaries small, pass domain values across them, and decide deliberately whether failures, cancellation, and actor isolation are part of the contract.
Learning stage
The use case depends on a capability it owns, while an API implementation handles transport details elsewhere.
struct LessonProgress: Equatable {
let lessonID: UUID
let completedAt: Date
}
protocol ProgressSaving: Sendable {
func save(_ progress: LessonProgress) async throws
}
struct CompleteLesson: Sendable {
private let progressStore: any ProgressSaving
private let now: @Sendable () -> Date
init(progressStore: any ProgressSaving,
now: @escaping @Sendable () -> Date = Date.init) {
self.progressStore = progressStore
self.now = now
}
func callAsFunction(lessonID: UUID) async throws {
try await progressStore.save(
LessonProgress(lessonID: lessonID, completedAt: now())
)
}
}
struct APIProgressStore: ProgressSaving {
let client: APIClient
func save(_ progress: LessonProgress) async throws {
try await client.send(ProgressRequest(progress: progress))
}
}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
Refactor a view model that creates URLSession directly. Define the smallest capability it needs and inject a live and in-memory implementation.
Hint: Write the consumer's required method first; do not mirror the entire network client.
Activity 2
Inspect models crossing your layers and identify framework, transport, persistence, or UI details that leak into policy code.
Hint: Ask whether the high-level decision could run in a command-line test target.
Learning stage
Answer each question before revealing the explanation.
QUESTION 1
An abstraction expressing the capability it needs
The lower-level implementation then conforms to the abstraction, protecting policy from implementation changes.
QUESTION 2
It exposes only the required capability, reducing coupling and making replacements easier to create.
A copied service interface forces consumers and tests to know unrelated operations.
Learning stage
Explain the decision, dependency direction, trade-offs, and evidence—not only the pattern name.
Short answer: Let high-level code define a narrow protocol for the capability it needs, then inject a concrete implementation at the composition root.
I identify the policy I want to protect, design an interface in its vocabulary, and keep transport or storage models behind the adapter. Swift protocols, closures, or generic parameters can express the seam. I include failure and concurrency semantics and avoid abstractions that have only one caller and no meaningful change pressure.
Possible follow-ups
Learning stage
Separation protects independently changing concerns, and dependency inversion lets policy define what it needs without importing implementation details.