Remember: Some agile practices (TDD, XP, …) becomes a culture of terminal juniority, there’s no place for an actual senior engineer. Seniors think & design software before writing the code... we are engineers. My experience (from different teams) in obsessed agile world: no one knows what to do and how to do, lack of minimal specs, everything becomes problematic and complex, expensive projects, delayed or cancelled projects, upset team members, difficult to scalability and maintenance, …

MV, Store pattern, Flux pattern, … SwiftUI, Vue, React, … all the some concept / principles, just don’t forget that SwiftUI can have an internal state (properties inside View) unlike other platforms.

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!

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!

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

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.

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

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.

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.

Data Essentials in SwiftU

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.

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.

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

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!

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