Copy vs. Strong NSArray Properties

At work this morning I added a property to an Objective-C object that looked something like this:

@property (nonatomic, strong) NSArray \*someArray;

And then it was suggested to me that copy would be better than strong in this case.

I have nothing against copy — but with an immutable array, is that really necessary? The array can’t change, so why copy it?

Well… that’s not strictly true. A caller could use an NSMutableArray — which would be perfectly valid — but then hold on that array and mutate it later on, which would be dumb.

So I ask: who would write code like that?

It’s not a class of mistake that I personally make. (I’ve internalized this so completely from years of writing Objective-C. I do make other classes of mistakes, of course.)

And then I think “Who would write code like that?” is the wrong question. The real question is, “Why wouldn’t I write code that minimizes the effect of a possible mistake?”

(Or even not a mistake. It could be entirely legitimate that the caller has a mutable array that it holds on to and mutates later on.)

* * *

This makes me wonder about the difference between code I write for myself and code I write as part of a team. Since I know that I wouldn’t make this particular mistake, I can safely use strong instead of copy in my own code.

But, really — sharp right turn here; buckle up! — doesn’t it make me wish everything was already in Swift, so we’d have the safer behavior automatically?

Yes. Yes it does.

My personal projects are mostly in Swift — converted to Swift 3 already — but, for obvious reasons, at work we often write new code in Swift but still have a large Objective-C codebase.

What I don’t need in life — because it adds complexity, and I don’t have time for that — is three separate coding styles: Swift, my Objective-C, and work Objective-C.

The only one I can get rid of is “my Objective-C.”

Okey-doke.