Which all are class are not KVO compliant?

Question

Below two different paragraphs from Apple docs. In one paragraph, it says all class which inherits from NSObject to use KVO, is KVO compliant. In the second paragraph, it says not all classes are KVO compliant. Which are those classes which not KVO compliant? Is there any class which does not inherit NSObject? Whereas I know all inherit from NSObject.

It would ideal to give an example, to understand the difference between the two paragraphs.

To use KVO, first you must ensure that the observed object, the Account, in this case, is KVO compliant. Typically, if your objects inherit from NSObject and you create properties in the usual way, your objects and their properties will automatically be KVO Compliant. It is also possible to implement compliance manually. KVO Compliance describes the difference between automatic and manual key-value observing, and how to implement both.

and

Important: Not all classes are KVO-compliant for all properties. You can ensure your own classes are KVO-compliant by following the steps described in KVO Compliance. Typically properties in Apple-supplied frameworks are only KVO-compliant if they are documented as such.

Answer 1

For a property of an object to be KVO-compliant, the object must inherit NSObject and the object must also either:

• only update the property by using the property's setter method, or
• manually notify when it modifies the property.

Since you don't have the source code for Apple's frameworks, you cannot in general know whether an object of an Apple-provided class obeys either of these requirements, except by checking the documentation. If the documentation says a property is KVO-compliant, you know it complies. Otherwise, you don't know if it complies so it is not safe to use KVO on the property.

It's important to understand that a property might sometimes be updated in a KVO-compliant way, and other times in a non-compliant way. So you can't just do a simple test to decide! Your test might show that the property is KVO-compliant for the way you set the property, but it cannot show that the property is always updated in a KVO-complaint way.

For example, every UIView owns a CALayer, and many of the UIView's properties, including its frame, its bounds, and its backgroundColor are actually properties of that CALayer. When you get or set the property on the view, the view's accessor method just sends the message on to the layer. But you can also set the layer's property directly. So if you say view.bounds = someRect, the view probably will notify KVO observers. But if you say view.layer.bounds = someRect, the view will not notify KVO observers. But after either of these statements, view.bounds will return someRect.

So, you can only rely on a property to be KVO-compliant if you are responsible for the implementation of that property, or if the property is documented to be KVO-compliant.

Answer 2

Key-Value Coding and Key-Value Observing are both dependent on naming conventions to identify which accessor methods correspond to which properties.

If you use declared properties (using the @property keyword) and you don't override the accessor method names, then the accessor methods will comply with the naming conventions and KVC and KVO will be able to identify the methods associated with a key. If you override the method names or use informal properties, then you are responsible for complying with the naming conventions. (One common case for this is using getter=is<Key> for a boolean property. It's an overridden getter name, but it still complies with the naming conventions.)

In addition to using accessor methods with conventional names, a class must also actually use the accessors to modify its own properties in order to take advantage of automatic change notification. The class should not directly modify its instance variables (outside of init methods or -dealloc) or, if it does, it needs to use manual change notification for that property.

What the first quote you cite is saying is that you get a lot of automatic behavior from NSObject, assuming you follow the naming conventions and modify your properties via their accessors rather than instance variables. That's what "create properties in the usual way" is getting at.

What the second quote is saying is that you can't assume that Apple's own classes do that. In some cases because of historical implementation details and in general for flexibility, they reserve the right to make their classes' properties non-compliant. You must not assume that the properties are KVO compliant unless they are specifically documented to be so.