Uplift iOS Interview
The Guide is for YOU if
- You are preparing for an iOS interview and want to improve your skills and knowledge and looking to level up your interview game and land your dream job.
- You want to gain confidence and ease during iOS interviews by learning expert tips and curated strategies.
- You want access to a comprehensive list of iOS interview QA to practice and prepare.
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.”
✍️ Written by Ishtiak Ahmed
👉 Follow me on X ● LinkedIn
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.