---
title: "iOS : IBOutlet of UI Element"  
description: "An IBOutlet connection is usually established between a view or control and its managing view controller (this is often done in addition to any IBActi"  
author: "Tarun Kumar"  
published: 2015-07-20  
updated: 2018-03-13  
canonical: https://www.mindstick.com/blog/10931/ios-iboutlet-of-ui-element  
category: "iphone"  
tags: ["iphone", "ios", "objective c"]  
reading_time: 2 minutes  

---

# iOS : IBOutlet of UI Element

An IBOutlet [connection](https://www.mindstick.com/articles/13012/what-makes-ethernet-connection-better-than-wifi) is usually established between a view or control and its managing [view controller](https://www.mindstick.com/forum/33636/how-to-push-a-view-controller-to-another-view-controller) (this is [often done](https://answers.mindstick.com/qa/40965/how-do-movements-in-the-charleston-dance-from-the-1920s-reflect-the-time-in-which-it-was-often-done) in addition to any IBActions that a view controller might be targeted to perform by a [responder](https://www.mindstick.com/interview/23134/what-is-the-first-responder-and-responder-chain-in-ios)). However, an IBOutlet can also be used to expose a top-level [property](https://www.mindstick.com/blog/205/property-notification-in-c-sharp), like another controller or a property that could then be accessed by a referencing view controller.

\
When to use @property or ivar

As with anything in modern Objective-C, [properties](https://www.mindstick.com/articles/23331/nootropics-7-different-types-and-their-unique-properties) are preferred to direct ivar access. The same is true of IBOutlets:

```
// YES@interface MyController : UIViewController@property (nonatomic, weak) IBOutlet UISwitch *switch;@end // NO@interface Sample: UIViewController {    IBOutlet UISwitch *_switch}@end
```

Since properties are the conventional way to expose and access members of a class, both externally and internally, they are preferred in this case as well, if only for consistency.

When to use weak or strong

One unfortunate consequence (if you want to call it that) of ARC is the ambiguity of when a IBOutlet @property should be [declared as](https://www.mindstick.com/interview/2711/what-if-the-main-method-is-declared-as-private) weak or strong. The ambiguity arises from the fact that most outlets have no discernible behavioral [differences](https://www.mindstick.com/articles/12918/cat-5e-vs-cat-6a-understanding-the-major-differences) between weak or strong—it just works.

\
…except when it doesn't… and things crash, or the [compiler](https://www.mindstick.com/articles/27/just-in-time-compiler) warns about weak or strong use.

So what should one do? Always declare IBOutlet properties as weak, except when they need to be strong.

\

##### Outlets should be changed to strong when the outlet should be

##### considered to own the referenced object:

\
· This is often the case with File’s Owner—top level objects in a nib file are frequently considered to be owned by the File’s Owner.

\
· You may in some situations need an object from a nib file to exist outside of its original container. For example, you might have an outlet for a view that can be temporarily removed from its initial view hierarchy and must therefore be maintained independently.

\
· The reason why most IBOutlet views can get away with weak ownership is that they are already owned within their respective view hierarchy, by their superview. This chain of ownership eventually works its way up to the view owned by the view controller itself. Spurious use of strong ownership on a view outlet has the potential to create a retain cycle.

---

Original Source: https://www.mindstick.com/blog/10931/ios-iboutlet-of-ui-element

Copyright © MindStick Software Pvt. Ltd. This Markdown version is provided for developers, AI systems, and offline reading.