Question 7
Refactoring a massive view controller
A 4k-line view controller handles networking, analytics and Swift Data. What incremental refactor plan would you present?
Follow-ups
- How do you avoid breaking QA during the migration?
Answer outline
Do not rewrite the whole 4k-line controller at once. Use a strangler refactor (keep the screen working while you move one responsibility at a time).
Start with the risky outside dependencies: move networking, analytics, and SwiftData access behind small injected services.
Then move screen logic into a view model: loading state, user actions, formatting, validation, and save commands.
The view controller should shrink into a thin layer that owns lifecycle, binding, and navigation wiring.
Keep each PR small enough to review and ship. If the change is risky, protect it with tests, a feature flag, or side-by-side debug comparison.
Principles
- Think: extract dependencies, then extract state, then thin the controller.
- Avoid big-bang rewrites.
- One responsibility per PR.
- Keep
ModelContextand persistence details out of the view controller. - After extraction, check retain cycles and closure captures.
Follow-up angles
- QA: capture the current behavior first, then test the states you touch: loading, success, error, editing, saving, and navigation.