> And incidentally, I've used startObservation() in places, and it's crippled by another idiotic design choice: It only works once. It reports the first change,

> And incidentally, I've used startObservation() in places, and it's crippled by another idiotic design choice: It only works once. It reports the first change, and then never another one. So in the onChange closure, you have to re-start the observation. Every goddamned time. The restart is there in my example, and it doesn't look too complex. And this aspect of observation is exactly what will be changed in Swift 6.2. Nice improvement, I'd say! > I disagree, because the model hasn't changed yet. That's the crippling aspect to it: You can't tell some controller object to recompute its state based on a change to another object in the model, because you're getting notified BEFORE that object has changed. If your model stores 2 interdependent states then you'll risk running into infinite update loop regardless of whether you've been notified from `didSet` or `willSet`. It can be fixed by changing the model. To be fair I didn't understand your example with camera and resolution. In all cases you already know the new value and so the dependent code is good to go. The code shouldn't ever care where the value comes from: the main state, the future state, or some mock state.