objectWillChange.send() is the core of ObservableObject notification, @Published is an convenience and use it.

Currently I’m working on big SwiftUI project, multi model, and I can tell “Active Record pattern” (data access) and “Store pattern” (state, source of truth) + @EnvironmentObject are our best friends.

Yes everything will be in model and model should not be POJOs. Inside model we can separate the things like Data, Network, Database, State / Stores. We have many patterns for data access (active record, data mapper, repository, …). You can call the stores / state as ViewModels and not using MVVM. The “MVVM pattern” becomes problematic (and unnecessary) with declarative UI frameworks (SwiftUI, Flutter, React, …).

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.

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.

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.

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.

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)

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.

“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.

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.

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.

Welcome! 👍

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

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.