UIView Properties: weak or strong?

I had always been using to qualify UIView properties in view controllers, but later noticed that some code does use for the same purpose. In fact, when I tried to initialize a view inside a block while using , I got a warning that only went away after switching to . It's worth understanding this properly, otherwise you'll never feel confident about the choice. Many people, when explaining the difference between and , simply say: use for views and for models. Over time I've come to feel that this is increasingly inaccurate. for strong references is easy to understand; , on the other hand, was designed specifically to avoid retain cycles. The most typical retain cycle scenario arises when a view controller holds a reference to a view, and that view's or is set back to the view controller. Apple's documentation states: Outlets should generally be weak, except for those from File's Owner to top-level objects in a nib file (or, in iOS, a storyboard scene) which should be strong. Outlets that you create should therefore typically be weak, because:... Mattt Thompson's article mentions: Spurious use of strong ownership on a view outlet has the potential to create a retain cycle. And 's article: Weak is the recommended relationship for all outlet properties. These view objects are already part of the view controller's view hierarchy and don't need to be retained elsewhere. The big advantage of declaring your outlets weak is that it saves you time writing the viewDidUnload method. There are only two cases where should be used: - Outlets that you create to subviews of a view controller's view or a window controller's window, for example, are arbitrary references between objects that do not imply ownership. - The strong outlets are frequently specified by framework classes (for example, UIViewController's view outlet, or NSWindowController's window outlet). Outlets should be changed to strong when the outlet should be considered to own the referenced object: - As indicated previously, this is often the case with File's Owner—top level objects in a nib file are frequently considered to be owned by the File's Owner. - You may in some situations need an object from a nib file to exist outside of its original container. For example, you might have an outlet for a view that can be temporarily removed from its initial view hierarchy and must therefore be maintained independently. The gist of this is: - If an IBOutlet object is directly owned by the nib/storyboard scene's File's Owner, then clearly the owner must a pointer to that object, so the property should be . All other IBOutlet properties should be , because the owner does not need to their pointers. For example, a UIViewController's property is because the controller directly owns the view. Subviews added to that view only need to be as IBOutlets, since they are not directly owned by the controller — the controller's view owns them, and ARC handles memory management. - Use when the controller needs to directly control a subview and add it to a different view tree. My personal understanding is that when using storyboards or nibs, there is already a strong reference chain from the view controller to its view and then to its subviews. Therefore, properties dragged out from Interface Builder are best declared as to avoid any potential retain cycles. What about views created in code? For example: If you don't use , you'll get the following warning: In practice, as long as there is no retain cycle, declaring a view as is perfectly fine. When the view controller is deallocated, both and views will be properly released, as long as there is no retain cycle. Finally, although I was reluctant to admit it, I found that in this highly-voted Stack Overflow question, the discussion took an interesting turn. The accepted answer notes: I asked about this on Twitter to an engineer on the IB team and he confirmed that strong should be the default and that the developer docs are being updated. https://twitter.com/danielhall/status/620716996326350848 https://twitter.com/danielhall/status/620717252216623104 This further supports the general safety of declaring view properties as . There is no one-size-fits-all answer to the vs question — is primarily used to avoid potential retain cycles, not as a blanket rule for view properties.