ARC & when to use strong, weak, unowned

Uplift iOS Interview

"Uplift iOS Interview" is a comprehensive guide to help aspiring iOS developers soar to new heights in their careers. This book is an indispensable tool for anyone looking to crack the iOS interview and impress their future employers with their technical prowess. With in-depth coverage of Swift, AutoLayout, SwiftUI, Multithreading, Memory management so on and so forth, this book is a treasure trove of knowledge for anyone looking to uplift their iOS development career.

Memory management is one of the important concept when it comes to mobile application development. Memory leaks and app crashes are very common due to poorly managed memory in iOS apps. In this short article, I will describe ARC and the use of strong, weak and unowned.

ARC/Automatic Reference Counting

Swift uses Automatic Reference Counting for maintaining memory footprint. It figures out when the objects should be deallocated based on retain count. Each object increases the retain count when it is allocated strong reference is assigned to that object. An object’s retain count is decreased by 1 when a strong reference is removed from that object. When the total retain count reaches 0 the object is deallocated from the memory by ARC.

Strong

Swift uses a strong reference by default. If you create a variable, constant or property for a reference type, it is strong type by default unless you declare it as weak or unowned. This is also true for passing references into functions or closures. Strong references in Swift increment the retain count each time it is allocated. When you are using strong reference you need to consider checking retain cycle and memory leaks.
A retain cycle will happen when multiple instances all retain strong references to each other. In this case those instances will not be deallocated from memory. We will have memory leak caused by retain cycle. One of the simple solution for handling retain cycle is using weak and unowned.

Weak

A weak reference will not increase the retain count of an instance. As weak reference will not increment the retain count of an instance it will be deallocated. The approach is to break the strong reference of an instance by using weak by which it can be deallocated. A delegate property is weak by design, because it would cause a strong reference cycle otherwise. A table view controller’s dataSource property is made weak. If it would be strong, the table view controller and data source would strongly hold onto each other and cause a memory leak.
Closure can capture variables, properties, etc. from its surrounding scope. When the closure outlives the scope it was declared in, it can strongly hold onto objects from that scope. This can cause a strong reference cycle.

Unowned

Unowned is same as weak, except that the referenced instance is not an optional.  It must not be nil when it is accessed. because accessing an unowned reference when the instance the reference points to nil will cause an error. According to Apple’s docs:

“Use a weak reference whenever it is valid for that reference to become nil at some point during its lifetime. Conversely, use an unowned reference when you know that the reference will never be nil once it has been set during initialization.”


Rev Up Your iOS Skills: Take a Dynamic Learning Journey
iOS Career Boost

iOS Career Boost is the ultimate learning journey to elevate your iOS development career through a dynamic blend of visual learning, handy cheat sheets, coding practice materials, and expertly curated tips and tricks


Get Ready to Shine: Mastering the iOS Interview


Enjoying the articles? Get the inside scoop by subscribing to my newsletter.

Get access to exclusive iOS development tips, tricks, and insights when you subscribe to my newsletter. You'll also receive links to new articles, app development ideas, and an interview preparation mini book. Your email address will only be used for the purpose of sending the newsletter and will not be shared with third parties or advertisers. Rest assured that we value your privacy and will not spam your inbox.


Connect with me on

Twitter and LinkedIn and don't hesitate to reach out with any questions about this post. Thank you for reading.

If you know someone who would benefit from reading this article, please share it with them.