There’s clearly some confusion out there among iPhone developers about whether or not you need to release your IBOutlets. It’s actually pretty simple.

When UIKit loads a NIB file, it sets up all your IBOutlets for you. That is, after all, then entire point of an IBOutlet! UIKit does this using setValue:forKey: which is part of the NSKeyValueCoding Protocol. The important things to know about it are:

  • If you have a setter method (which you will if you have defined it as an @property), UIKit will call that
  • If you have not defined a setter, then UIKit will directly set the value of the instance variable and then, for anything other than an NSNumber or NSValue date type, UIKit will retain the value after autoreleasing the instance variable’s old value.

The consequence of this is that unless you define your IBOutlets as

@property (..., assign)

then you need to worry about cleaning them up at dealloc time. A good way to do this is to ensure that you always define an IBOutlet as an @property, and then to simply to set their values to nil in your dealloc implementation, like this:

-(void)dealloc {
    self.outlet1 = nil;
    self.outlet2 = nil;
    [super dealloc];
}

Setting them to nil will work regardless of how you set up the @property – i.e. whether it is a ‘retain’-type or an ‘assign’-type property.

You also need to worry about IBOutlets in UIViewController when handling didReceiveMemoryWarning, but that’s a story for another post.

4 thoughts on “Memory Management and NIBs on the iPhone

    • I read the article you reference, but I’m missing the point.

      a) I was suggesting that accessors were useful because if you swap from assign to retain properties or vice versa, everything still works
      b) I see no immediate reason not to use accessor methods for properties in dealloc. Obviously they should not be used after calling [super dealloc] – but that should be the last thing you do anyway. Obviously you should also be aware of side-effects – but it is the side effect of the implicit release call that I specifically want here! You may argue that the order in which the accessors are called matters, or that they have other side effects that cannot be easily handled – I would argue that is a deficiency in the design and makes the code brittle in its own right – and should be fixed, rather than working around it.
      c) The article you reference indicates that UIViewController itself calls an accessor method in dealloc – the specific construct you are saying is bad.
      d) How do you have a declared property without having an accessor? I admit it will compile, but you will get a warning.

      Reply
      • On the point about using assign on an IBOutlet property: not sure this is such a good idea. If you don’t retain your IBOutlet it’s quite possible to have bits and pieces failing to remain loaded after you load from the NIB, if they’re not immediately pushed onto a view or controller somewhere that will retain them. The expectation of a user of a class using the interface builder is that something attached to an IBOutlet will get retained.

        On the point about dealloc methods. The ‘.’ accessor syntax is confusing for anyone who’s not too familiar with Objective C, and there are situations in which setX accessors with side-effects are useful such as in a utility class. Moreover, setX accessors can be overridden by subclasses, which is a good reason why calling them from dealloc probably isn’t such a good idea, since the subclass will already have dealloc’d.

        Reply

Leave a reply

required

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>