iOS Architecture
Use Apple's MVC responsibly by keeping controllers focused on presentation coordination instead of absorbing every concern.
Before you begin
Learning stage
In UIKit MVC, models represent data and rules, views display content and receive interaction, and view controllers coordinate between them. UIViewController is already a framework controller with lifecycle and containment responsibilities; it does not need to become the networking client, decoder, database, analytics service, formatter, and router as well.
Massive view controllers grow through convenience. A new request is started in viewDidLoad, JSON is decoded beside table code, validation appears in a button action, and navigation construction spreads across callbacks. Each addition looks small, but unrelated reasons to change accumulate in one stateful object that is difficult to test or reuse.
Refactor around responsibilities, not line count. Extract domain rules into values or use cases, data access behind a focused dependency, formatting into pure collaborators, and complex route construction into a coordinator. Keep screen-specific orchestration in the controller. A small static screen may need nothing more—architecture should reduce cognitive load, not maximize type count.
Learning stage
A controller can remain an MVC coordinator when loading and formatting are delegated to explicit collaborators.
@MainActor
final class CourseListViewController: UIViewController {
private let loader: any CourseLoading
private let formatter: CourseRowFormatter
private let tableView = UITableView()
private var courses: [Course] = []
init(loader: any CourseLoading, formatter: CourseRowFormatter) {
self.loader = loader
self.formatter = formatter
super.init(nibName: nil, bundle: nil)
}
required init?(coder: NSCoder) { fatalError("Use dependency initializer") }
override func viewDidLoad() {
super.viewDidLoad()
configureHierarchy()
Task { await loadCourses() }
}
private func loadCourses() async {
do {
courses = try await loader.courses()
tableView.reloadData()
} catch {
presentLoadFailure(retry: { [weak self] in
Task { await self?.loadCourses() }
})
}
}
}
struct CourseRowFormatter {
func subtitle(for course: Course) -> String {
"(course.completedLessons) of (course.totalLessons) complete"
}
}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
Mark each method in a sample controller as lifecycle, rendering, domain rule, data access, formatting, navigation, or analytics. Group candidates for extraction.
Hint: A coherent responsibility often changes for one reason and can be named in product language.
Activity 2
Extract one deterministic rule and one external dependency while leaving screen coordination in the controller. Add focused tests.
Hint: Measure improvement through simpler tests and fewer change reasons, not only fewer lines.
Learning stage
Answer each question before revealing the explanation.
QUESTION 1
Coordinate its view lifecycle, rendering, and user intent
Other responsibilities can live in focused model, service, use-case, formatting, or navigation collaborators.
QUESTION 2
Accumulating unrelated reasons to change and tightly coupled responsibilities, not crossing a specific line-count threshold.
A long controller with one coherent job may be clearer than many tiny indirections.
Learning stage
Explain the decision, dependency direction, trade-offs, and evidence—not only the pattern name.
Short answer: Map responsibilities, extract the highest-value seams incrementally, and keep UIKit coordination local.
I first add characterization tests around risky behavior, then identify domain decisions, external I/O, formatting, and navigation. I extract narrow collaborators with explicit inputs, outputs, and lifetimes, inject them, and verify the controller now translates state into UI. I avoid a wholesale rewrite or an equally massive replacement type.
Possible follow-ups
Learning stage
MVC works when its roles stay meaningful. The problem is not UIViewController itself but the gradual accumulation of unrelated policy, I/O, formatting, and routing.