copy creates a new object, which, as the name of the method suggests, is a copy of the receiver (in fact, it depends on the implementation of the copy method in each class, but the goal is the method anyway).
Thus, in fact, this does not “increase the reference counter by 1”, but rather creates a new object with recount 1 as any new selected object and makes it the same value of the / ivar property as the original.
So, imagine that you have a Person class with the name , surname and age properties, if you need to implement the copy method yourself, it will look like this:
-(id)copy { // Create a new instance Person* mycopy = [[Person alloc] init]; // Make it an exact copy of the original mycopy.name = self.name; mycopy.surname = self.surname; mycopy.age = self.age; // and return that copy return mycopy; }
Please note that in this case, if you subsequently change the copy, the original will not be changed, because it is a different copy.
With this principle, the source object does not have its refcount increased by one, but you have a new object whose refcount is the same (as if you just distributed / init to create this new object yourself), and you still have to release or auto-advertise at some point (unless you use ARC). Therefore, when calling copy on the object, the same rules are alloc as retain or alloc regarding the need to call release or autorelease in order to balance the recount at some point
Note that there are some exceptions / special cases, especially for some classes that are called "immutable", such as NSArray or NSString . In such cases, it is reasonable that creating a copy (like another instance of the object), which is a clone of the original, while the original cannot be modified, is not very efficient and can be optimized.
Therefore, in cases such as NSArray and NSString and some others, the copy method can simply be implemented to perform a simple retain , because the behavior will be the same as you can not change the original (and neither copy), since they are immutable classes by nature .
Of course, the mutableCopy implementation (for example, to get an NSMutableArray from an NSArray ) makes a real copy, not just save, but the implementation of the copy method in mutable subclasses like NSMutableString and NSMutableArray make a real copy, but for a case that requires an immutable copy of an immutable object, the selection point of another instance is usually useless and consumed in memory, and thus implemented in the same way as retain .
But all this probable optimization does not change either the behavior (because the classes are immutable) or the memory management policy (since you still need to release object returned by copy )