If the object may come in a mutable variant (like NSString has NSMutableString), use
copy, so that you don’t end up holding a mutable object that somebody mutates while you’re holding it.
If you will own the object, use
strong. (Optionally, leave it out, because
strongis the default for objects.)
If the object will own you, use
weak. For example, a table view weakly references its data source and delegate, because they are very often the VC or WC that indirectly owns the table view.
If the object cannot be referenced with a true
unsafe_unretained. A select few classes*, such as NSTextView, do not support weak references. You will get an exception at run time if you try to establish a weak reference to such an object. You will have to use
weakis preferable is because, if the object dies while being weakly referenced, the weak references automatically get changed to
nil. That’s also the part that certain classes are allergic to.
unsafe_unretaineddoesn’t have this feature, which is why the classes that don’t support
weakcan still be referenced with
unsafe_unretained—but, the caveat is that if you use
unsafe_unretained, you must ensure that the object will never get deallocated while you are weakly holding it—i.e., that you let go of your unsafe unretained reference before the last owner of the object lets go of that ownership.
- Never use
assign. For objects,
unsafe_unretainedis synonymous and clearer (it explicitly says that it is unsafe, which it is). For non-objects (such as
CGFloat, leave it out—
assignis the default for such values.
(This is an expanded version of a comment I posted on Stack Overflow.)