What means [unowned self] and what are the benefits?

Question

I´m trying to integrate Face/Touch ID Login but i saw in apples documentation [unowned self] in a closure. What is that and what are the benefits? Example code:

let context = LAContext()
    var error: NSError?

    if context.canEvaluatePolicy(.deviceOwnerAuthenticationWithBiometrics, error: &error) {
        let reason = "Identify yourself!"

        context.evaluatePolicy(.deviceOwnerAuthenticationWithBiometrics, localizedReason: reason) {
            [unowned self] (success, authenticationError) in

            DispatchQueue.main.async {
                if success {
                    print("Authenticated!")
                } else {
                    // error
                }
            }
        }
    } else {
        // no biometry
    }

Answer 1

Long story short, it's the same as weak! , since unowned references are just weak references that are guaranteed to have a value.

unowned is used when you're sure that the reference will NEVER be nil, and therefore, it can only be evaluated with non nil values.

Like weak references, an unowned reference does not keep a strong hold on the instance it refers to. Unlike a weak reference, however, an unowned reference is assumed to always have a value. Because of this, an unowned reference is always defined as a non-optional type. (Apple Docs)

Check this other answer: What is the difference between a weak reference and an unowned reference?

Docs: ARC Documentation

Answer 2

The unowned qualifier, like weak , prevents the closure from establishing a strong reference to to self which can be helpful in preventing strong reference cycles. The benefit of unowned over weak is that it's a tad more efficient in optimized builds, not requiring it to keep track of this reference and go back and set it to nil when the object to which it references is deallocated. The unowned reference also is not an optional, meaning that you don't have to unwrap it, eliminating syntactic noise and simplifying one's code.

But you obviously can't use unowned in any situation where the object might be deallocated, because it obviously can no longer keep a reference to the memory for a deallocated object.

Interestingly, the evaluatePolicy(_:localizedReason:reply:) documentation says, “This method asynchronously evaluates an authentication policy.” Any time you're dealing with an asynchronous method, it is not advisable to use unowned , because you cannot be assured that the object in question hasn't been deallocated in the intervening time. Only use unowned in those specific situations where you know, for a fact, that the closure cannot be called if the object has been deallocated. That would not appear to be the case here.

Bottom line, use unowned to avoid strong reference cycles and where you want cleaner, slightly more efficient code. But only do so when you know that it is impossible for the object to be deallocated before closure is called.