If you have a Dog with a weak reference to Bone, that means that the Dog is the 'owner' of the reference in this situation, and it USES bone, but bone can go out of existence and Dog can still function (because the reference to bone is an optional).
However with 'unowned', it seems to be that the keyword 'unowned' is used not in the owner's declaration of the reference, but in the other object. For instance, Bone's reference to its dog is marked as 'unowned'.
Unowned is not safe. It can crash if the owner goes out of existence at some point in the program, and it cannot be an optional. Why would one ever use unowned as opposed to a weak reference?
Why not just use weak? from my understanding it just has to do with failing loudly vs. failing silently. In the case of an unowned, the app will always crash if bone ends up without a dog, whereas if we use weak, you will end up with a bone that still exists, with a 'ghost' dog.
Strong & Weak references
So when A has a weak reference to B, then A is NOT the owner.
Example (where A is
Bone
and B isDog
)Strong Reference
Here a
Dog
can have aBone
. In that case it's the owner of that Bone. So thebone
property is a strong reference.Weak reference The
Bone
can belong to a Dog. But we need to declare thebelongsTo
property as weak, otherwise we have a strong retain cycle (which means ARC is not going to release these object once we are done with them).Unowned reference
Let's look at another example
Again, Person can own a CreditCard, so it has a the owner property which is a strong reference to
CreditCard
.Something like this
However a weak property must be declared as
Optional
so we use theunowned
which means: