There’s nothing wrong with MVVM. SwiftUI is modern, declarative and data-drive nature, also automatically do many VM / Controller tasks. MVVM is old, imperative + binding and event-driven. I’m just following the SwiftUI nature. You call Book (Model) and BookVM (ViewModel). I call Book and BookStore, both model objects. At the end is the same but with different names and layers.

You call Book (Model) and BookVM (ViewModel). I call Book and BookStore, both model objects. At the end is the same.

Just follow SwiftUI data-driven approach and everything will works. If you see my projects maybe you call VMs to my functional / state objects (store, context, …), the concept of MVVM changed in last years for non-Windows platforms. At the end I just focus in model objects with data, logic and other things and following the SwiftUI concepts.. no middle layer. My models includes all kind of non-UI objects (entities, stores, managers, …), MVVM models is just entities and logic move to ViewModel.

For this case you can define an User.formattedBirthday (or User.displayBirthday, or …) instance computed property. Or just use the Text(user.birthday, format: …). In many cases you can extend the DataFormatter with your custom formats.

Hi, you can pass on load(userId), more likely for this case, or define a BookStore.userId instance property.

Welcome! 👍

It’s ok if all that stores are shared from root view to deep views. But we try as possible to assign a store where is needed. If the store is only needed in one view we should keep only on that view, if a store is shared on 2 ou more views we should set as EnvironmentObject (some times as ObservedObject) on the point of hierarchy that makes sense. There’s no rules, only your views needs.

Yes, SwiftUI View have freedom to use one or more "Stores" (or source of truths). SwiftUI View has many-to-many relationship, MVVM View has one-to-one (in some cases many-to-one). Also theres lots free features, e.g. using Core Data we almost don’t need na “Store” object.

“Classic MVVM architecture” -> old and not the most correct & modern architecture. And you can use classic MVC with SwiftUI too. Many people use ViewModels (presentation logic) for presentation & business logic. We can (and should, as Apple Engineer said) use SwiftUI View locals for presentation logic and the ObservableObjects for business logic, in some situations (navigation) we could need an ObservableObject for presentation logic, but again.. this is not MVVM.

It’s ok 👍- if SwiftUI don’t complaint - also you can read “SwiftUI Architecture - A Complete Guide to MV Pattern Approach” by AzamSharp, there’s 2 (using internal and external state) examples of inputs and field validation.

Apple use ECS for GameplayKit. It’s great for Games but don’t see it in Apps today (in future with proper system framework I don’t know)

As I said before we can do all the work in the stores (SOT) and keeping Channel and Movie plain (only properties). Personally I use Active Record to separating the data access from Source of Truth. Also I have cases that I use the some data object factory method in multiple store. And some different but related project that use the some web services (data access) but not the Source of Truths (stores). Active Record works great for library / frameworks and integration tests.

With small data set you can have favorite channels in your Account object. Also you can remove subscription plans from Account and have a SubscriptionStore. We do what makes sense for our business. But just remember: ObservableObject is a Source of Truth, part of our model, not a ViewModel.

Registration and other objects are Source of Truths, model objects, part of our model. That objects are independent from a specific view and this is one important difference from MVVM. I see, from other platforms some people use the name VM for the “Source of Truth” (shared, view independent, …) but this is not MVVM. Also we can’t share a state using true MVVM, for SwiftUI (and other declarative platforms) EnvironmentObject is key for many use cases and situations.

Registration, ChannelStore, MovieStore, Account… are not ViewModels, but in some cases can feel like. MVVM (old tech) requires a middle layer and one ViewModel for each View. ViewModel is the state and handle tasks for that View. In my Movies example if you use MVVM you will implement a MovieListVM, MovieRowVM, MovieGridVM, MovieCardVM. SwiftUI View is a ViewModel, have local state, you can handle events inside, … you only need to give to View the Source of Truth(s). I only have a MovieStore.