On Apple platforms, MVC reigned supreme for decades.

Only SwiftUI changed the default approach.

MVC as a structural pattern consists of three eponymous pieces:

1. Model: In the most practical sense, any data to bring on screen. Could be mutable by the user, or static.

2. View: In the strictest sense, the NSView or UIView subclass that draws pixels on screen to somehow visualize the model.

3. Controller: Tells the view how to display the model, and tells the model how to change based on inputs in the view.

With this setup, you can create interactive applications, forms, news readers – it scales pretty well in principle.

Controller Bloat

MVC gets annoying in practice, though, when the Model is identified as database entities from an ORM, or Core Data, and when the Controller’s complexity explodes to customize the UI, handle drag and drop, pasteboards, key events, validate inputs, and handle errors. There’s a lot that can be “controlled”.

Some remedies include:

• Separating a true “Domain Model” from dumb data representations for the view, aka “View Model”. See MVVM for an aproach that goes all-in on that.
• Extracting other Services from the Controller, e.g. to handle network requests separately, or to take care of routing.

Posts on the topic