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, …).

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.

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

State -> model / business / use case(s) / functionality / life-cycle object, view independent. ViewModel -> middle layer, data / state / functionality for a specific view, view dependent.

Our example (FileManagement object) use case (view / platform independent): Client / user needs an app to view folders, view all files from a selected folder and view file details, also can change some file attributes, create / delete files. Yes you can split “FileManagement” (FileStore, FolderStore, local selects) if needed or makes sense. Making apps has never been so easy!

You can find on the Medium an article about that “Detecting changes to a folder in iOS using Swift” also using SwiftUI.

The file system management is not a great example for state / store. Typically we work in local (disk) and not in memory, we use the FileManager (and a “FileWatcher”) and work with URLs and Data + Attributes dictionary. But ok to have a struct representation of folder and file, or doing a virtual file system.

var favourites is a computed property, in this case to reflect the changes you can put the (or an) setFavourite in the store and after attribute / reference change call objectWillChange.send(). You shouldn’t have a reference of store from struct. Yes active record, repository, … pattern are more for libs or an data access model layer of your app if needed. In declarative UI we need a state.

Data Essentials in SwiftU

You can use await / async on iOS 13. When it was originally announced, Swift concurrency required at least iOS 15 but with Xcode 13.2 you can deploy to iOS 13.

I understand you but I think next year (hope!) Core Data will be replaced by something new, modern, Swifty. @FetchedRequest has limitations and we can’t share in view hierarchy. I see it as a local view state for local data. e.g. Mail, Notes, Reminders, Recipes apps you can use an ObservableObject to sync & process data from remote and use @FetchedRequest to display that data. Maybe we need, in the system, an ObservableObject subclass object to store & handle db fetch request.

If SOLID works for your team is because you are not following SOLID. Maybe you are using OOP with design patterns where need.

In my personal opinion and 20 years of experience in software engineering, developers should stop following SOLID and Clean. As a team leader I also don’t recommend any developer with SOLID / Clean / Testability talk in the interviews. They will make complexity and problematic software, all has a cost for the company.

I posted some others examples in this topic. Is really easy to understand why SOLID and Clean Architecture becomes a big problem to companies. A picture is worth a thousand words. Sorry but anyone, also my dog, can see the difference. Example #1 Example #2

Is a small project, with a small estimation. The SOLID team wasted time with many layers, abstractions, protocols, objects, also refactoring the thinks because is not ok, any change they need to refactoring the code. Also they use MVVM and fight the system in many ways. I can’t show you but the SOLID project was 10x more code files, 20x code. You know, this is very common for a SOLID project!