I think there's more to the story that bears consideration:
@IBOutlet annotation merely allows a variable to be exposed to Interface builder. It doesn't require it to actually be correctly connected to a Xib. If it were unconnected and the variable were referenced within code, the app would crash. We've all experienced this developer error.
Fatal error: Unexpectedly found nil while implicitly unwrapping an Optional value 2. Contrary to a popular WWDC presentation by a UIKit engineer (2015?) who stated that IBOutlets should now be strong, the Apple docs haven't changed. It still recommends @IBOutlet's should be weak var and implicitly unwrapped, since as QuinceyMorris states above, the view hierarchy does hold strong references to correctly attached IBOutlets, thus allowing the object holding the IBOutlet to do so weakly.
3. As always, the devil is in the details with a notable exception:
If a UI element is to be added or removed programmatically, it may need to be held with a strong reference because removing a weakly held IBOutlet element from the view hierarchy that currently holds it strongly would cause it to be immediately deallocated if no other references held it strongly.
Topic:
Programming Languages
SubTopic:
Swift
Tags: