I disagree with a few points in this article, and can provide clarification on a few others. The clarifications first:<p>Bindings don't exist in Cocoa Touch because they're either slow (e.g. computed properties like @sum) because they're mostly stateless, or memory intensive because... well, dig into the internals of KVO sometime - there are a huge number of caches to try to keep things fast. It's not because KVO is a bad API. Heck, the KVO side of bindings is never exposed at all.<p>On the topic of infinite loops, yes, you have to be careful not to change an affecting property within an -observeValue... but it's hardly unknowable what changes will cause a KVO notification. Indeed, it's an isomorphic problem to breaking retain cycles, something every Obj-C programmer has to worry about every day, yes, even with ARC. The information is just stored in a different place, namely +keyPathsForValuesAffecting<Key> methods, rather than in property or ivar declarations. One can create a "weak" notification by removing oneself as an observer in the -observeValue, optionally adding oneself back at the end.<p>As for disagreements:
KVO is not the old way. NSNotificationCenter and the delegate pattern predate KVO. Callback blocks don't, and indeed where possible I'd recommend all of the above over KVO, but it's hardly ancient, and certainly not "the old way". It's just a different way that allows you to watch for changes that doesn't require the designers of an API to have provided hooks for you to do so explicitly.<p>On its implicitness, I can't agree that it's any more implicit than delegates. The same criticism that you can't command-click in Xcode to follow the code flow applies. Same thing with NSNotifications for that matter. That's kind of the point. If it was all explicit, we wouldn't have the dynamism that all of these mechanisms provide.<p>Re: "An important thing to note is that KVO will throw an exception and crash our app if we try to remove the same observer twice." This is simply untrue. KVO will throw an exception and crash the app if you try to remove the same <i>observance</i> twice, but an observance is created each time you call -addObserver:.... That is, like retain and release, -addObserver: and -removeObserver: calls need to be balanced. Additionally, the author actually misses a part where KVO really is broken: "[Using a static context pointer per observation] helps to make sure that none of our super- or subclasses can deregister us from being an observer." doesn't actually work. Using -removeObserver:forKeyPath: will happily remove the first observance it comes across (the first that was registered, AFAICT, though this isn't documented), regardless of its context; it's not just a convenience method for -removeObserver:forKeyPath:context: that passes NULL for the last parameter.<p>Lastly, it seems quite silly to have a unique context for each object and key path per class. If they're going to unique the contexts, you don't need to check objects and key paths. Or, you only need one context per class, and then only if your inheritance tree does include multiple observing classes. On a related note, I think the complaint about having to call super if the superclass implements -observeValue... is ridiculous. This is how any method that might be implemented at multiple levels of an inheritance tree must be called. Same thing with a delegate whose superclass also conforms to that delegate protocol. Or -init. Or -dealloc. Or...<p>.<p>All that said, I still generally agree with the conclusions about when to use KVO, although is #3 is just a subset of #1, and I wouldn't have phrased it as the author did (see the first paragraph of disagreement). I'd also add #4: Use KVO when you need the old values as well as the new values of the objects, and/or need to be notified prior to the value changing. NSNotificationCenter and delegates can do the same thing, but at the cost of double the number of methods that need to be written, and you'll have to store the state yourself if you need the old value at the same time as the new value. That's a lot of code that gets abstracted away by KVO, particularly if you're observing multiple key paths on the same object and need all their old and new values. Code you don't have to write is code you don't have to debug.