Discussion

MV vs MVVM for SwiftUI

Model-View-ViewModel (MVVM) became a commonly proposed architecture for SwiftUI. However, in practice, the use of this pattern may lead to unwanted complexity of the codebase. The architecture forces you to make view as dumb as possible and ViewModel as smart as possible. So you may find yourself in a position of thinking that you are fighting the framework. And it is true. In SwiftUI the implementation of the View component contains support for bindings through the utilization of the @State property wrapper. This feature obviates the necessity for the implementation of a separate ViewModel, as the View effectively serves as a ViewModel.

On the other hand, in the Model-View (MV) architecture the Model stores and process data, while View binds to this model and renders updates to the user. This approach effectively utilizes the advantage of the inherent characteristics of the framework, leading to a seamless and intuitive development experience.

Sometimes you can find cases where Model entity does the same work as ViewModel would do, but the main difference is that this Model entity is reusable, independent and not coupled with the specific view/screen. Therefore, it could be effectively utilized by multiple View entities. In the MV pattern Model and View maintain M-to-M relationship, while in the MVVM pattern ViewModel and View are in 1-to-1 or in some cases could be in 1-to-M relationship.

Network calls inside Data Model

When trying to understand the architecture it may seem bizarre that Data Models could have a network calls inside them, but this is totally natural and fine. Also they do not contain any of additional logic around these calls, they just provide an interface of how you can manipulate with this data object. Of course, you should factor out any networking work, such as building and performing requests, into independent service object to avoid code repetition and growing complexity.