Note You may notice that the familyNames property is declared using the copy keyword instead of strong. What’s up with that? Why should we be copying arrays willy-nilly? The reason is the potential existence of mutable arrays.
Imagine if we had declared the property using strong, and an outside piece of code passed in an instance of NSMutableArray to set the value of the familyNames property. If that original caller later decides to change the contents of that array, the BIDRootViewController instance will end up in an inconsistent state, where the contents of familyNames is no longer in sync with what’s on the screen! Using copy eliminates that risk, since calling copy on any NSArray (including any mutable subclasses) always gives
us an immutable copy. Also, we don’t need to worry about the performance impact too much. As it turns out,
sending copy to any immutable object doesn’t actually copy the object. Instead, it returns the same object
after increasing its reference count. In effect, calling copy on an immutable object is the same as calling
retain, which is what ARC might do behind the scenes anytime you set a strong property. So, it works out
just fine for everyone, since the object can never change.
This situation applies to all value classes where the base class is immutable, but mutable subclasses exist.
These value classes include NSArray, NSDictionary, NSSet, NSString, NSData, and a few more.
Any time you want to hang onto an instance of one of these in a property, you should probably declare the
property’s storage with copy instead of strong to avoid any problems.