The story started when I was checking the codebase and found all the outlets annotated as weak, and I wondered why that was... like, what retain cycle are we even trying to avoid?

I had an intrusive idea of removing them, so I did — and then I opened the Leaks instrument, and guess what?

(No leaks were introduced)

Instruments showing no leaks

The Origin of `weak @IBOutlet`

That got me thinking: why were they there in the first place? So I started searching and came across this legacy Apple documentation:

Apple documentation on weak outlets

An outlet is declared as a weak reference (weak) to prevent strong reference cycles. — Apple documentation

Hmm... so Apple themselves recommended this!

Still... I honestly couldn't see the purpose, because I didn't have any retain cycles even without them.

What Apple Actually Says Now

So I decided to dig deeper, and I found this Stack Overflow answer from Daniel Hall:

The current recommended best practice from Apple is for IBOutlets to be strong unless weak is specifically needed to avoid a retain cycle.

This was commented on in the "Implementing UI Designs in Interface Builder" session from WWDC 2015 where an Apple engineer said:

In general, you should make your outlet strong, especially if you are connecting an outlet to a subview or to a constraint that's not always retained by the view hierarchy.

The only time you really need to make an outlet weak is if you have a custom view that references something back up the view hierarchy — and in general, that's not recommended.

They even asked an Interface Builder engineer at Apple on X:

Apple engineer confirming strong outlets

They confirmed it and said they're updating the docs.

And honestly, that makes sense — because it's really weird to annotate everything as weak. It's like saying: "I'll make all my variables weak to avoid retain cycles."

The Rule of Thumb

Everything is strong unless `weak` is actually needed to avoid a retain cycle

You'll only need to annotate something as weak in one specific case: when custom views have references to views upstream in the view hierarchy.

class CustomView: UIView {
    var controller: UIViewController?
}

class MyViewController: UIViewController {
    var customView: CustomView!

    override func viewDidLoad() {
        super.viewDidLoad()

        // Controller owns the customView strongly
        customView = CustomView()
        customView.controller = self   // CustomView owns controller strongly
        view.addSubview(customView)
    }
}

However, this is an anti-pattern and something we should never be doing in the first place. I'm pretty sure everyone can name at least three issues with these few lines of code.

Remember: a view should always be dumb, and it should never hold a strong reference to a ViewController.

The Performance Cost of `weak`

Okay, makes sense... but what are the drawbacks of having weak in our @IBOutlets?

Weak references don't keep objects alive, so an outlet may be deallocated unexpectedly, leading to crashes or undefined behavior.
strong is faster and more efficient than weak.

Why is `strong` faster?

It's just a pointer to the object in memory. When you assign or release it, ARC simply increments or decrements the retain count.

Why is `weak` slower?

It needs to track weak pointers in a global table, add them on assignment, and clear them to nil when the object is deallocated.

That's three extra operations versus a simple retain/release for strong references.

Summary

Never use weak again — and if it ever is needed, double-check your design choice, because it's probably wrong.