Explain UIKit MVC and the Massive View Controller problem

WHAT THIS TESTS This checks foundational architecture knowledge and self-awareness about a well-known anti-pattern. It reveals whether you can both define MVC precisely and diagnose why real UIKit code drifts toward bloated controllers.

A GOOD ANSWER COVERS In classic MVC the Model holds application data and business logic and is independent of the UI. The View presents information and captures user interaction but holds no business logic. The Controller sits between them: it observes or pulls from the model, configures the views, and translates user actions back into model updates. In Apple's Cocoa MVC the controller, typically a UIViewController, is the mediator and owns the view hierarchy. The Massive View Controller problem arises because the view controller is the most convenient place to put everything, so networking calls, JSON parsing, data source and delegate methods, navigation, and formatting all pile in, producing files of thousands of lines that are hard to test and reuse. Good answers note this is misuse, not a flaw of MVC, and describe relief valves: move presentation logic into view models, networking into service objects, table behavior into separate data source types, and decompose screens into child view controllers.

COMMON WRONG ANSWERS Saying the View talks directly to the Model in Cocoa MVC. Declaring MVC obsolete and that you must use MVVM. Confusing the controller's mediation role with owning business rules.

LIKELY FOLLOW-UPS How does MVVM reduce the problem? Where do networking and parsing belong? Can the model notify the controller, and how? How does this affect testability?

ONE CONCRETE EXAMPLE A profile screen's view controller fetches the user over the network, decodes JSON, formats dates, conforms to UITableViewDataSource and UITableViewDelegate, and handles navigation, swelling to two thousand lines. Refactoring moves the fetch into a UserService, decoding into a Codable model, formatting into a ProfileViewModel, and the table behavior into a dedicated data source, shrinking the controller to coordination only and making each piece unit-testable.