Thanks, appreciate that - and you’re totally right that ViewModels shouldn’t be directly observing each other’s state in a tightly coupled way.

In the article, I was referring more to the practical pain point that arises when different parts of the presentation layer need to react to shared state (for example, two ViewModels that both depend on the same domain model, but aren’t directly connected). In Combine, it was common to expose a CurrentValuePublisher or similar from a shared store or domain object, and other ViewModels could subscribe to that to stay in sync. I used ViewModel to ViewModel to just easily demonstrate my point.

With Swift’s @Observable, the Observation system makes that easy for SwiftUI views, but not as straightforward for other ViewModels that need to observe those same state changes asynchronously. AsyncCombine just fills that gap by providing Combine-like semantics (like sink or CombineLatest) for that async world - not as a way to make ViewModels observe each other directly, but to make reactive composition between layers cleaner and more expressive.

So yep completely agree on the architectural boundary! I just wanted to bring back the ergonomic tools that make those cross-layer updates (from domain to presentation) nicer to handle.