Swift Closures Memory Hell

Hi everyone, let talk about one of the simplest but trickiest things in Swift: Closures and ARC. Automatic Reference Counter is a simple topic, as well as closures. And it is easy to manage memory problems in swift. For most of the time, you just need to know what strong reference cycles(also known as “retain cycle”) are and how to prevent them(Spoiler alert! Use weak and unowned keywords in appropriate places).

However, I see many iOS developers understanding how ARC works but they suddenly forget their knowledge when they work with closures and functions. They either do not use weak and unowned or put weak in every closure they encounter. Which eventually ends up with memory leaks or weird bugs due to early object release, or sometimes I see code like this 😂:

Swift

1

2

3

4

5

6

7

closure{[weakself]in

guard letstrongSelf=selfelse{

self?.presentError()

return

}

...

}

So let’s dive into the code to clarify the relation between closures and ARC. You can find a source code here.

We will have a simple class named Ball, which has a stored closure. And to illustrate that Ball object deinitialized, we’re going to print “Ball destroyed” message to the console.

Swift

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

classBall{

private varonKickCallback:(()->Void)?

funckick(){

onKickCallback?()

}

funconKick(callback:(()->Void)?){

onKickCallback=callback

}

deinit{

print("Ball destroyed")

}

}

Next, let’s create Player class which will work with our Ball class. Player will have a stored property of type string, and deinitializer with the print method in it.

Swift

1

2

3

4

5

6

7

8

9

10

11

classPlayer{

letname:String

init(name:String){

self.name=name

}

deinit{

print("Player \(name) destroyed")

}

}

In the first example let the closure in Ball class capture Player class, and see the order of deinits.

Swift

1

2

3

4

5

6

7

8

9

letball=Ball()

iftrue{

letjohn=Player(name:"John")

ball.onKick{

print(john.name+" kicked the ball")

}

}

ball.kick()

So, we create a Ball object and local scoped Player object. And in that scope ball captures john object. And here is the output.

Output

Swift

1

2

3

John kicked the ball

Ball destroyed

Player John destroyed

As we can see even though john object’s scope ended first, it released after the ball object. Which is totally fine according to ARC. And you need to keep this aspect in mind, especially when working with singletons. Because if singleton captures some reference type object, that object won’t be released until closure gets rewritten, otherwise it never deinits and remains in the memory.

Now, let’s add weak or unowned keyword, to the closure’s body and changing the last block of code. And it is going to look like this:

Swift

1

2

3

4

5

6

7

8

9

10

letball=Ball()

iftrue{

letjohn=Player(name:"John")

ball.onKick{[weakjohn]in

guard letjohn=johnelse{return}

print(john.name+" kicked the ball")

}

}

ball.kick()

In this case, by using weak keyword the Ball object is not even holding a Player object. We used weak reference on the object which is not holding any reference to back to its holder. Let look and compare the outputs:

Swift

1

2

Player John destroyed

Ball destroyed

So, the first thing to notice by comparing with previous output is that Ball’s method kick doesn’t print anything. Second, the order of deinitializers changed. The john property releases independently to ball object. Which means ball didn’t have any reference to john object. So, if a closure captures some reference type object with the weak or unowned keyword and that object is not holding any reference back to the holder of the closure, you should know that object isn’t likely to survive if it hits its scope end. And most of the developers make this mistake, by putting weak in every closure they write. Maybe, just in case to prevent the memory leak, but it ends up with the unexpected behavior of an app.

Next, let’s make Player class hold a reference to a Ball class. With the slight changes of Player class, the code:

Swift

1

2

3

4

5

6

7

8

9

10

11

12

13

classPlayer{

letname:String

letball:Ball

init(name:String,ball:Ball){

self.name=name

self.ball=ball

}

deinit{

print("Player \(name) destroyed")

}

}

So, the only difference is that Player owns a ball property and initializes it through init constructor method. We’re going to use the code from the first example, and see how things will change.

Swift

1

2

3

4

5

6

7

8

9

letball=Ball()

iftrue{

letjohn=Player(name:"John",ball:ball)

ball.onKick{

print(john.name+" kicked the ball")

}

}

ball.kick()

It’s almost the same code, with a slight difference in Player construction due to new ball parameter passing to the object. The output:

Swift

1

John kicked the ball

As you can see, objects don’t even get released from the memory. That happens because the player is holding the reference to the ball object, meanwhile, a ball object holds a reference to a player object in its closure. And this is how a retain cycle looks like. Since both objects holding each other, they can’t be destroyed. As ARC sees that there are references to the object, that object is never gets destroyed, unless the object holding the reference deinits.

To fix that issue, we will weakly capture john property in balls closure body. And our code is going to look like this:

Swift

1

2

3

4

5

6

7

8

9

10

letball=Ball()

iftrue{

letjohn=Player(name:"John",ball:ball)

// If you put unowned instead of weak it's going to crash

ball.onKick{[weakjohn]in

guard letjohn=johnelse{return}

print(john.name+" kicked the ball")

}

}

ball.kick()

As you can see we capture john object weakly. And this code will crash if try to use unowned instead of weak. Because once john hits the end of its scope it deinits. But the ball object will remain alive, and by calling onKick method it will inevitably use dead john reference. So, be careful with those things. Output:

Swift

1

2

Player John destroyed

Ball destroyed

We don’t see John kicking the ball, because he didn’t survive after hitting the end of his scope.

Conclusion

Before we move to the key points, I have a good association for how ARC operates for you: It’s like I’m holding you and you’re holding me, so we both can’t fall. And if you don’t hold me, but I’m still holding you, you won’t fall. But in case, if I fall, we both fall. Maybe that will help you to understand =)

Do not forget that ARC principles apply to closures, functions, and reference type objects

If any property or method of the class is holding any reference to any other reference type object that means your class captured that reference. Functions will start holding the reference only once they get called.

Captured reference will not deinit until the object holding it releases that object or releases itself.

Use weak and unowned wisely. Use them only if you have two objects holding references to each other and use it by looking at the context, by understanding which one should look at another weakly.

If you’re using a singleton and that singleton captures some other object, you need to think about the time when to release that object from the memory