Swift: Don’t Forget To Keep Your IBOutlets Private!

In Objective-C, I’ve always put my IBOutlets into the method (m) file, making them private by default.

For those who might be new to iOS, an IBOutlet is a reference to an view on your Storyboard. So for example, in my sample Seinfeld Quotes app, I have a custom QuoteTableViewCell on the Storyboard:


When I drag the two labels – the quoteContentLabel and the scenarioLabel – into my QuoteTableViewCell, by default, the IBOutlet that’s created is not private in Swift:


The reason I like to keep IBOutlets very private is because I don’t like the idea of any other class setting the content for my label. For example, here is my configure method for the QuoteTableViewCell:

Configure TableViewCell

I want the labels configured in a very specific way – with a custom font and content. No other class should be able to change the textColor or fontSize of the label text, for example.

Maybe Apple will add a private option when creating the default IBOutlet, for now, I’ll have to remember to always add the private keyword to my IBOutlets!

Private IBOutlet

Enjoy the article? Join over 17,500+ Swift developers and enthusiasts who get my weekly updates.

  • David Owens

    Great article! I think this is a pretty wise thing to make habit. I find myself backtracking sometimes to find out what is sabotaging my innocent UILabels.

  • Mark Patterson

    I totally agree with you. And I hope Apple make private available and default.

  • Abizer Nasir

    Have you filed a radar?

  • Kristofer Doman

    Do we need to put private before everything in the class if it’s meant to be private? I don’t really like that, it took swift from being simple looking, to overcrowded with keywords.

    • Yes, everything is internal by default, so you have to put private for all variables and functions you want private… Might change in the future, since it’s still in beta 🙂

    • LegendLength

      That being said it’s supposedly good practice to avoid private members of any kind, so their decision makes some sense. I agree with the sentiment though swift looks lovely on the surface but there’s a lot of things they haven’t thought through.

  • Awesome! Question: any reason why you’re specifying ‘weak’ in the IBOutlet declaration? Unless I’ve missed something in the latest beta release notes – IBOutlet’s are weak by default.

    • The weak was the default when connecting from the storyboard in the beta I was in (haven’t checked lately).

    • qalandarov

      It’s not a Swift thing setting them as `weak` – it was the same even with Objective-C. The reason behind this is that the IBOutlet object is held strongly by the view, it’s parent, which is strongly held by the View Controller – so no need to increase the retain count of the IBOutlet.
      (Sorry for the late response, but I hope it will benefit someone in the future)

  • Paul

    I haven’t had the time yet to devote to Swift (actually still learning Obj-C), but I definitely hope Apple makes these connections private by default, as that’s the correct way to do it in Obj-C.

  • James Richard

    I believe setting them as privately settable, but publicly accessible is better. That way you can use the controls during application testing.

  • Alexandr Graschenkov

    HI. For outlets I always use snippets. Split window with dragging outlet from IB take a lot of time, cause you must use mouse.. (IMHO)

    What you think about type of outlets in view controller, should they be with exclamation mark or question mark? I usually don’t unload views in memory warning notification, but if in someday add unload views and then I need rewrite my code with question mark…

  • Alexandr Graschenkov


  • Awesome.