Like Objective C, Swift makes use of automatic reference counting or ARC.

Many of the considerations you need to make are similar to Objective C,

though overall you actually have even less to worry about.

In this video, we won't repeat all the theory but

we will focus on what's different in Swift memory management, and

a few of the most common snags developers hit.

The first thing you'll notice as different in Swift memory management

is that we aren't explicitly declaring memory directives like strong and

copy, like they would be in Objective C property declarations like this.

In Swift, all properties of a class are assumed to be strong, so

you'd simply write them like this.

[SOUND] No strong required.

Of course Swift, like objective C, isn't immune to retain cycles.

So often, you will need to explicitly request a weak reference, for

instance, between a parent and a child.

To do this, you do need to use the keyword, weak.

In this example, we can imagine that a person may, or may not have a car.

When the person object is active in the app, we would want that reference.

When that person is set to nil, which could happen for any number of reasons,

we would wanna release the car object and the person object.

If there were strong references in both directions, that would never happen.

Now in the person car example, both objects could be nil.

Neither a person nor a car must exist in order for the other to exist, but

what about situation where one of the objects could never be nil?

For example, let's say we have a user and a user avatar.

In this scenario, a user might elect not to have a user avatar, and

instead just display some placeholder image.

However on the flip side, a user avatar must be associated with a user.

Without being link to a user, it wouldn't have any meaning in our app.

In this case, instead of using a weak reference like this,

we would use an unowned reference like so.

The last variant on this situation is one in which

neither member of the relationship should ever be nil.

For example, between two objects, mobileDevice and SerialNumber.

Neither should exist without a link to the other.

Here you see our solution was to combine one explicitly unwrapped optional,

that's the exclamation point following the SerialNumber property

of the mobileDevice class,

along with an unowned reference pointing from the SerialNumber to the mobileDevice.

If you need a refresher on unwrapped optionals, check below for a helpful link.

Given that blocks in Objective C are susceptible to memory issues,

it isn't surprising that their Swift counterpart, closures, are as well.

Now a closure could cause a strong reference cycle in a few ways.

But generally it would occur when you assign a closure to a property of a class

instance and that closure itself is actually capturing the instance.

Imagine the closure is capturing self.myproperty or

self.mymethod, common things you might place in a closure, right?

Well in both situations, you've now captured self and

therein have given yourself a strong reference cycle.

The solution for this problem is creating something called a capture list.

Simply put,

a capture list lets you explicitly specify how you capture constants and

variables in a closure, and what special memory handling you might want.

Getting into the nitty gritty of closures and

capture lists are beyond the scope of this overview, but

if it interests you or if you think your code might be subject to this issue,

I'd direct you to the Apple documentation linked below in the teacher's notes.