Correct, my fault, sorry. It’s 2020 session when SwiftUI bring @StateObject.

I don’t know Vue but reading Apple docs / sessions yes theres a local state inside the View and a external state (for complex, management / life cycle, shared) using ObservableObject. As someone said, SwiftUI is not necessarily MVVM but something else that is part of your model.

Sorry for late response, I don’t made a feedback yet

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

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.

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!

“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

“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

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.

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

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.

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

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.

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.

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.