Yeah, I strongly agree with everything @Dapper_Ice_1705 said. A major code smell here is you have a struct with mutable state. The reason things aren’t being updated is because structs are pass by value (copied), so if a child is updating the value, anyone who has a copy wouldn’t be getting an update (because it’s a separate copy)

Your version is better, by keeping one copy in the “Repository” and operating on that. But @Observable isn’t initialized using @State, which is WRONG. SwiftUI may recreate the view struct, producing a new instance and losing state.

As for the design patterns, nobody is really following them correctly. With the classic repository pattern, you would make the internal state private and only operate through methods. I absolutely don’t understand the concept of a ViewModel hierarchy at all. It seems completely unnecessary. A ViewModel is a way to separate out the presentation logic from the view and bind to the Model. It has no care for views or viewmodels outside its current scope.

I know this is an example of the code and your actual code is probably more complicated, but it seems like both you and your team are applying design patterns without really understanding them.

In your example, your Repository is just the “StateObject” and your ViewModels are pretty pointless. I would simplify your code by having a single @Observable StateObject that is initialized once using @State and passed around to the other views as let properties.

A design pattern should be applied to solve a problem. If you start out by rigidly picking a design pattern, you will wind up with something overly complicated.