Should IBOutlets be strong or weak under ARC?












521














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.










share|improve this question




















  • 11




    As a note, IBOutletCollection() must not be weak, otherwise it returns as nil.
    – ohho
    Jul 31 '13 at 7:03












  • Xcode 8.2.1 uses weak when creating IBOutlets via interface builder. However many answers here on SO advises to use strong.
    – neoneye
    Feb 23 '17 at 11:33










  • @neoneye I just tried with xcode 8.3.2 dragging from storyboard to swift file and it defaults to strong
    – CupawnTae
    Jun 17 '17 at 9:39
















521














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.










share|improve this question




















  • 11




    As a note, IBOutletCollection() must not be weak, otherwise it returns as nil.
    – ohho
    Jul 31 '13 at 7:03












  • Xcode 8.2.1 uses weak when creating IBOutlets via interface builder. However many answers here on SO advises to use strong.
    – neoneye
    Feb 23 '17 at 11:33










  • @neoneye I just tried with xcode 8.3.2 dragging from storyboard to swift file and it defaults to strong
    – CupawnTae
    Jun 17 '17 at 9:39














521












521








521


241





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.










share|improve this 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.







ios objective-c cocoa-touch interface-builder automatic-ref-counting






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Aug 28 '15 at 7:38









Julian Król

7,81043759




7,81043759










asked Oct 6 '11 at 17:56









hypercrypt

11.9k64359




11.9k64359








  • 11




    As a note, IBOutletCollection() must not be weak, otherwise it returns as nil.
    – ohho
    Jul 31 '13 at 7:03












  • Xcode 8.2.1 uses weak when creating IBOutlets via interface builder. However many answers here on SO advises to use strong.
    – neoneye
    Feb 23 '17 at 11:33










  • @neoneye I just tried with xcode 8.3.2 dragging from storyboard to swift file and it defaults to strong
    – CupawnTae
    Jun 17 '17 at 9:39














  • 11




    As a note, IBOutletCollection() must not be weak, otherwise it returns as nil.
    – ohho
    Jul 31 '13 at 7:03












  • Xcode 8.2.1 uses weak when creating IBOutlets via interface builder. However many answers here on SO advises to use strong.
    – neoneye
    Feb 23 '17 at 11:33










  • @neoneye I just tried with xcode 8.3.2 dragging from storyboard to swift file and it defaults to strong
    – CupawnTae
    Jun 17 '17 at 9:39








11




11




As a note, IBOutletCollection() must not be weak, otherwise it returns as nil.
– ohho
Jul 31 '13 at 7:03






As a note, IBOutletCollection() must not be weak, otherwise it returns as nil.
– ohho
Jul 31 '13 at 7:03














Xcode 8.2.1 uses weak when creating IBOutlets via interface builder. However many answers here on SO advises to use strong.
– neoneye
Feb 23 '17 at 11:33




Xcode 8.2.1 uses weak when creating IBOutlets via interface builder. However many answers here on SO advises to use strong.
– neoneye
Feb 23 '17 at 11:33












@neoneye I just tried with xcode 8.3.2 dragging from storyboard to swift file and it defaults to strong
– CupawnTae
Jun 17 '17 at 9:39




@neoneye I just tried with xcode 8.3.2 dragging from storyboard to swift file and it defaults to strong
– CupawnTae
Jun 17 '17 at 9:39












11 Answers
11






active

oldest

votes


















201














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








share|improve this answer



















  • 27




    Is this really true or is the answer with 300+ upvotes the correct one? I noticed that InterfaceBuilder by default uses weak when you Ctrl-drag from the storyboard to the .h
    – Arunabh Das
    Oct 8 '15 at 19:48






  • 4




    The one with 400+ votes is correct, but outdated. Since iOS 6 viewDidUnload doesn't get called, so there are no benefits for having weak outlets.
    – kjam
    Mar 10 '16 at 13:16






  • 3




    @kjam there are benefits. First and foremost you shouldn't hold a strong reference to something you didn't create. Second, the performance gain is negligible. Don't violate best practices in programming simply because some guy, even a well placed guy, said this is 10 microseconds faster. Code clear intent, don't try to play optimizing compiler. Only code for performance when it has been measured in a specific case to be a problem.
    – Cameron Lowell Palmer
    Mar 15 '16 at 10:25








  • 5




    Let me disagree with you. 'Holding a strong reference to something you didn't create' happens all the time in Objective-C. That's why there is a reference counting, rather then a single owner. Do you have any references to back-up this recommendation? Could you pls list the other benefits of weak outlets?
    – kjam
    Apr 6 '16 at 20:18








  • 3




    Here is the WWDC video mentioned in the answer developer.apple.com/videos/play/wwdc2015/407/?time=1946
    – petrsyn
    Jan 7 '17 at 9:51



















445





+50









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;








share|improve this answer



















  • 10




    How did you get the "developer library" link to jump to the particular part of the apple doc page? Whenever I link to the apple docs it always links to the top of the page (even if the content of interest is halfway down the page). Thanks.
    – bearMountain
    Dec 1 '11 at 17:12






  • 68




    I copied the link from the navigation pane on the left. :D
    – Alexsander Akers
    Dec 1 '11 at 18:22






  • 27




    What does "except for those from File’s Owner to top-level objects in a nib file (or, in iOS, a storyboard scene)" mean?
    – Van Du Tran
    Mar 9 '12 at 15:55






  • 16




    @VanDuTran - it means objects in the NIB that are at the root level, i.e. say you instantiated another view in there which isn't directly a subview of the main view, then it needs to have a strong reference.
    – mattjgalloway
    Mar 25 '12 at 16:59






  • 6




    Top level means that when you look at the nib, the object appears in the list on the left. Almost all nibs have a UIView in them - this might be the only top level object. If you add other items, and they show in the list, they are "top level objects"
    – David H
    May 30 '12 at 17:29



















46














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. ;)






