Weak vs Strong IBOutlets

đź“š Official Books Auto Layout by Tutorials
1

Hi,

Generally when we create IBOutlets, they are weak, but in book(Chapter 2), we are using strong.
Is it intentional or some printing error? And if it is intentional, then what is the difference btw weak and strong IBOulets?

Thanks

1 Like
2

Hi @pulkitap!

Although IBOutlets are often found as weak, Apple recommends a while back (2015) that references should be strong by default. Of course, this is unless the reference needs to be weak. However, it seems like this recommendation hasn’t had a significant impact enough caught on. I’ve attached a WWDC15 video and Apple’s documentation regarding IBOutlet storage type below for reference.

WWDC 2015 (Video 407, Timestamp 32:31):

Apple’s Documentation:

Hope I’ve answered your question!

3 Likes
3

Thanks @jayvenn for ur quick reply.

As u mentioned that “references should be strong by default. Of course, this is unless the reference needs to be weak.”, can we follow the reverse approach of this, i.e take IBOutlets as weak reference, unless we do not need it as strong?

4

Hi @pulkitap !
Defaulting IBOutlets to strong and only changing IBOutlets to weak as needed is recommended over the other way around. Imagine the way you’d initialize view properties programmatically. You’d also start with strong references and only change properties to weak when needed.

1 Like
5

Hi @jayvenn

Your logic sounds good to me, but I am having one more query, i.e. If we follow the strong IBOutlets approach, then do not we need to always check for memory that whether our views are in any kind of retain cycle or not? But if we follow the weak IBOutlet approach, then we do not specifically check for retain cycle.

Thanks

6

Hi @pulkitap!

The best practice is to start with a strong reference and move to weak as needed. When determining if a property should be strong or weak, look into Apple’s Automatic Reference Counting (ARC) first introduced in iOS 5 and 2011. You can learn more about this topic with the following article:

https://www.raywenderlich.com/966538-arc-and-memory-management-in-swift

And/or with the following video course:

https://www.raywenderlich.com/1940727-advanced-swift-memory-management

Understanding Swift memory management and reference counting will help you decide whether an IBOutlet should be weak or strong. You can use the initializer and de-initializer to verify whether class instances have the correct allocation/deallocation behavior with the reference count expectations. Beyond that, running Allocations and Leaks instruments against your application can help you find less obvious memory leaks.

Xcode understands that properties are referenced from the Interface Builder with the IBOutlet property declaration. Beyond that, the fundamentals of Automatic Reference Counting (ARC) and memory management in Swift still applies.

Every view controller has a strong reference to a view it manages. If you open UIViewController, you can find that view is declared as strong. You want a strong reference to mitigate invalid memory deallocation. When a view is alive, you should ask if its subviews should also be alive? In most cases, this would be a yes. Hence, the view keeps a strong reference to its subviews. All in all, the compiler needs to know when memory deallocation of a class instance is safe to mitigate memory overflow.

As a bonus resource, if you’d like to watch Chris Lattner introduce Automatic Reference Counting from about nine years ago, you can watch his introduction of the memory management system here from 2011:

1 Like
7

Recommendations do change over time and a lot has changed in the last five years. This is what the link above says today -

You typically need strong references to top-level objects to ensure that they are not deallocated; you don’t need strong references to objects lower down in the graph because they’re owned by their parents, and you should minimize the risk of creating strong reference cycles.
Outlets that you create should therefore typically be weak

1 Like
8

Perhaps this situation can also be expressed this way:

Top-level objects typically need to be strong to avoid deallocation. Objects down the graph don’t typically need to be strong to mitigate the chances of creating strong reference cycles.

I’d say this is still a rule of thumb. Understanding Swift memory management and reference counting should help you definitively decide whether an IBOutlet should be weak or strong.