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!

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.

Part 2: But author examples, theories and people over engineering everything. SOLID, XP, TDD becomes one of the worst nightmares of a software development team.

I’m talking about all letters of SOLID. SOLID trys to borrows OOP and software design patterns but just over-complicate.. and sometimes becomes anti-pattern. e.g. The MVC, MVVM, MV are the S, in the model layer the WebService, Account, ProductStore are the S. We are separating / grouping the concerns. If we have social sign (Apple, Facebook, Google) and we make an SocialSignInService protocol and implement func signIn(service: SocialSignInService) async we are using others letters.

This is MV. Not using Active Record at all for data types but in fact an ObservableObject is (or can be) an Active Record at it nature. This is another approach where you call WebService directly from state (ObservableObject) and don’t use func / factories in data types / model.

There’s many ways we can do that, but be careful with “single responsibilities” and “separation of concerns”. All these is hurting projects and teams. Don’t over-engineering just because you read “Uncle Bob” SOLID book and the book tell you need to over complicate. From my 20 years of experience, SOLID principles are a cancer. Every SOLID based projects I know failed (delayed, not release, complex, not easy to do, not easy to test, not easy to fix, not easy to change, burnout team members).

Sorry but companies should fire obsessed people with testability & SOLID principles. In last years this obsession are the reason of problematic / complex software projects. 90% of tests (that some people talks) are unnecessary. Over-engineering are not good for you, your team , your company, your customer, your user. As software engineer you shouldn’t sacrifice the software design and simplicity for testability.

This is working o big & professional apps without problems. Again, the model are not only structs with properties. Example, StoreKit 2 is a model: Product / Transaction are part of the model, both have properties and logic (funcs and static factories). https://developer.apple.com/documentation/storekit/in-app_purchase

The first post of topic is “deprecated”, more focus on local and limited state. In other post I explain with examples. Also, before I tried to make a property wrapper + modifiers to handle some life cycle (of remote data) to avoid create “stores“ (ObservableObject) but failed, we can’t share and is too specific / limited. Local things we can use local state. Remote / life cycle / shared we should use ObservableObject. Again there’s no middle layer, that objects is part of your model.

“There’s a correlation between the increased reliance on automated testing and the decline in quality of software. Automated tests don’t ensure a quality product, human are most often better than automation. Frequently it can lead to more time being spent maintaining an automation suite than actually using it.” - Apple QA Engineer

“Developers obsessed with testability waste time with unnecessary code structures and dependencies, not vital to the core essence of building products. Some practices are not suitable for object-oriented projects.” - OMG

Managing complexity is the second most important responsibility of software developers. In the last 10 years software has become problematic and expensive… welcome to TDD / XP / SOLID world!

The problem is that we still need UIKit for some cases and sometimes not use some SwiftUI feature at all. Some things can easily be done today asap.

Yes, pull-down to refresh is available but only for List, in real world we use ScrollView with lazy stacks and grids.