MVVM in SwiftUI for a Better Architecture

Apple is creating significant friction against using MVVM—for instance, both SwiftData and AppStorage only work in a view—which makes me doubt its long-term maintainability

SwiftUI's views are already view models, they describe how the actual view should look like.

The tragedy is that SwiftUI does not offer any testing instruments besides UI testing.

> I believe Redux-like architectural patterns […] are a terrible choice. They impose functional programming paradigms onto a language and a framework that are not functional but heavily reliant on imperative code and state.

Ehh… Redux shipped on JS… which was less functional than Swift is. Redux state ships on JS objects and has to work around mutable JS collection objects to preserve "immutable" value semantics. And after all that trouble it was still a better choice for managing global mutable state.

First class value types and immutable semantics in Swift make the language a solid choice for a Redux style architecture.

> The primary issue with this approach is that it concentrates the entire application state within a single monolithic structure, resulting in tightly coupled code.

Ehh… not really. One big goal of Flux and Redux was to decouple state from views. Because transformations on state are dispatched using declarative action values on user events views no longer need to know the structure and organization of state to perform imperative logic.

> Moreover, any change to the data in such a structure can trigger view updates across the entire view hierarchy, even in views unrelated to the updated state components.

This is just an implementation detail and an optimization to ship. A "hello world" Redux style SwiftUI application might lead to everything recomputing `body`. A production quality Redux solution for SwiftUI would probably leverage Selectors to "scope" slices of state similar to ReduxJS. That would mean that view components then only listen for updates from their slice… not the complete state tree.

The Redux community shipped this optimization almost ten years ago… there's nothing stopping engineers in the Swift community from shipping a Redux solution with a similar optimization.

> Another problem arises from reducers, which introduce substantial boilerplate code typically implemented using numerous Swift switches. This code blatantly violates the Open-closed principle.

Ehh… I'm not sure I see why structuring state transformations as pure functions is a net negative. Go ahead and critique the idea of pure function state reducers… but then we also go back and discuss the critiques for the idea of modeling state as mutable object references. It's a tradeoff… and engineers that ship Redux in their products see why this is the correct tradeoff for them.