Introduction

In Objective-C under ARC, strong and weak describe ownership. A strong property keeps an object alive, while a weak property points to an object without extending its lifetime. Choosing the wrong one can create retain cycles or, just as often, objects that disappear earlier than you expected.

What strong Actually Means

Use strong when the owning object should keep the referenced object alive for as long as the property is set. Most model objects, collections, and child objects stored by a controller use strong references.

1@interface ProfileViewController : UIViewController
2
3@property (nonatomic, strong) User *user;
4@property (nonatomic, strong) NSArray<NSString *> *sections;
5
6@end

With ARC, assigning to a strong property increases ownership of the assigned object. As long as ProfileViewController still holds user, that User instance will not be deallocated.

This is why strong is the default choice when the property represents data your object truly owns.

What weak Actually Means

A weak property does not keep the target alive. If the last strong reference to that target disappears, ARC sets the weak property to nil automatically.

1@protocol DetailsViewControllerDelegate;
2
3@interface DetailsViewController : UIViewController
4
5@property (nonatomic, weak) id<DetailsViewControllerDelegate> delegate;
6
7@end

This pattern is common for delegates, parent references, and callbacks where the property should not own the object it points to.

The automatic nil behavior is important. A weak reference does not become a dangling pointer under ARC. Instead, it becomes nil, which is much safer and usually exactly what you want for back-references.

Why Retain Cycles Happen

The classic example is a parent owning a child strongly, while the child also owns the parent strongly. Neither object can be released because each one keeps the other alive.

1@interface ParentController : UIViewController
2@property (nonatomic, strong) ChildController *childController;
3@end
4
5@interface ChildController : UIViewController
6@property (nonatomic, weak) ParentController *parentController;
7@end

Here the parent should usually keep the child strongly, and the child should point back weakly. If both sides are strong, deallocation may never happen.

This is also why delegate properties are almost always weak. The delegating object should notify the delegate, not own it.

Setter Semantics and Property Behavior

The setter generated for a strong property stores the new object with ownership. The setter for a weak property stores a non-owning reference instead. From the caller's point of view, both are simple assignments, but the memory-management result is very different.

self.user = [[User alloc] init];
self.delegate = self.parentController;

In the first line, the view controller now owns the User object. In the second line, it merely points at parentController without affecting that controller's lifetime.

That difference is why "setter attribute" matters. The property declaration is not just documentation; it changes how the synthesized setter manages memory.

Choosing Between Them in Real Code

Use strong for objects your class conceptually owns:

• model instances stored by a controller
• arrays and dictionaries held for later use
• child coordinators or helper objects with the same lifetime

Use weak for objects your class refers to but does not own:

• delegates
• parent view controllers or owner references
• outlets to objects already retained elsewhere, depending on UI hierarchy

One related detail: immutable value objects such as NSString are often better declared as copy rather than strong. That is a separate ownership choice, but it is worth remembering because developers sometimes assume the only options are weak and strong.

Common Pitfalls

The most common bug is making both sides of a relationship strong. If object A strongly owns object B and object B strongly owns object A, ARC cannot clean them up.

The opposite bug is using weak for something your object actually owns. If no other strong reference exists, the value becomes nil and seems to "disappear." That usually means the property should have been strong.

Another pitfall is applying these attributes to the wrong kinds of types. weak is for Objective-C object references managed by ARC. It is not a general-purpose replacement for every pointer in the language.

Summary

• 'strong means your object owns the referenced object and keeps it alive.'
• 'weak means your object does not own the referenced object.'
• Weak references are zeroing under ARC, so they become nil when the target is deallocated.
• Use weak to break retain cycles in delegates and back-references.
• Use strong for objects your class is responsible for keeping in memory.