Like Objective C, Swift makes use of automatic reference counting or ARC. 0:00 Many of the considerations you need to make are similar to Objective C, 0:05 though overall you actually have even less to worry about. 0:09 In this video, we won't repeat all the theory but 0:12 we will focus on what's different in Swift memory management, and 0:15 a few of the most common snags developers hit. 0:18 The first thing you'll notice as different in Swift memory management 0:21 is that we aren't explicitly declaring memory directives like strong and 0:24 copy, like they would be in Objective C property declarations like this. 0:28 In Swift, all properties of a class are assumed to be strong, so 0:33 you'd simply write them like this. 0:36 [SOUND] No strong required. 0:38 Of course Swift, like objective C, isn't immune to retain cycles. 0:40 So often, you will need to explicitly request a weak reference, for 0:44 instance, between a parent and a child. 0:48 To do this, you do need to use the keyword, weak. 0:50 In this example, we can imagine that a person may, or may not have a car. 0:53 When the person object is active in the app, we would want that reference. 0:57 When that person is set to nil, which could happen for any number of reasons, 1:01 we would wanna release the car object and the person object. 1:05 If there were strong references in both directions, that would never happen. 1:09 Now in the person car example, both objects could be nil. 1:14 Neither a person nor a car must exist in order for the other to exist, but 1:17 what about situation where one of the objects could never be nil? 1:22 For example, let's say we have a user and a user avatar. 1:26 In this scenario, a user might elect not to have a user avatar, and 1:31 instead just display some placeholder image. 1:35 However on the flip side, a user avatar must be associated with a user. 1:38 Without being link to a user, it wouldn't have any meaning in our app. 1:43 In this case, instead of using a weak reference like this, 1:46 we would use an unowned reference like so. 1:50 The last variant on this situation is one in which 1:54 neither member of the relationship should ever be nil. 1:57 For example, between two objects, mobileDevice and SerialNumber. 2:00 Neither should exist without a link to the other. 2:05 Here you see our solution was to combine one explicitly unwrapped optional, 2:08 that's the exclamation point following the SerialNumber property 2:13 of the mobileDevice class, 2:15 along with an unowned reference pointing from the SerialNumber to the mobileDevice. 2:17 If you need a refresher on unwrapped optionals, check below for a helpful link. 2:23 Given that blocks in Objective C are susceptible to memory issues, 2:27 it isn't surprising that their Swift counterpart, closures, are as well. 2:31 Now a closure could cause a strong reference cycle in a few ways. 2:36 But generally it would occur when you assign a closure to a property of a class 2:40 instance and that closure itself is actually capturing the instance. 2:44 Imagine the closure is capturing self.myproperty or 2:49 self.mymethod, common things you might place in a closure, right? 2:53 Well in both situations, you've now captured self and 2:57 therein have given yourself a strong reference cycle. 3:01 The solution for this problem is creating something called a capture list. 3:04 Simply put, 3:08 a capture list lets you explicitly specify how you capture constants and 3:09 variables in a closure, and what special memory handling you might want. 3:13 Getting into the nitty gritty of closures and 3:18 capture lists are beyond the scope of this overview, but 3:20 if it interests you or if you think your code might be subject to this issue, 3:23 I'd direct you to the Apple documentation linked below in the teacher's notes. 3:27