Should IBOutlets be strong or weak under ARC

Question

I am developing exclusively for iOS 5 using ARC  Should IBOutlets to UIViews  and subclasses  be strong or weak   The following    property  nonatomic  weak  IBOutlet UIButton  button    Would get rid of all of this   -  void viewDidUnload                  self button   nil                 Are there any problems doing this  The templates are using strong as are the automatically generated properties created when connecting directly to the header from the  Interface Builder  editor  but why  The UIViewController already has a strong reference to its view which retains its subviews

User · Answer

From WWDC 2015 there is a session on Implementing UI Designs in Interface Builder  Around the 32min mark he says that you always want to make your  IBOutlet strong

User · Answer

I think that most important information is  Elements in xib are automatically in subviews of view  Subviews is NSArray  NSArray owns it s elements  etc have strong pointers on them  So in most cases you don t want to create another strong pointer  IBOutlet   And with ARC you don t need to do anything in viewDidUnload

User · Answer

I don t see any problem with that  Pre-ARC  I ve always made my IBOutlets assign  as they re already retained by their superviews  If you make them weak  you shouldn t have to nil them out in viewDidUnload  as you point out    One caveat  You can support iOS 4 x in an ARC project  but if you do  you can t use weak  so you d have to make them assign  in which case you d still want to nil the reference in viewDidUnload to avoid a dangling pointer  Here s an example of a dangling pointer bug I ve experienced   A UIViewController has a UITextField for zip code  It uses CLLocationManager to reverse geocode the user s location and set the zip code  Here s the delegate callback   - void locationManager  CLLocationManager   manager    didUpdateToLocation  CLLocation   newLocation           fromLocation  CLLocation   oldLocation       Class geocoderClass   NSClassFromString   CLGeocoder        if  geocoderClass  amp  amp  IsEmpty self zip text             id geocoder     geocoderClass alloc  init            geocoder reverseGeocodeLocation newLocation completionHandler   NSArray  placemarks  NSError  error                if  self zip  amp  amp  IsEmpty self zip text                     self zip text     placemarks objectAtIndex 0  postalCode                                            self locationManager stopUpdatingLocation       I found that if I dismissed this view at the right time and didn t nil self zip in viewDidUnload  the delegate callback could throw a bad access exception on self zip text

User · Answer

WARNING  OUTDATED ANSWER  this answer is not up to date as per WWDC 2015  for the correct answer refer to the accepted answer  Daniel Hall  above  This answer will stay for record     Summarized from the developer library      From a practical perspective  in iOS and OS X outlets should be defined as declared properties  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 will therefore typically be weak by default  because          Outlets that you create to  for example  subviews of a view controller   s view or a window controller   s window  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     property  weak  IBOutlet MyView  viewContainerSubview   property  strong  IBOutlet MyOtherClass  topLevelObject

User · Answer

The current recommended best practice from Apple is for IBOutlets to be strong unless weak is specifically needed to avoid a retain cycle  As Johannes mentioned above  this was commented on in the  Implementing UI Designs in Interface Builder  session from WWDC 2015 where an Apple Engineer said      And the last option I want to point out is the storage type  which can   either be strong or weak  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 going to be 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    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

User · Answer

It looks like something has changed over the years and now Apple recommends to use strong in general  The evidence on their WWDC session is in session 407 - Implementing UI Designs in Interface Builder and starts at 32 30  My note from what he says is  almost  if not exactly  quoting him     outlet connections in general should be strong especially if we connect a subview or constraint that is not always retained by the view hierarchy weak outlet connection might be needed when creating custom views that has some reference to something back up in the view hierarchy and in general it is not recommended   In other wards it should be always strong now as long as some of our custom view doesn t create a retain cycle with some of the view up in the view hierarchy  EDIT    Some may ask the question  Does keeping it with a strong reference doesn t create a retain cycle as the root view controller and the owning view keeps the reference to it  Or why that changed happened  I think the answer is earlier in this talk when they describe how the nibs are created from the xib  There is a separate nib created for a VC and for the view  I think this might be the reason why they change the recommendations  Still it would be nice to get a deeper explanation from Apple

User · Answer

