Utilizing Observations to watch @Observable mannequin properties – Donny Wals

Beginning with Xcode 26, there is a new approach to observe properties of your @Observable fashions. Prior to now, we had to make use of the withObservationTracking operate to entry properties and obtain adjustments with willSet semantics. In Xcode 26 and Swift 6.2, now we have entry to a completely new strategy that may make observing our fashions outdoors of SwiftUI a lot easier.

On this publish, we’ll check out how we will use Observations to watch mannequin properties. We’ll additionally go over a few of the potential pitfalls and caveats related to Observations that you have to be conscious of.

Establishing an statement sequence

Swift’s new Observations object permits us to construct an AsyncSequence primarily based on properties of an @Observable mannequin.

Let’s think about the next @Observable mannequin:

@Observable 
class Counter {
  var depend: Int
}

As an example we would like to watch adjustments to the depend property outdoors of a SwiftUI view. Possibly we’re constructing one thing on the server or command line the place SwiftUI is not obtainable. Or perhaps you are observing this mannequin to kick off some non-UI associated course of. It actually would not matter that a lot. The purpose of this instance is that we’re having to watch our mannequin outdoors of SwiftUI’s computerized monitoring of adjustments to our mannequin.

To observe our Counter with out the brand new Observations, you’d write one thing like the next:

class CounterObserver {
  let counter: Counter

  init(counter: Counter) {
    self.counter = counter
  }

  func observe() {
    withObservationTracking { 
      print("counter.depend: (counter.depend)")
    } onChange: {
      self.observe()
    }
  }
}

This makes use of withObservationTracking which comes with its personal caveats in addition to a fairly clunky API.

Once we refactor the above to work with the brand new Observations, we get one thing like this:

class CounterObserver {
  let counter: Counter

  init(counter: Counter) {
    self.counter = counter
  }

  func observe() {
    Job { [weak self] in
      let values = Observations { [weak self] in
        guard let self else { return 0 }
        return self.counter.depend 
      }

      for await worth in values {
        guard let self else { break }
        print("counter.depend: (worth)")
      }
    }
  }
}

There are two key steps to observing adjustments with Observations:

1. Establishing your async sequence of noticed values
2. Iterate over your statement sequence

Let’s take a more in-depth take a look at each steps to know how they work.

Establishing an async sequence of noticed values

The Observations object that we created within the instance is an async sequence. This sequence will emit values each time a change to our mannequin’s values is detected. Notice that Observations will solely inform us about adjustments that we’re really taken with. Which means that the one properties that we’re knowledgeable about are properties that we entry within the closure that we go to Observations.

This closure additionally returns a price. The returned worth is the worth that is emitted by the async sequence that we create.

On this case, we created our Observations as follows:

let values = Observations { [weak self] in
  guard let self else { return 0 }
  return self.counter.depend 
}

Which means that we observe and return no matter worth our depend is.

We may additionally change our code as follows:

let values = Observations { [weak self] in
  guard let self else { return "" }
  return "counter.depend is (self.counter.depend)"
}

This code observes counter.depend however our async sequence will present us with strings as an alternative of simply the counter’s worth.

There are two issues about this code that I might wish to concentrate on: reminiscence administration and the output of our statement sequence.

Let’s take a look at the output first, after which we will discuss concerning the reminiscence administration implications of utilizing Observations.

Sequences created by Observations will routinely observe all properties that you simply accessed in your Observations closure. On this case we have solely accessed a single property so we’re knowledgeable each time depend is modified. If we accessed extra properties, a change to any of the accessed properties will trigger us to obtain a brand new worth. No matter we return from Observations is what our async sequence will output. On this case that is a string however it may be something we would like. The properties we entry do not need to be a part of our return worth. Accessing the property is sufficient to have your closure known as, even when you do not use that property to compute your return worth.

You’ve gotten most likely seen that my Observations closure comprises a [weak self]. Each time a change to our noticed properties occurs, the Observations closure will get known as. That implies that internally, Observations must one way or the other retain our closure. Because of that, we will create a retain cycle by capturing self strongly within an Observations closure. To interrupt that, we should always use a weak seize.

This weak seize implies that now we have an elective self to cope with. In my case, I opted to return an empty string as an alternative of nil. That is as a result of I do not need to need to work with an elective worth in a while in my iteration, however if you happen to’re okay with that then there’s nothing incorrect with returning nil as an alternative of a default worth. Do notice that returning a default worth doesn’t do any hurt so long as you are organising your iteration of the async sequence appropriately.

Talking of which, let’s take a more in-depth take a look at that.

Iterating over your statement sequence

As soon as you have arrange your Observations, you have got an async sequence that you may iterate over. This sequence will output the values that you simply return out of your Observations closure. As quickly as you begin iterating, you’ll instantly obtain the “present” worth to your statement.

Iterating over your sequence is completed with an async for loop which is why we’re wrapping this all in a Job:

Job { [weak self] in
  let values = Observations { [weak self] in
    guard let self else { return 0 }
    return self.counter.depend 
  }

  for await worth in values {
    guard let self else { break }
    print("counter.depend: (worth)")
  }
}

Wrapping our work in a Job, implies that our Job wants a [weak self] similar to our Observations closure does. The reason being barely totally different although. If you wish to be taught extra about reminiscence administration in duties that include async for loops, I extremely advocate you learn my publish on the subject.

When iterating over our Observations sequence we’ll obtain values in our loop after they have been assigned to our @Observable mannequin. Which means that Observations sequences have “did set semantics” whereas withObservationTracking would have given us “will set semantics”.

Now that we all know concerning the completely happy paths of Observations, let’s speak about some caveats.

Caveats of Observations

While you observe values with Observations, the primary and predominant caveat that I might wish to level out is that reminiscence administration is essential to avoiding retain cycles. You’ve got realized about this within the earlier part, and getting all of it proper may be difficult. Particularly as a result of how and if you unwrap self in your Job is crucial. Do it earlier than the for loop and you’ve got created a reminiscence leak that’ll run till the Observations sequence ends (which it will not).

A second caveat that I might wish to level out is that you may miss values out of your Observable sequence if it produces values sooner than you are consuming them.

So for instance, if we introduce a sleep of three seconds in our loop we’ll find yourself with missed values once we produce a brand new worth each second:

for await worth in values {
  guard let self else { break }
  print(worth)
  strive await Job.sleep(for: .seconds(3))
}

The results of sleeping on this loop whereas we produce extra values is that we’ll miss values that have been despatched through the sleep. Each time we obtain a brand new worth, we obtain the “present” worth and we’ll miss any values that have been despatched in between.

Often that is positive, however if you wish to course of each worth that received produced and processing would possibly take a while, you may need to just remember to implement some buffering of your individual. For instance, if each produced worth would end in a community name you’d need to just remember to do not await the community name within your loop since there is a good probability that you simply’d miss values if you try this.

General, I believe Observations is a big enchancment over the instruments we had earlier than Observations got here round. Enhancements may be made within the buffering division however I believe for lots of purposes the present scenario is nice sufficient to present it a strive.