Commenting on this post on LinkedIn: https://www.linkedin.com/posts/jacobmartinbartlett_the-biggest-problem-with-swiftui-is-that-activity-7261769674034409472-qGVe?utm_source=share&utm_medium=member_desktop
I replied with:
*The "Massive View Controller" was never a problem if you understood that the "Model" of MVC was supposed to include all business logic.
The issue occurs because people keep only data modelling, without any logic in the "Model" layer and move all business logic into the "Controller" layer.
Ofcourse if you do the same in SwiftUI you are going to end up with Massive SwiftUI Views.
Your app logic and business should be agnostic, as much of possible, from the UI layer. You should be able to swap your UIKit interface for a SwiftUI interface, or a command line interface, with minimum changes to your app.
If you aren't able to do that, it's not UIKit or SwiftUI the issue, but your own understanding of how it's supposed to work. We don't need to invent MVVM, TCA, VIPER or any other complex architecture to handle that properly.*
Asking ChatGPT:
If you ask ChatGPT, it comes up with the following definition for the Model of the MVC on Apple platforms:
In Apple's implementation of the Model-View-Controller (MVC) design pattern, the Model component is responsible for managing the application's data and business logic. It encapsulates the core information and defines the rules for manipulating that data. This includes tasks such as data persistence, networking, and data parsing. The Model operates independently of the user interface, ensuring that changes in the data do not directly affect the presentation layer. This separation promotes modularity and reusability within the application architecture.
In this old document from Apple: https://developer.apple.com/library/archive/documentation/General/Conceptual/DevPedia-CocoaCore/MVC.html
Apple’s way:
We can find the following:
Model Objects
Model objects encapsulate the data specific to an application and define the logic and computation that manipulate and process that data. For example, a model object might represent a character in a game or a contact in an address book. A model object can have to-one and to-many relationships with other model objects, and so sometimes the model layer of an application effectively is one or more object graphs. Much of the data that is part of the persistent state of the application (whether that persistent state is stored in files or databases) should reside in the model objects after the data is loaded into the application. Because model objects represent knowledge and expertise related to a specific problem domain, they can be reused in similar problem domains. Ideally, a model object should have no explicit connection to the view objects that present its data and allow users to edit that data—it should not be concerned with user-interface and presentation issues.
Communication: User actions in the view layer that create or modify data are communicated through a controller object and result in the creation or updating of a model object. When a model object changes (for example, new data is received over a network connection), it notifies a controller object, which updates the appropriate view objects.
Looking at this definition, I can see why there might be confusion. It's not very clear where the object gets modified. There's a mention of "User actions" that are somehow communicated through a controller object, leading to the "updating of a model object"... but where is the code that updates the model object? Is it in the model, the controller, or maybe in the user action itself?
Considering what we know about the "Massive View Controller" problem, putting the code to modify the model object in the controller will likely make the controller objects too complex.
So if we are to understand the intent, it would be:
to create a struct or object that represents the User Action itself
forward the User Action object via the controller to the model
model processes the User Action and creates or updates the model objects.
model updates notifies the controller, which then updates the view
What lead to Massive View Controller then?
Based on my experience, developers under used Views. Very often colors, fonts, spacing are all implemented in the controllers. Mistake number 1.
The MVC, intended for views to implement all aspects of their designs. This particular quote from Apple is telling:
A view object knows how to draw itself and can respond to user actions.
I have seldomly, if ever, seen a custom UIView in a project handling user actions. Usually you would have the view expose some IBActions and have the controller setup observers and handlers. Based on Apple’s documentation, if a view has a login form, it should forward to the controller a SignIn user action that contains the username and password. However, developers would typically connect the “Sign In” IBAction, and from the controller they would manually fetch the username and passwords from the textfields, etc. Mistake number 2.
As previously discussed, the model was intended to have all the model object creation and updates mechanisms. It’s fairly typical to have the controller perform the modifications based on the setup IBAction handler. Whereas it was originally intended to only forward the User Action to the model. Mistake number 3.
With this trifecta of mistakes, the controller keeps having more and more responsibility, which lead to developers coming up with a “ViewModel” (in MVVM) to play what was originally intended to be the controller’s role. Or in VIPER the Interactor and Presenter.
Effects for SwiftUI
In a system where MVC is developed as intended by Apple, SwiftUI takes on the role of the View and Controller all in one. Since the controller was mostly intended in converting the Model data into View data, and forwarding User Actions (not implementing the processing), removing the controller has the following impact:
- SwiftUI is set to receive Model data updates, and send User Action to the Model layer.
Would this lead to Massive SwiftUI views? No. The end result is MV - Model-View, and your View should be relatively lightweight.
