{"id":49860,"date":"2025-10-31T13:27:32","date_gmt":"2025-10-31T17:27:32","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=49860"},"modified":"2025-10-31T13:27:32","modified_gmt":"2025-10-31T17:27:32","slug":"swift-6-2-observations","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2025\/10\/31\/swift-6-2-observations\/","title":{"rendered":"Swift 6.2: Observations"},"content":{"rendered":"

Holly Borla<\/a>:<\/p>\n

Swift 6.2 enables streaming transactional state changes of observable types using the new Observations<\/code><\/a> async sequence type. Updates include all synchronous changes to the observable properties, and the transaction ends at the next await<\/code> that suspends. This avoids redundant UI updates, improves performance, and ensures that your code reacts to a consistent snapshot of the value.<\/p><\/blockquote>\n\n

As with notification center messages<\/a>, this is really part of the macOS 26 frameworks rather than Swift 6.2 itself.<\/p>\n\n

Donny Wals<\/a>:<\/p>\n

Sequences created by Observations<\/code> will automatically observe all properties that you accessed in your Observations<\/code> closure. In this case we’ve only accessed a single property so we’re informed whenever count<\/code> is changed. If we accessed more properties, a change to any of the accessed properties will cause us to receive a new value. Whatever we return from Observations<\/code> is what our async sequence will output. In this case that’s a string but it can be anything we want. The properties we access don’t have to be part of our return value. Accessing the property is enough to have your closure called, even when you don’t use that property to compute your return value.<\/p>

[…]<\/p>

When iterating over our Observations<\/code> sequence we’ll receive values in our loop after<\/em> they’ve been assigned to our @Observable<\/code> model. This means that Observations<\/code> sequences have “did set semantics” while withObservationTracking<\/code><\/a> would have given us “will set semantics”.<\/p><\/blockquote>\n\n

Keith Harrison<\/a>:<\/p>\n

\n

The updates are transactional so multiple synchronous changes arrive as a single updated value.<\/p>\n<\/blockquote>\n\n

SE-0475<\/a>:<\/p>\n

\n

Observation was introduced to add the ability to observe changes in graphs of objects. The initial tools for observation afforded seamless integration into SwiftUI, however aiding SwiftUI is not the only intent of the module - it is more general than that. This proposal describes a new safe, ergonomic and composable way to observe changes to models using an AsyncSequence, starting transactions at the first willSet and then emitting a value upon that transaction end at the first point of consistency by interoperating with Swift Concurrency.<\/p>\n

[…]<\/p>\n

This proposal does not change the fact that the spectrum of APIs may range from\nfavoring AsyncSequence<\/code> properties to purely @Observable<\/code> models. They both\nhave their place. However the calculus of determining the best exposition may\nbe slightly more refined now with Observations<\/code>.<\/p>\n<\/blockquote>\n\n

Jared Sinclair<\/a>:<\/p>\n

Apple has effectively deprecated the reigning paradigm of the ObservableObject<\/a> protocol and @Published<\/a> properties observed via the Combine framework, but they’ve only partially provided its replacement via the @Observable<\/a> macro and the withObservationTracking<\/a> free function. The gaps between the old way and the new way are worth careful consideration.<\/p>

[…]<\/p>

Observations is an Apple-provided way for one object to subscribe to long-running changes to some other, @Observable-macro’ed object. It is written to use the AsyncSequence protocol<\/a>. Despite the fact that withObservationTracking<\/code> was released in OS 17, Observations has not been back-ported and requires OS 26.<\/p>

[…]<\/p>

To implement cancellation you need to wrap the entire thing in a Task, store that task in an instance variable, and determine key points in the lifecycle of your object to cancel that task[…]<\/p>

[…]<\/p>

It is important that your Task<\/code> and your Observations<\/code> structs weakly-capture both self<\/code> and whatever object you’re trying to observe. But it’s still easy to get it wrong.<\/p>

[…]<\/p>

You can’t access a mutable var<\/code> property from the deinit. You would need to wrap that property in some kind of synchronization box, like a Mutex<\/a>, which comes with its own kinds of hassles and boilerplate.<\/p><\/blockquote>\n\n

Combine was much more succinct, but it seems like this API is a work in progress so it may get better next year.<\/p>\n\n

Paul Hudson<\/a> (Mastodon<\/a>, Hacker News<\/a>):<\/p>\n

\n

There are a handful of important usage notes you should be aware of when using Observations<\/code>:<\/p>\n

    \n
  1. It will emit the initial value as well as all future values.<\/li>\n
  2. If multiple changes come in at the same time, they might be coalesced into a single value being emitted. For example, if our Task<\/code> code incremented score<\/code> twice, the values emitted would go up in 2s.<\/li>\n
  3. The AsyncSequence<\/code> of values being emitted can potentially run forever, so you should put it on a separate task or otherwise handle it carefully.<\/li>\n
  4. If you want iteration to stop – to end the loop – you should make the value being observed optional, then set it to nil.<\/li><\/ol>\n<\/blockquote>\n\n

    Lucas van Dongen<\/a>:<\/p>\n

    \n

    I built a simple demo app<\/a> with both the new and existing stuff.<\/p>\n<\/blockquote>\n\n

    Previously:<\/p>\n