Thanks for the response.

You can actually read my following opinion piece about barebone MVVM we use here.

I emphasis on the small and decoupled views and view models. The VM should stay small and do very little.

We actually also do use built in property wrapper, for local view state we do use @State and we have some injected environment too.

The key again is really about being small. A screen is a composition of small views and view models. The initial hosting controller will cascade into many different workers.

Most of our VM are actually store, and were called store for a while. They define a state, and this state is the only published property of the view model, the view will rely only on that. Everything else is function that update this state.