Introduction

In Objective-C property declarations, assign, copy, and retain describe how a value is stored and owned. They matter because object lifetime and mutation behavior depend on them. In pre-ARC code you see retain directly, while under ARC the modern equivalent is usually strong, but the reasoning behind all three attributes is still important.

assign for Non-Object Values

assign stores the incoming value directly without taking object ownership. It is appropriate for primitive types such as integers, floats, and booleans.

1@interface Counter : NSObject
2@property (nonatomic, assign) NSInteger count;
3@property (nonatomic, assign) BOOL enabled;
4@end

This is the normal choice for scalar values.

Using assign with object references is dangerous in most modern code because it does not keep the object alive. If the referenced object is deallocated, the property can become a dangling pointer.

retain Means Shared Ownership

In manual reference counting code, retain means the property keeps ownership of the assigned object by increasing its retain count.

@interface ProfileController : NSObject
@property (nonatomic, retain) NSMutableArray *items;
@end

This is appropriate when the property should hold onto an object and use the exact same instance that was passed in.

Under ARC, you normally replace retain with strong.

@property (nonatomic, strong) NSMutableArray *items;

The ownership idea is the same even though ARC manages the retain and release calls automatically.

copy Protects You from External Mutation

copy stores a copied version of the assigned object instead of the original reference. This is especially important when the public type is immutable but callers may pass a mutable subclass.

@interface Person : NSObject
@property (nonatomic, copy) NSString *name;
@end

Why copy for NSString? Because someone might pass an NSMutableString. If your property merely retained it and the caller changed that mutable string later, your object’s name would change unexpectedly. Copying breaks that shared-mutation link.

The same logic often applies to collections and blocks.

@property (nonatomic, copy) NSArray *titles;
@property (nonatomic, copy) void (^completionHandler)(void);

Choosing the Right Attribute

A practical rule set looks like this:

• use assign for primitive values
• use copy for NSString, NSArray, NSDictionary, and blocks when you want value-like behavior
• use retain in pre-ARC code, or strong in ARC code, for owned mutable object references

The real question is not “which keyword is fashionable.” It is “should this property own the same object, or should it store an independent copy?”

Pre-ARC and ARC Context

Older Objective-C codebases often still use retain explicitly because memory management was manual. In ARC projects, you no longer write retain and release calls yourself, but property attributes still express ownership.

That means legacy articles about retain are not obsolete. They describe the underlying model that ARC automates.

Common Pitfalls

• Using assign for object properties and risking dangling pointers.
• Using retain or strong for NSString when copy would protect against unexpected mutation.
• Assuming copy is only about memory and not about immutability semantics.
• Confusing pre-ARC retain with ARC strong and treating them as unrelated ideas.
• Forgetting that mutable collections copied into immutable property types become separate objects.

Summary

• 'assign is for primitive values and does not keep objects alive.'
• 'retain in pre-ARC code means the property owns the same object instance.'
• In ARC, strong is the modern replacement for most retain use cases.
• 'copy is the right choice when you need value-like behavior and protection from external mutation.'
• Choose the attribute based on ownership and mutation semantics, not just coding habit.