Don't Call willChangeValueForKey Unless It's Really Needed
You’re using KVO, right? So you most likely already have written code like this:
Carefully encapsulating your calls within a willChangeValueForKey/didChangeValueForKey call to “enable” KVO. Well, turns out, you just did shit work. There’s no reason to do the will/did dance, as long as you are using a setter method to change the ivar. It doesn’t need to be backed by an ivar or declared as a property. KVO was written long before there was anything like @property in Objective-C.
In fact, I am now writing iOS apps for about 4 years and didn’t know this. A lot. of. open. source. code. also gets this wrong. Apple has some good KVO documentation, where they explain the concept of Automatic Change Notifications.
There is a reason why you want to manually add willChangeValueForKey, most likely changing a variable also affects another variables. The most popular example is NSOperation:
Sometimes you also might wanna optimize how often you’re sending KVO notifications with overriding automaticallyNotifiesObserversForKey: to disable automatic change notifications for certain properties.
In this example, there might be expensive KVO observations when the image changes, so we wanna make damn sure that KVO is only fired if the image actually is a different one to the already set image:
If you currently have such obsolete calls, they’re not doing any harm. Incrementally called willChangeValueForKey doesn’t emit more notifications. Still, time to delete some code!
Update: Don’t forget that there are more ways that’ll save you manual calls to will/did, like using the little known addition keyPathsForValuesAffecting(PropertyName), which uses some runtime magic to make KVO smarter. Here’s a real-life example how I used that on AFNetworking, so people can register a KVO notification on “isNetworkActivityIndicatorVisible” and it’ll get sent every time activityCount is changed. (You’ll also see that I do some atomic updating that requires manual KVO.)