One thing I wish to point out here  and that is  despite what the Apple engineers have stated in their own WWDC 2015 video here   https   developer apple com videos play wwdc2015 407   Apple keeps changing their mind on the subject  which tells us that there is no single right answer to this question   To show that even Apple engineers are split on this subject  take a look at Apple s most recent sample code  and you ll see some people use weak  and some don t   This Apple Pay example uses weak  https   developer apple com library ios samplecode Emporium Listings Emporium ProductTableViewController swift html   apple ref doc uid TP40016175-Emporium ProductTableViewController swift-DontLinkElementID 8  As does this picture-in-picture example  https   developer apple com library ios samplecode AVFoundationPiPPlayer Listings AVFoundationPiPPlayer PlayerViewController swift html   apple ref doc uid TP40016166-AVFoundationPiPPlayer PlayerViewController swift-DontLinkElementID 4  As does the Lister example  https   developer apple com library ios samplecode Lister Listings Lister ListCell swift html   apple ref doc uid TP40014701-Lister ListCell swift-DontLinkElementID 57  As does the Core Location example  https   developer apple com library ios samplecode PotLoc Listings Potloc PotlocViewController swift html   apple ref doc uid TP40016176-Potloc PotlocViewController swift-DontLinkElementID 6  As does the view controller previewing example  https   developer apple com library ios samplecode ViewControllerPreviews Listings Projects PreviewUsingDelegate PreviewUsingDelegate DetailViewController swift html   apple ref doc uid TP40016546-Projects PreviewUsingDelegate PreviewUsingDelegate DetailViewController swift-DontLinkElementID 5  As does the HomeKit example  https   developer apple com library ios samplecode HomeKitCatalog Listings HMCatalog Homes Action Sets ActionSetViewController swift html   apple ref doc uid TP40015048-HMCatalog Homes Action Sets ActionSetViewController swift-DontLinkElementID 23  All those are fully updated for iOS 9  and all use weak outlets   From this we learn that A   The issue is not as simple as some people make it out to be   B  Apple has changed their mind repeatedly  and C  You can use whatever makes you happy     Special thanks to Paul Hudson  author of www hackingwithsift com  who gave me the clarification  and references for this answer   I hope this clarifies the subject a bit better   Take care

User · Answer

IBOutlet should be strong  for performance reason  See Storyboard Reference  Strong IBOutlet  Scene Dock in iOS 9     As explained in this paragraph  the outlets to subviews of the view   controller   s view can be weak  because these subviews are already   owned by the top-level object of the nib file  However  when an Outlet   is defined as a weak pointer and the pointer is set  ARC calls the   runtime function       id objc storeWeak id  object  id value         This adds the pointer    object  to a table using the object value as a key  This table is   referred to as the weak table  ARC uses this table to store all the   weak pointers of your application  Now  when the object value is   deallocated  ARC will iterate over the weak table and set the weak   reference to nil  Alternatively  ARC can call       void objc destroyWeak id   object       Then  the object is   unregistered and objc destroyWeak calls again       objc storeWeak id  object  nil       This book-keeping associated   with a weak reference can take 2   3 times longer over the release of a   strong reference  So  a weak reference introduces an overhead for the   runtime that you can avoid by simply defining outlets as strong    As of Xcode 7  it suggests strong    If you watch WWDC 2015 session 407 Implementing UI Designs in Interface Builder  it suggests  transcript from http   asciiwwdc com 2015 sessions 407      And the last option I want to point out is the storage type  which can either be strong or weak       In general you should make your outlet strong  especially if you are connecting an outlet to a sub view or to a constraint that s not always going to be 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       So I m going to choose strong and I will click connect which will generate my outlet

User · Answer

Be aware  IBOutletCollection should be  property  strong  nonatomic

User · Answer

While the documentation recommends using weak on properties for subviews  since iOS 6 it seems to be fine to use strong  the default ownership qualifier  instead  That s caused by the change in UIViewController that views are not unloaded anymore    Before iOS 6  if you kept strong links to subviews of the controller s view around  if the view controller s main view got unloaded  those would hold onto the subviews as long as the view controller is around  Since iOS 6  views are not unloaded anymore  but loaded once and then stick around as long as their controller is there  So strong properties won t matter  They also won t create strong reference cycles  since they point down the strong reference graph    That said  I am torn between using   property  nonatomic  weak  IBOutlet UIButton  button    and   property  nonatomic  IBOutlet UIButton  button    in iOS 6 and after    Using weak clearly states that the controller doesn t want ownership of the button  But omitting weak doesn t hurt in iOS 6 without view unloading  and is shorter  Some may point out that is also faster  but I have yet to encounter an app that is too slow because of weak IBOutlets  Not using weak may be perceived as an error    Bottom line  Since iOS 6 we can t get this wrong anymore as long as we don t use view unloading  Time to party

User · Answer

In iOS development NIB loading is a little bit different from Mac development    In Mac development an IBOutlet is usually a weak reference  if you have a subclass of NSViewController only the top-level view will be retained and when you dealloc the controller all its subviews and outlets are freed automatically    UiViewController use Key Value Coding to set the outlets using strong references  So when you dealloc your UIViewController  the top view will automatically deallocated  but you must also deallocate all its outlets in the dealloc method    In this post from the Big Nerd Ranch  they cover this topic and also explain why using a strong reference in IBOutlet is not a good choice  even if it is recommended by Apple in this case

[ios] Should IBOutlets be strong or weak under ARC?

Examples related to ios

Examples related to objective-c

Examples related to cocoa-touch

Examples related to interface-builder

Examples related to automatic-ref-counting