share|improve this answer























  • That is true, but you may still want to unload the view yourself. In which case you'd have to set all of your outlets to nil manually.
    – hypercrypt
    Dec 10 '13 at 22:10










  • PS: weak is a quite a bit cheaper in ARM64 :D
    – hypercrypt
    Dec 10 '13 at 22:11












  • That's right, if you implement view unloading, weak properties or __weak instance variables are the way to go. I just wanted to point out that there is less potential for error here. As for weak being cheaper on arm64, I have not even seen a real-life performance problem with weak IBOutlets on armv7. :)
    – Tammo Freese
    Dec 11 '13 at 8:47










  • Nor have I and your point is very valid.
    – hypercrypt
    Dec 11 '13 at 9:14






  • 1




    @Rocotilos The first iPhone had very limited RAM. If I recall correctly, 128 MB, leaving around 10 MB for the active app. Having a small memory footprint was crucial, hence there was view unloading. That changed as we now have more and more RAM, and Apple optimized UIViews in iOS 6, so that on memory warnings, a lot of memory can be freed without unloading the view.
    – Tammo Freese
    Sep 4 '16 at 16:11



















34














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 && IsEmpty(self.zip.text)) {
id geocoder = [[geocoderClass alloc] init];
[geocoder reverseGeocodeLocation:newLocation completionHandler:^(NSArray *placemarks, NSError *error) {
if (self.zip && 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.






share|improve this answer



















  • 4




    It is also my understanding that weak properties do not need to be nilled in viewDidUnload. But why does Apple’s template for creating outlets include a [self setMySubview:nil]?
    – Yang Meyer
    Jan 24 '12 at 8:20










  • @Yang, I'm wondering the same
    – Brenden
    May 22 '13 at 23:00






  • 3




    Is there any real world cases where using strong/retained for your IBOutlet could cause problem? Or is it just a redundant retain, which means bad coding style but wouldn't affect your code?
    – Enzo Tran
    Jun 13 '13 at 15:22






  • 1




    Is there such a thing as a redundant retain? If there's an extra retain, that will cause it to not be counted properly, and therefore won't be freed as soon as it could be since there's an extra retain on its retain count.
    – karlbecker_com
    Feb 25 '14 at 1:13



















20














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).






share|improve this answer



















  • 16




    It explains it as at 2009. With ARC, this has changed significantly.
    – Dafydd Williams
    Jul 19 '12 at 1:53






  • 1




    :( the Big Nerd Ranch link is dead… yet I really need to read it. Anyone knows more details about that post, so I can find it?
    – Motti Shneor
    Aug 9 '14 at 17:42










  • @MottiShneor don't worry, it's no big deal since the link was about times before ARC and is not relevant anymore.
    – Sergey Grischyov
    Aug 11 '14 at 9:45



















16














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.







share|improve this answer



















  • 1




    Great answer that explains the actual reason -why-
    – micnguyen
    Feb 9 '17 at 2:49










  • That is good and all but i have seen leaks coming from gesture recognizers implemented in storyboard.
    – thibaut noah
    May 11 '17 at 12:28






  • 2




    I still get weak as the default (Xcode 8)
    – Fonix
    Jun 12 '17 at 13:54



















11














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.






share|improve this answer





























    9














    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.






    share|improve this answer





















    • Interesting. I guess this changed when view unloading was removed?
      – hypercrypt
      Jul 9 '15 at 14:45



















    6














    Be aware, IBOutletCollection should be @property (strong, nonatomic).






    share|improve this answer

















    • 3




      Why not copy as it is an NSArray?
      – hypercrypt
      Mar 25 '14 at 13:16



















    5














    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.






    share|improve this answer































      4














      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






      share|improve this answer





















        Your Answer






        StackExchange.ifUsing("editor", function () {
        StackExchange.using("externalEditor", function () {
        StackExchange.using("snippets", function () {
        StackExchange.snippets.init();
        });
        });
        }, "code-snippets");

        StackExchange.ready(function() {
        var channelOptions = {
        tags: "".split(" "),
        id: "1"
        };
        initTagRenderer("".split(" "), "".split(" "), channelOptions);

        StackExchange.using("externalEditor", function() {
        // Have to fire editor after snippets, if snippets enabled
        if (StackExchange.settings.snippets.snippetsEnabled) {
        StackExchange.using("snippets", function() {
        createEditor();
        });
        }
        else {
        createEditor();
        }
        });

        function createEditor() {
        StackExchange.prepareEditor({
        heartbeatType: 'answer',
        autoActivateHeartbeat: false,
        convertImagesToLinks: true,
        noModals: true,
        showLowRepImageUploadWarning: true,
        reputationToPostImages: 10,
        bindNavPrevention: true,
        postfix: "",
        imageUploader: {
        brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
        contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
        allowUrls: true
        },
        onDemand: true,
        discardSelector: ".discard-answer"
        ,immediatelyShowMarkdownHelp:true
        });


        }
        });














        draft saved

        draft discarded


















        StackExchange.ready(
        function () {
        StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f7678469%2fshould-iboutlets-be-strong-or-weak-under-arc%23new-answer', 'question_page');
        }
        );

        Post as a guest















        Required, but never shown

























        11 Answers
        11






        active

        oldest

        votes








        11 Answers
        11






        active

        oldest

        votes









        active

        oldest

        votes






        active

        oldest

        votes









        201














        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








        share|improve this answer



















        • 27




          Is this really true or is the answer with 300+ upvotes the correct one? I noticed that InterfaceBuilder by default uses weak when you Ctrl-drag from the storyboard to the .h
          – Arunabh Das
          Oct 8 '15 at 19:48






        • 4




          The one with 400+ votes is correct, but outdated. Since iOS 6 viewDidUnload doesn't get called, so there are no benefits for having weak outlets.
          – kjam
          Mar 10 '16 at 13:16






        • 3




          @kjam there are benefits. First and foremost you shouldn't hold a strong reference to something you didn't create. Second, the performance gain is negligible. Don't violate best practices in programming simply because some guy, even a well placed guy, said this is 10 microseconds faster. Code clear intent, don't try to play optimizing compiler. Only code for performance when it has been measured in a specific case to be a problem.
          – Cameron Lowell Palmer
          Mar 15 '16 at 10:25








        • 5




          Let me disagree with you. 'Holding a strong reference to something you didn't create' happens all the time in Objective-C. That's why there is a reference counting, rather then a single owner. Do you have any references to back-up this recommendation? Could you pls list the other benefits of weak outlets?
          – kjam
          Apr 6 '16 at 20:18








        • 3




          Here is the WWDC video mentioned in the answer developer.apple.com/videos/play/wwdc2015/407/?time=1946
          – petrsyn
          Jan 7 '17 at 9:51
















        201














        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








        share|improve this answer



















        • 27




          Is this really true or is the answer with 300+ upvotes the correct one? I noticed that InterfaceBuilder by default uses weak when you Ctrl-drag from the storyboard to the .h
          – Arunabh Das
          Oct 8 '15 at 19:48






        • 4




          The one with 400+ votes is correct, but outdated. Since iOS 6 viewDidUnload doesn't get called, so there are no benefits for having weak outlets.
          – kjam
          Mar 10 '16 at 13:16






        • 3




          @kjam there are benefits. First and foremost you shouldn't hold a strong reference to something you didn't create. Second, the performance gain is negligible. Don't violate best practices in programming simply because some guy, even a well placed guy, said this is 10 microseconds faster. Code clear intent, don't try to play optimizing compiler. Only code for performance when it has been measured in a specific case to be a problem.
          – Cameron Lowell Palmer
          Mar 15 '16 at 10:25








        • 5




          Let me disagree with you. 'Holding a strong reference to something you didn't create' happens all the time in Objective-C. That's why there is a reference counting, rather then a single owner. Do you have any references to back-up this recommendation? Could you pls list the other benefits of weak outlets?
          – kjam
          Apr 6 '16 at 20:18








        • 3




          Here is the WWDC video mentioned in the answer developer.apple.com/videos/play/wwdc2015/407/?time=1946
          – petrsyn
          Jan 7 '17 at 9:51














        201












        201








        201






        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








        share|improve this 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









        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Nov 23 at 21:59

























        answered Jul 14 '15 at 0:59









        Daniel Hall

        9,57742326




        9,57742326








        • 27




          Is this really true or is the answer with 300+ upvotes the correct one? I noticed that InterfaceBuilder by default uses weak when you Ctrl-drag from the storyboard to the .h
          – Arunabh Das
          Oct 8 '15 at 19:48






        • 4




          The one with 400+ votes is correct, but outdated. Since iOS 6 viewDidUnload doesn't get called, so there are no benefits for having weak outlets.
          – kjam
          Mar 10 '16 at 13:16






        • 3




          @kjam there are benefits. First and foremost you shouldn't hold a strong reference to something you didn't create. Second, the performance gain is negligible. Don't violate best practices in programming simply because some guy, even a well placed guy, said this is 10 microseconds faster. Code clear intent, don't try to play optimizing compiler. Only code for performance when it has been measured in a specific case to be a problem.
          – Cameron Lowell Palmer
          Mar 15 '16 at 10:25








        • 5




          Let me disagree with you. 'Holding a strong reference to something you didn't create' happens all the time in Objective-C. That's why there is a reference counting, rather then a single owner. Do you have any references to back-up this recommendation? Could you pls list the other benefits of weak outlets?
          – kjam
          Apr 6 '16 at 20:18








        • 3




          Here is the WWDC video mentioned in the answer developer.apple.com/videos/play/wwdc2015/407/?time=1946
          – petrsyn
          Jan 7 '17 at 9:51














        • 27




          Is this really true or is the answer with 300+ upvotes the correct one? I noticed that InterfaceBuilder by default uses weak when you Ctrl-drag from the storyboard to the .h
          – Arunabh Das
          Oct 8 '15 at 19:48






        • 4




          The one with 400+ votes is correct, but outdated. Since iOS 6 viewDidUnload doesn't get called, so there are no benefits for having weak outlets.
          – kjam
          Mar 10 '16 at 13:16






        • 3




          @kjam there are benefits. First and foremost you shouldn't hold a strong reference to something you didn't create. Second, the performance gain is negligible. Don't violate best practices in programming simply because some guy, even a well placed guy, said this is 10 microseconds faster. Code clear intent, don't try to play optimizing compiler. Only code for performance when it has been measured in a specific case to be a problem.
          – Cameron Lowell Palmer
          Mar 15 '16 at 10:25








        • 5




          Let me disagree with you. 'Holding a strong reference to something you didn't create' happens all the time in Objective-C. That's why there is a reference counting, rather then a single owner. Do you have any references to back-up this recommendation? Could you pls list the other benefits of weak outlets?
          – kjam
          Apr 6 '16 at 20:18








        • 3




          Here is the WWDC video mentioned in the answer developer.apple.com/videos/play/wwdc2015/407/?time=1946
          – petrsyn
          Jan 7 '17 at 9:51








        27




        27




        Is this really true or is the answer with 300+ upvotes the correct one? I noticed that InterfaceBuilder by default uses weak when you Ctrl-drag from the storyboard to the .h
        – Arunabh Das
        Oct 8 '15 at 19:48




        Is this really true or is the answer with 300+ upvotes the correct one? I noticed that InterfaceBuilder by default uses weak when you Ctrl-drag from the storyboard to the .h
        – Arunabh Das
        Oct 8 '15 at 19:48




        4




        4




        The one with 400+ votes is correct, but outdated. Since iOS 6 viewDidUnload doesn't get called, so there are no benefits for having weak outlets.
        – kjam
        Mar 10 '16 at 13:16




        The one with 400+ votes is correct, but outdated. Since iOS 6 viewDidUnload doesn't get called, so there are no benefits for having weak outlets.
        – kjam
        Mar 10 '16 at 13:16




        3




        3




        @kjam there are benefits. First and foremost you shouldn't hold a strong reference to something you didn't create. Second, the performance gain is negligible. Don't violate best practices in programming simply because some guy, even a well placed guy, said this is 10 microseconds faster. Code clear intent, don't try to play optimizing compiler. Only code for performance when it has been measured in a specific case to be a problem.
        – Cameron Lowell Palmer
        Mar 15 '16 at 10:25






        @kjam there are benefits. First and foremost you shouldn't hold a strong reference to something you didn't create. Second, the performance gain is negligible. Don't violate best practices in programming simply because some guy, even a well placed guy, said this is 10 microseconds faster. Code clear intent, don't try to play optimizing compiler. Only code for performance when it has been measured in a specific case to be a problem.
        – Cameron Lowell Palmer
        Mar 15 '16 at 10:25






        5




        5




        Let me disagree with you. 'Holding a strong reference to something you didn't create' happens all the time in Objective-C. That's why there is a reference counting, rather then a single owner. Do you have any references to back-up this recommendation? Could you pls list the other benefits of weak outlets?
        – kjam
        Apr 6 '16 at 20:18






        Let me disagree with you. 'Holding a strong reference to something you didn't create' happens all the time in Objective-C. That's why there is a reference counting, rather then a single owner. Do you have any references to back-up this recommendation? Could you pls list the other benefits of weak outlets?
        – kjam
        Apr 6 '16 at 20:18






        3




        3




        Here is the WWDC video mentioned in the answer developer.apple.com/videos/play/wwdc2015/407/?time=1946
        – petrsyn
        Jan 7 '17 at 9:51




        Here is the WWDC video mentioned in the answer developer.apple.com/videos/play/wwdc2015/407/?time=1946
        – petrsyn
        Jan 7 '17 at 9:51













        445





        +50









        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;








        share|improve this answer



















        • 10




          How did you get the "developer library" link to jump to the particular part of the apple doc page? Whenever I link to the apple docs it always links to the top of the page (even if the content of interest is halfway down the page). Thanks.
          – bearMountain
          Dec 1 '11 at 17:12






        • 68




          I copied the link from the navigation pane on the left. :D
          – Alexsander Akers
          Dec 1 '11 at 18:22






        • 27




          What does "except for those from File’s Owner to top-level objects in a nib file (or, in iOS, a storyboard scene)" mean?
          – Van Du Tran
          Mar 9 '12 at 15:55






        • 16




          @VanDuTran - it means objects in the NIB that are at the root level, i.e. say you instantiated another view in there which isn't directly a subview of the main view, then it needs to have a strong reference.
          – mattjgalloway
          Mar 25 '12 at 16:59






        • 6




          Top level means that when you look at the nib, the object appears in the list on the left. Almost all nibs have a UIView in them - this might be the only top level object. If you add other items, and they show in the list, they are "top level objects"
          – David H
          May 30 '12 at 17:29
















        445





        +50









        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;








        share|improve this answer



















        • 10




          How did you get the "developer library" link to jump to the particular part of the apple doc page? Whenever I link to the apple docs it always links to the top of the page (even if the content of interest is halfway down the page). Thanks.
          – bearMountain
          Dec 1 '11 at 17:12






        • 68




          I copied the link from the navigation pane on the left. :D
          – Alexsander Akers
          Dec 1 '11 at 18:22






        • 27




          What does "except for those from File’s Owner to top-level objects in a nib file (or, in iOS, a storyboard scene)" mean?
          – Van Du Tran
          Mar 9 '12 at 15:55






        • 16




          @VanDuTran - it means objects in the NIB that are at the root level, i.e. say you instantiated another view in there which isn't directly a subview of the main view, then it needs to have a strong reference.
          – mattjgalloway
          Mar 25 '12 at 16:59






        • 6




          Top level means that when you look at the nib, the object appears in the list on the left. Almost all nibs have a UIView in them - this might be the only top level object. If you add other items, and they show in the list, they are "top level objects"
          – David H
          May 30 '12 at 17:29














        445





        +50







        445





        +50



        445




        +50




        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;








        share|improve this 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;









        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Jul 11 '17 at 14:45









        Antonio E.

        4,00122035




        4,00122035










        answered Oct 11 '11 at 16:10









        Alexsander Akers

        13.5k115176




        13.5k115176








        • 10




          How did you get the "developer library" link to jump to the particular part of the apple doc page? Whenever I link to the apple docs it always links to the top of the page (even if the content of interest is halfway down the page). Thanks.
          – bearMountain
          Dec 1 '11 at 17:12






        • 68




          I copied the link from the navigation pane on the left. :D
          – Alexsander Akers
          Dec 1 '11 at 18:22






        • 27




          What does "except for those from File’s Owner to top-level objects in a nib file (or, in iOS, a storyboard scene)" mean?
          – Van Du Tran
          Mar 9 '12 at 15:55






        • 16




          @VanDuTran - it means objects in the NIB that are at the root level, i.e. say you instantiated another view in there which isn't directly a subview of the main view, then it needs to have a strong reference.
          – mattjgalloway
          Mar 25 '12 at 16:59






        • 6




          Top level means that when you look at the nib, the object appears in the list on the left. Almost all nibs have a UIView in them - this might be the only top level object. If you add other items, and they show in the list, they are "top level objects"
          – David H
          May 30 '12 at 17:29














        • 10




          How did you get the "developer library" link to jump to the particular part of the apple doc page? Whenever I link to the apple docs it always links to the top of the page (even if the content of interest is halfway down the page). Thanks.
          – bearMountain
          Dec 1 '11 at 17:12






        • 68




          I copied the link from the navigation pane on the left. :D
          – Alexsander Akers
          Dec 1 '11 at 18:22






        • 27




          What does "except for those from File’s Owner to top-level objects in a nib file (or, in iOS, a storyboard scene)" mean?
          – Van Du Tran
          Mar 9 '12 at 15:55






        • 16




          @VanDuTran - it means objects in the NIB that are at the root level, i.e. say you instantiated another view in there which isn't directly a subview of the main view, then it needs to have a strong reference.
          – mattjgalloway
          Mar 25 '12 at 16:59






        • 6




          Top level means that when you look at the nib, the object appears in the list on the left. Almost all nibs have a UIView in them - this might be the only top level object. If you add other items, and they show in the list, they are "top level objects"
          – David H
          May 30 '12 at 17:29








        10




        10




        How did you get the "developer library" link to jump to the particular part of the apple doc page? Whenever I link to the apple docs it always links to the top of the page (even if the content of interest is halfway down the page). Thanks.
        – bearMountain
        Dec 1 '11 at 17:12




        How did you get the "developer library" link to jump to the particular part of the apple doc page? Whenever I link to the apple docs it always links to the top of the page (even if the content of interest is halfway down the page). Thanks.
        – bearMountain
        Dec 1 '11 at 17:12




        68




        68




        I copied the link from the navigation pane on the left. :D
        – Alexsander Akers
        Dec 1 '11 at 18:22




        I copied the link from the navigation pane on the left. :D
        – Alexsander Akers
        Dec 1 '11 at 18:22




        27




        27




        What does "except for those from File’s Owner to top-level objects in a nib file (or, in iOS, a storyboard scene)" mean?
        – Van Du Tran
        Mar 9 '12 at 15:55




        What does "except for those from File’s Owner to top-level objects in a nib file (or, in iOS, a storyboard scene)" mean?
        – Van Du Tran
        Mar 9 '12 at 15:55




        16




        16




        @VanDuTran - it means objects in the NIB that are at the root level, i.e. say you instantiated another view in there which isn't directly a subview of the main view, then it needs to have a strong reference.
        – mattjgalloway
        Mar 25 '12 at 16:59




        @VanDuTran - it means objects in the NIB that are at the root level, i.e. say you instantiated another view in there which isn't directly a subview of the main view, then it needs to have a strong reference.
        – mattjgalloway
        Mar 25 '12 at 16:59




        6




        6




        Top level means that when you look at the nib, the object appears in the list on the left. Almost all nibs have a UIView in them - this might be the only top level object. If you add other items, and they show in the list, they are "top level objects"
        – David H
        May 30 '12 at 17:29




        Top level means that when you look at the nib, the object appears in the list on the left. Almost all nibs have a UIView in them - this might be the only top level object. If you add other items, and they show in the list, they are "top level objects"
        – David H
        May 30 '12 at 17:29











        46














        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. ;)






        share|improve this answer























        • That is true, but you may still want to unload the view yourself. In which case you'd have to set all of your outlets to nil manually.
          – hypercrypt
          Dec 10 '13 at 22:10










        • PS: weak is a quite a bit cheaper in ARM64 :D
          – hypercrypt
          Dec 10 '13 at 22:11












        • That's right, if you implement view unloading, weak properties or __weak instance variables are the way to go. I just wanted to point out that there is less potential for error here. As for weak being cheaper on arm64, I have not even seen a real-life performance problem with weak IBOutlets on armv7. :)
          – Tammo Freese
          Dec 11 '13 at 8:47










        • Nor have I and your point is very valid.
          – hypercrypt
          Dec 11 '13 at 9:14






        • 1




          @Rocotilos The first iPhone had very limited RAM. If I recall correctly, 128 MB, leaving around 10 MB for the active app. Having a small memory footprint was crucial, hence there was view unloading. That changed as we now have more and more RAM, and Apple optimized UIViews in iOS 6, so that on memory warnings, a lot of memory can be freed without unloading the view.
          – Tammo Freese
          Sep 4 '16 at 16:11
















        46














        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. ;)






        share|improve this answer























        • That is true, but you may still want to unload the view yourself. In which case you'd have to set all of your outlets to nil manually.
          – hypercrypt
          Dec 10 '13 at 22:10










        • PS: weak is a quite a bit cheaper in ARM64 :D
          – hypercrypt
          Dec 10 '13 at 22:11












        • That's right, if you implement view unloading, weak properties or __weak instance variables are the way to go. I just wanted to point out that there is less potential for error here. As for weak being cheaper on arm64, I have not even seen a real-life performance problem with weak IBOutlets on armv7. :)
          – Tammo Freese
          Dec 11 '13 at 8:47










        • Nor have I and your point is very valid.
          – hypercrypt
          Dec 11 '13 at 9:14






        • 1




          @Rocotilos The first iPhone had very limited RAM. If I recall correctly, 128 MB, leaving around 10 MB for the active app. Having a small memory footprint was crucial, hence there was view unloading. That changed as we now have more and more RAM, and Apple optimized UIViews in iOS 6, so that on memory warnings, a lot of memory can be freed without unloading the view.
          – Tammo Freese
          Sep 4 '16 at 16:11














        46












        46








        46






        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. ;)






        share|improve this 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. ;)







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Jun 26 '16 at 8:32









        Aamir

        7,24363952




        7,24363952










        answered Dec 10 '13 at 21:54









        Tammo Freese

        8,67922944




        8,67922944












        • That is true, but you may still want to unload the view yourself. In which case you'd have to set all of your outlets to nil manually.
          – hypercrypt
          Dec 10 '13 at 22:10










        • PS: weak is a quite a bit cheaper in ARM64 :D
          – hypercrypt
          Dec 10 '13 at 22:11












        • That's right, if you implement view unloading, weak properties or __weak instance variables are the way to go. I just wanted to point out that there is less potential for error here. As for weak being cheaper on arm64, I have not even seen a real-life performance problem with weak IBOutlets on armv7. :)
          – Tammo Freese
          Dec 11 '13 at 8:47










        • Nor have I and your point is very valid.
          – hypercrypt
          Dec 11 '13 at 9:14






        • 1




          @Rocotilos The first iPhone had very limited RAM. If I recall correctly, 128 MB, leaving around 10 MB for the active app. Having a small memory footprint was crucial, hence there was view unloading. That changed as we now have more and more RAM, and Apple optimized UIViews in iOS 6, so that on memory warnings, a lot of memory can be freed without unloading the view.
          – Tammo Freese
          Sep 4 '16 at 16:11


















        • That is true, but you may still want to unload the view yourself. In which case you'd have to set all of your outlets to nil manually.
          – hypercrypt
          Dec 10 '13 at 22:10










        • PS: weak is a quite a bit cheaper in ARM64 :D
          – hypercrypt
          Dec 10 '13 at 22:11












        • That's right, if you implement view unloading, weak properties or __weak instance variables are the way to go. I just wanted to point out that there is less potential for error here. As for weak being cheaper on arm64, I have not even seen a real-life performance problem with weak IBOutlets on armv7. :)
          – Tammo Freese
          Dec 11 '13 at 8:47










        • Nor have I and your point is very valid.
          – hypercrypt
          Dec 11 '13 at 9:14






        • 1




          @Rocotilos The first iPhone had very limited RAM. If I recall correctly, 128 MB, leaving around 10 MB for the active app. Having a small memory footprint was crucial, hence there was view unloading. That changed as we now have more and more RAM, and Apple optimized UIViews in iOS 6, so that on memory warnings, a lot of memory can be freed without unloading the view.
          – Tammo Freese
          Sep 4 '16 at 16:11
















        That is true, but you may still want to unload the view yourself. In which case you'd have to set all of your outlets to nil manually.
        – hypercrypt
        Dec 10 '13 at 22:10




        That is true, but you may still want to unload the view yourself. In which case you'd have to set all of your outlets to nil manually.
        – hypercrypt
        Dec 10 '13 at 22:10












        PS: weak is a quite a bit cheaper in ARM64 :D
        – hypercrypt
        Dec 10 '13 at 22:11






        PS: weak is a quite a bit cheaper in ARM64 :D
        – hypercrypt
        Dec 10 '13 at 22:11














        That's right, if you implement view unloading, weak properties or __weak instance variables are the way to go. I just wanted to point out that there is less potential for error here. As for weak being cheaper on arm64, I have not even seen a real-life performance problem with weak IBOutlets on armv7. :)
        – Tammo Freese
        Dec 11 '13 at 8:47




        That's right, if you implement view unloading, weak properties or __weak instance variables are the way to go. I just wanted to point out that there is less potential for error here. As for weak being cheaper on arm64, I have not even seen a real-life performance problem with weak IBOutlets on armv7. :)
        – Tammo Freese
        Dec 11 '13 at 8:47












        Nor have I and your point is very valid.
        – hypercrypt
        Dec 11 '13 at 9:14




        Nor have I and your point is very valid.
        – hypercrypt
        Dec 11 '13 at 9:14




        1




        1




        @Rocotilos The first iPhone had very limited RAM. If I recall correctly, 128 MB, leaving around 10 MB for the active app. Having a small memory footprint was crucial, hence there was view unloading. That changed as we now have more and more RAM, and Apple optimized UIViews in iOS 6, so that on memory warnings, a lot of memory can be freed without unloading the view.
        – Tammo Freese
        Sep 4 '16 at 16:11




        @Rocotilos The first iPhone had very limited RAM. If I recall correctly, 128 MB, leaving around 10 MB for the active app. Having a small memory footprint was crucial, hence there was view unloading. That changed as we now have more and more RAM, and Apple optimized UIViews in iOS 6, so that on memory warnings, a lot of memory can be freed without unloading the view.
        – Tammo Freese
        Sep 4 '16 at 16:11











        34














        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 && IsEmpty(self.zip.text)) {
        id geocoder = [[geocoderClass alloc] init];
        [geocoder reverseGeocodeLocation:newLocation completionHandler:^(NSArray *placemarks, NSError *error) {
        if (self.zip && 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.






        share|improve this answer



















        • 4




          It is also my understanding that weak properties do not need to be nilled in viewDidUnload. But why does Apple’s template for creating outlets include a [self setMySubview:nil]?
          – Yang Meyer
          Jan 24 '12 at 8:20










        • @Yang, I'm wondering the same
          – Brenden
          May 22 '13 at 23:00






        • 3




          Is there any real world cases where using strong/retained for your IBOutlet could cause problem? Or is it just a redundant retain, which means bad coding style but wouldn't affect your code?
          – Enzo Tran
          Jun 13 '13 at 15:22






        • 1




          Is there such a thing as a redundant retain? If there's an extra retain, that will cause it to not be counted properly, and therefore won't be freed as soon as it could be since there's an extra retain on its retain count.
          – karlbecker_com
          Feb 25 '14 at 1:13
















        34














        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 && IsEmpty(self.zip.text)) {
        id geocoder = [[geocoderClass alloc] init];
        [geocoder reverseGeocodeLocation:newLocation completionHandler:^(NSArray *placemarks, NSError *error) {
        if (self.zip && 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.






        share|improve this answer



















        • 4




          It is also my understanding that weak properties do not need to be nilled in viewDidUnload. But why does Apple’s template for creating outlets include a [self setMySubview:nil]?
          – Yang Meyer
          Jan 24 '12 at 8:20










        • @Yang, I'm wondering the same
          – Brenden
          May 22 '13 at 23:00






        • 3




          Is there any real world cases where using strong/retained for your IBOutlet could cause problem? Or is it just a redundant retain, which means bad coding style but wouldn't affect your code?
          – Enzo Tran
          Jun 13 '13 at 15:22






        • 1




          Is there such a thing as a redundant retain? If there's an extra retain, that will cause it to not be counted properly, and therefore won't be freed as soon as it could be since there's an extra retain on its retain count.
          – karlbecker_com
          Feb 25 '14 at 1:13














        34












        34








        34






        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 && IsEmpty(self.zip.text)) {
        id geocoder = [[geocoderClass alloc] init];
        [geocoder reverseGeocodeLocation:newLocation completionHandler:^(NSArray *placemarks, NSError *error) {
        if (self.zip && 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.






        share|improve this 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 && IsEmpty(self.zip.text)) {
        id geocoder = [[geocoderClass alloc] init];
        [geocoder reverseGeocodeLocation:newLocation completionHandler:^(NSArray *placemarks, NSError *error) {
        if (self.zip && 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.







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Oct 11 '11 at 16:01

























        answered Oct 7 '11 at 22:34









        Christopher Pickslay

        15.2k57186




        15.2k57186








        • 4




          It is also my understanding that weak properties do not need to be nilled in viewDidUnload. But why does Apple’s template for creating outlets include a [self setMySubview:nil]?
          – Yang Meyer
          Jan 24 '12 at 8:20










        • @Yang, I'm wondering the same
          – Brenden
          May 22 '13 at 23:00






        • 3




          Is there any real world cases where using strong/retained for your IBOutlet could cause problem? Or is it just a redundant retain, which means bad coding style but wouldn't affect your code?
          – Enzo Tran
          Jun 13 '13 at 15:22






        • 1




          Is there such a thing as a redundant retain? If there's an extra retain, that will cause it to not be counted properly, and therefore won't be freed as soon as it could be since there's an extra retain on its retain count.
          – karlbecker_com
          Feb 25 '14 at 1:13














        • 4




          It is also my understanding that weak properties do not need to be nilled in viewDidUnload. But why does Apple’s template for creating outlets include a [self setMySubview:nil]?
          – Yang Meyer
          Jan 24 '12 at 8:20










        • @Yang, I'm wondering the same
          – Brenden
          May 22 '13 at 23:00






        • 3




          Is there any real world cases where using strong/retained for your IBOutlet could cause problem? Or is it just a redundant retain, which means bad coding style but wouldn't affect your code?
          – Enzo Tran
          Jun 13 '13 at 15:22






        • 1




          Is there such a thing as a redundant retain? If there's an extra retain, that will cause it to not be counted properly, and therefore won't be freed as soon as it could be since there's an extra retain on its retain count.
          – karlbecker_com
          Feb 25 '14 at 1:13








        4




        4




        It is also my understanding that weak properties do not need to be nilled in viewDidUnload. But why does Apple’s template for creating outlets include a [self setMySubview:nil]?
        – Yang Meyer
        Jan 24 '12 at 8:20




        It is also my understanding that weak properties do not need to be nilled in viewDidUnload. But why does Apple’s template for creating outlets include a [self setMySubview:nil]?
        – Yang Meyer
        Jan 24 '12 at 8:20












        @Yang, I'm wondering the same
        – Brenden
        May 22 '13 at 23:00




        @Yang, I'm wondering the same
        – Brenden
        May 22 '13 at 23:00




        3




        3




        Is there any real world cases where using strong/retained for your IBOutlet could cause problem? Or is it just a redundant retain, which means bad coding style but wouldn't affect your code?
        – Enzo Tran
        Jun 13 '13 at 15:22




        Is there any real world cases where using strong/retained for your IBOutlet could cause problem? Or is it just a redundant retain, which means bad coding style but wouldn't affect your code?
        – Enzo Tran
        Jun 13 '13 at 15:22




        1




        1




        Is there such a thing as a redundant retain? If there's an extra retain, that will cause it to not be counted properly, and therefore won't be freed as soon as it could be since there's an extra retain on its retain count.
        – karlbecker_com
        Feb 25 '14 at 1:13




        Is there such a thing as a redundant retain? If there's an extra retain, that will cause it to not be counted properly, and therefore won't be freed as soon as it could be since there's an extra retain on its retain count.
        – karlbecker_com
        Feb 25 '14 at 1:13











        20














        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).






        share|improve this answer



















        • 16




          It explains it as at 2009. With ARC, this has changed significantly.
          – Dafydd Williams
          Jul 19 '12 at 1:53






        • 1




          :( the Big Nerd Ranch link is dead… yet I really need to read it. Anyone knows more details about that post, so I can find it?
          – Motti Shneor
          Aug 9 '14 at 17:42










        • @MottiShneor don't worry, it's no big deal since the link was about times before ARC and is not relevant anymore.
          – Sergey Grischyov
          Aug 11 '14 at 9:45
















        20














        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).






        share|improve this answer



















        • 16




          It explains it as at 2009. With ARC, this has changed significantly.
          – Dafydd Williams
          Jul 19 '12 at 1:53






        • 1




          :( the Big Nerd Ranch link is dead… yet I really need to read it. Anyone knows more details about that post, so I can find it?
          – Motti Shneor
          Aug 9 '14 at 17:42










        • @MottiShneor don't worry, it's no big deal since the link was about times before ARC and is not relevant anymore.
          – Sergey Grischyov
          Aug 11 '14 at 9:45














        20












        20








        20






        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).






        share|improve this 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).







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Mar 30 '12 at 16:30









        Olivier Jacot-Descombes

        65.2k885136




        65.2k885136










        answered Oct 10 '11 at 16:02









        Giuseppe

        6,20121432




        6,20121432








        • 16




          It explains it as at 2009. With ARC, this has changed significantly.
          – Dafydd Williams
          Jul 19 '12 at 1:53






        • 1




          :( the Big Nerd Ranch link is dead… yet I really need to read it. Anyone knows more details about that post, so I can find it?
          – Motti Shneor
          Aug 9 '14 at 17:42










        • @MottiShneor don't worry, it's no big deal since the link was about times before ARC and is not relevant anymore.
          – Sergey Grischyov
          Aug 11 '14 at 9:45














        • 16




          It explains it as at 2009. With ARC, this has changed significantly.
          – Dafydd Williams
          Jul 19 '12 at 1:53






        • 1




          :( the Big Nerd Ranch link is dead… yet I really need to read it. Anyone knows more details about that post, so I can find it?
          – Motti Shneor
          Aug 9 '14 at 17:42










        • @MottiShneor don't worry, it's no big deal since the link was about times before ARC and is not relevant anymore.
          – Sergey Grischyov
          Aug 11 '14 at 9:45








        16




        16




        It explains it as at 2009. With ARC, this has changed significantly.
        – Dafydd Williams
        Jul 19 '12 at 1:53




        It explains it as at 2009. With ARC, this has changed significantly.
        – Dafydd Williams
        Jul 19 '12 at 1:53




        1




        1




        :( the Big Nerd Ranch link is dead… yet I really need to read it. Anyone knows more details about that post, so I can find it?
        – Motti Shneor
        Aug 9 '14 at 17:42




        :( the Big Nerd Ranch link is dead… yet I really need to read it. Anyone knows more details about that post, so I can find it?
        – Motti Shneor
        Aug 9 '14 at 17:42












        @MottiShneor don't worry, it's no big deal since the link was about times before ARC and is not relevant anymore.
        – Sergey Grischyov
        Aug 11 '14 at 9:45




        @MottiShneor don't worry, it's no big deal since the link was about times before ARC and is not relevant anymore.
        – Sergey Grischyov
        Aug 11 '14 at 9:45











        16














        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.







        share|improve this answer



















        • 1




          Great answer that explains the actual reason -why-
          – micnguyen
          Feb 9 '17 at 2:49










        • That is good and all but i have seen leaks coming from gesture recognizers implemented in storyboard.
          – thibaut noah
          May 11 '17 at 12:28






        • 2




          I still get weak as the default (Xcode 8)
          – Fonix
          Jun 12 '17 at 13:54
















        16














        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.







        share|improve this answer



















        • 1




          Great answer that explains the actual reason -why-
          – micnguyen
          Feb 9 '17 at 2:49










        • That is good and all but i have seen leaks coming from gesture recognizers implemented in storyboard.
          – thibaut noah
          May 11 '17 at 12:28






        • 2




          I still get weak as the default (Xcode 8)
          – Fonix
          Jun 12 '17 at 13:54














        16












        16








        16






        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.







        share|improve this 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.








        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Nov 17 '17 at 9:40

























        answered Nov 4 '15 at 4:27









        onmyway133

        24.3k14157190




        24.3k14157190








        • 1




          Great answer that explains the actual reason -why-
          – micnguyen
          Feb 9 '17 at 2:49










        • That is good and all but i have seen leaks coming from gesture recognizers implemented in storyboard.
          – thibaut noah
          May 11 '17 at 12:28






        • 2




          I still get weak as the default (Xcode 8)
          – Fonix
          Jun 12 '17 at 13:54














        • 1




          Great answer that explains the actual reason -why-
          – micnguyen
          Feb 9 '17 at 2:49










        • That is good and all but i have seen leaks coming from gesture recognizers implemented in storyboard.
          – thibaut noah
          May 11 '17 at 12:28






        • 2




          I still get weak as the default (Xcode 8)
          – Fonix
          Jun 12 '17 at 13:54








        1




        1




        Great answer that explains the actual reason -why-
        – micnguyen
        Feb 9 '17 at 2:49




        Great answer that explains the actual reason -why-
        – micnguyen
        Feb 9 '17 at 2:49












        That is good and all but i have seen leaks coming from gesture recognizers implemented in storyboard.
        – thibaut noah
        May 11 '17 at 12:28




        That is good and all but i have seen leaks coming from gesture recognizers implemented in storyboard.
        – thibaut noah
        May 11 '17 at 12:28




        2




        2




        I still get weak as the default (Xcode 8)
        – Fonix
        Jun 12 '17 at 13:54




        I still get weak as the default (Xcode 8)
        – Fonix
        Jun 12 '17 at 13:54











        11














        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.






        share|improve this answer


























          11














          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.






          share|improve this answer
























            11












            11








            11






            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.






            share|improve this 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.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered May 5 '16 at 21:25









            syedfa

            1,63613058




            1,63613058























                9














                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.






                share|improve this answer





















                • Interesting. I guess this changed when view unloading was removed?
                  – hypercrypt
                  Jul 9 '15 at 14:45
















                9














                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.






                share|improve this answer





















                • Interesting. I guess this changed when view unloading was removed?
                  – hypercrypt
                  Jul 9 '15 at 14:45














                9












                9








                9






                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.






                share|improve this 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.







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Jul 9 '15 at 13:11









                Johannes

                6,694135780




                6,694135780












                • Interesting. I guess this changed when view unloading was removed?
                  – hypercrypt
                  Jul 9 '15 at 14:45


















                • Interesting. I guess this changed when view unloading was removed?
                  – hypercrypt
                  Jul 9 '15 at 14:45
















                Interesting. I guess this changed when view unloading was removed?
                – hypercrypt
                Jul 9 '15 at 14:45




                Interesting. I guess this changed when view unloading was removed?
                – hypercrypt
                Jul 9 '15 at 14:45











                6














                Be aware, IBOutletCollection should be @property (strong, nonatomic).






                share|improve this answer

















                • 3




                  Why not copy as it is an NSArray?
                  – hypercrypt
                  Mar 25 '14 at 13:16
















                6














                Be aware, IBOutletCollection should be @property (strong, nonatomic).






                share|improve this answer

















                • 3




                  Why not copy as it is an NSArray?
                  – hypercrypt
                  Mar 25 '14 at 13:16














                6












                6








                6






                Be aware, IBOutletCollection should be @property (strong, nonatomic).






                share|improve this answer












                Be aware, IBOutletCollection should be @property (strong, nonatomic).







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Mar 25 '14 at 13:02









                landonandrey

                4711720




                4711720








                • 3




                  Why not copy as it is an NSArray?
                  – hypercrypt
                  Mar 25 '14 at 13:16














                • 3




                  Why not copy as it is an NSArray?
                  – hypercrypt
                  Mar 25 '14 at 13:16








                3




                3




                Why not copy as it is an NSArray?
                – hypercrypt
                Mar 25 '14 at 13:16




                Why not copy as it is an NSArray?
                – hypercrypt
                Mar 25 '14 at 13:16











                5














                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.






                share|improve this answer




























                  5














                  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.






                  share|improve this answer


























                    5












                    5








                    5






                    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.






                    share|improve this 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.







                    share|improve this answer














                    share|improve this answer



                    share|improve this answer








                    edited Aug 7 '15 at 9:01

























                    answered Aug 7 '15 at 8:28









                    Julian Król

                    7,81043759




                    7,81043759























                        4














                        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






                        share|improve this answer


























                          4














                          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






                          share|improve this answer
























                            4












                            4








                            4






                            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






                            share|improve this 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







                            share|improve this answer












                            share|improve this answer



                            share|improve this answer










                            answered Dec 4 '12 at 14:49









                            kraag22

                            2,03412228




                            2,03412228






























                                draft saved

                                draft discarded




















































                                Thanks for contributing an answer to Stack Overflow!


                                • Please be sure to answer the question. Provide details and share your research!

                                But avoid



                                • Asking for help, clarification, or responding to other answers.

                                • Making statements based on opinion; back them up with references or personal experience.


                                To learn more, see our tips on writing great answers.





                                Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


                                Please pay close attention to the following guidance:


                                • Please be sure to answer the question. Provide details and share your research!

                                But avoid



                                • Asking for help, clarification, or responding to other answers.

                                • Making statements based on opinion; back them up with references or personal experience.


                                To learn more, see our tips on writing great answers.




                                draft saved


                                draft discarded














                                StackExchange.ready(
                                function () {
                                StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f7678469%2fshould-iboutlets-be-strong-or-weak-under-arc%23new-answer', 'question_page');
                                }
                                );

                                Post as a guest















                                Required, but never shown





















































                                Required, but never shown














                                Required, but never shown












                                Required, but never shown







                                Required, but never shown

































                                Required, but never shown














                                Required, but never shown












                                Required, but never shown







                                Required, but never shown







                                Popular posts from this blog

                                If I really need a card on my start hand, how many mulligans make sense? [duplicate]

                                Alcedinidae

                                Can an atomic nucleus contain both particles and antiparticles? [duplicate]