When choosing whether to specify retain or copy for a property, you should not be considering size, time, etc. – you should be considering semantics first and foremost.

Yes, it is conceivable that a custom immutable class will later have an immutable class added, but you have to balance this hypothetical against the cost. If you’re very concerned about it, you could add an isMemberOfClass: assertion, but in my opinion this goes beyond defensive programming to unhelpful paranoia.

When choosing whether to retain or copy, you must also consider the size of the object. If the object is quite small, then perhaps the cost of copy is worth it. If it is large or set very often, then copying may simply be too inefficient. As an example from the other direction, when returning an NSArray that you store internally as an NSMutableArray, you should make a copy so that the array doesn’t change behind your caller’s back. Unfortunately this can sometimes be a massive performance bottleneck, and I’ve been forced to just return the NSMutableArray cast as an NSArray. Read the docs for NSView -subviews for an example where Apple has had to do this, too.

Always remember to keep the actual goal in mind, and then apply the rules of thumb appropriately.

You wrote “[S]hould a copy of foo have a second pointer to bar, or should it have its own copy of whatever bar points to? There is no way to answer this question generally; it depends on the nature of the objects.”

Indeed, I suspect I’m wrestling with this issue right now. (I could also be suffering from a bit of developer myopia and need to step back a bit.)

As I’ve been taught, for attributes whose type is an immutable value class that conforms to the NSCopying protocol, it’s wise to specify copy vs retain in the @property declaration.

In particular, the recommendation is to always use copy on NSString setters, which I continue to do to this day:

@property (nonatomic, copy) NSString *bar;

However, wouldn’t that go against the advisement – when NSCopying is honored – to “[implement] the accessors with the correct behavior (retain versus copy)”?

In the case of NSString, is the use of copy in setters a bad idea? Is it a toss-up (“it doesn’t matter”)?

The urging to use copy on NSString setters is very strong out there in the wild, so I want to make sure I “measure twice, cut once” here!

Product *copy = [[[self class] allocWithZone: zone]];

should be Product *copy = [[[self class] allocWithZone: zone]init];

Thanks for the enlightening article, I was having hard time understanding the drawback of NSCopyObject on the reference manual.

Could you post detailed example about the alternative way, this would help iPhone newbies.