In iOS development, what is the correct way to manage IBOutlet outlet memory references under ARC when connecting user interface elements from storyboards or nib files?

Introduction / Context:
Managing memory for user interface outlets in iOS is important for preventing leaks and retain cycles. With Automatic Reference Counting (ARC), much of the manual memory management burden is removed, but developers still need to choose property attributes correctly. This question checks whether you understand how IBOutlets are typically declared under ARC when using storyboards or nib files.

Given Data / Assumptions:

• The project uses ARC rather than manual retain and release calls.
• User interface elements are created in Interface Builder and connected via IBOutlets to view controller properties.
• The view controller owns a main view hierarchy that is managed by the system.

Concept / Approach:
Under ARC, the main view of a view controller is strongly held by the system, and that view strongly references its subviews. If outlet properties were also strong in the view controller for every subview, circular references could occur or at least unnecessary strong ownership would exist. For this reason, common guidance is to declare IBOutlets for subviews as weak. The storyboard or nib keeps them alive as part of the main view hierarchy, and when the view is unloaded, weak outlets are automatically set to nil, preventing stale references.

Step-by-Step Solution:
Step 1: Recognize that the view hierarchy created from a nib or storyboard is owned strongly by the view controller main view property.Step 2: Understand that subviews are strongly retained by their superviews, so they do not need additional strong references from the view controller.Step 3: Declare outlet properties that point to these subviews as weak, allowing them to be set to nil automatically when the view hierarchy is torn down.Step 4: Avoid using assign for object references under ARC, because assign does not interact correctly with reference counting for objects.Step 5: Therefore the best practice is described in option A, where outlets are weak and memory is managed by ARC and the view hierarchy itself.

Verification / Alternative check:
Apple templates and Xcode generated code usually declare connection outlets as weak for UIKit views under ARC. Some exceptions exist for top level objects that must be strongly owned, but for typical subviews, weak is standard. This consistent pattern, combined with documentation, confirms that option A expresses the recommended approach.

Why Other Options Are Wrong:
Option B is incorrect because assign should not be used for Objective C objects under ARC and it does not address clearing references when views are unloaded. Option C incorrectly suggests global variables, which complicate memory management and design. Option D contradicts the premise of ARC by calling for manual retain and release, which is both unnecessary and unsupported with ARC enabled.

Common Pitfalls:
Developers sometimes mark all outlets as strong without understanding the ownership graph, potentially causing retain cycles or keeping entire view hierarchies in memory longer than needed. Another pitfall is failing to understand when outlets become nil, leading to crashes when accessing them after the view has been unloaded. Following the weak outlet convention for subviews helps applications behave efficiently and avoids many subtle bugs.

Final Answer:
Under ARC, outlet properties for user interface elements are typically declared as weak for views in a nib or storyboard to avoid retain cycles, and they are automatically cleared when the view is unloaded.