Open Radar

 
KVO is itself neither good nor bad, but in practice it's difficult due to a lack of safe expectations. Some APIs document properties that cannot be observed, others do not. The only current safe approach is to only KVO properties that are explicitly documented as supported and properties within your own code.

I propose instead:

@property (kvoable, nonatomic, strong) id foo;

and

@property (nonkvoable, atomic, weak) id bar;

First and foremost, this would provide explicit documentation in code of what expectations are safe to make in terms of KVO. Furthermore, it allows for static and runtime checks to be added that would improve code quality across the board. Two easy examples: @dynamic properties can emit a warning when nonkvoable is not set and  (assuming kvoable is the default, which matches current behaviour), and the KVO mechanism itself can provide feedback at runtime if a property is improperly observed.