15

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.

This statement leaves me confused. Can't we use KVO for UIKit objects at all? I don't remember seeing any property being documented as KVO compliant. Despite saying otherwise, I am able to use KVO with many properties. Does this mean that I can't rely on it?

Any insight into this would be appreciated.

Deepak Danduprolu
  • 44,595
  • 12
  • 101
  • 105

1 Answers1

10

UIKit is mostly NOT KVO compliant. This is mostly because UIView acts as high-level wrapper for CALayer, so when you eg. change the frame property of an UIView, it will change the layers frame but leave eg. the bounds property of the UIView untouched, so no observer will be triggered for the view.bounds path, because it never really changes. And this leads to non KVO compliance.

Only if the property is marked as KVO compliant can you rely on this, otherwise it will not work or break in some weird cases.

Paxic
  • 1,760
  • 16
  • 28
JustSid
  • 25,168
  • 7
  • 79
  • 97
  • The UIView's frame is not a stored itself as a value. The UIView stores the bounds and the centerpoint. If asked for "frame" UIView computes the frame from bounds and centerpoint values. – MacMark Sep 22 '11 at 13:36
  • I do fully understand the given reasoning but still UIView frame seems to properly be KVO compliant and that **really** confuses me. – Till Oct 17 '12 at 21:22
  • @Till Mhhh, maybe Apple has changed the implementation details in the newer iOS versions? I don't know, as far as I remember this didn't work at the time I was writing that answer. – JustSid Oct 17 '12 at 23:37