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 20,000+ 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)

    • Michael Nguyen

      For anyone that reads this in the future, IBOutlets should be strong. It is weak by default when you drag them in, but whem you do set them as strong, it will stay that way. For brevit, omit the strong/weak for it to be strong by default. Ref: https://stackoverflow.com/a/31395938/794646

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