iOS: How To Make Weak Delegates In Swift

Posted on December 23rd, 2015

Here is a common scenario: You have a ViewController with multiple views and you want to delegate some action logic from the View to the ViewController.

For example, let’s say you have a view with a button in it (such as “Sign Up” button in a form), and when the user clicks that button, you want to delegate the logic (validation and API call) for that button to the ViewController to figure out where the user should go (or not) next.

Your code would look something like this:

// The protocol to delegate the
// button tap to the ViewController
protocol ButtonDelegate {
    func onButtonTap(sender: UIButton)
}

class ViewWithTextAndButton: UIView {
    
    // keeping track of the delegate to use later
    var delegate: ButtonDelegate?
    
    func onButtonTap(sender: UIButton) {
        // invoking the delegate when the
        // button is actually tapped
        delegate?.onButtonTap(sender)
    }
}

class MyViewController: UIViewController, ButtonDelegate {
    
    let viewWithTextAndButton = ViewWithTextAndButton(frame: CGRect(x: 0, y: 0, width: 100, height: 100))
    
    override func viewDidLoad() {
        super.viewDidLoad()
        
        // assigning the delegate
        viewWithTextAndButton.delegate = self
        view.addSubview(viewWithTextAndButton)
    }
    
    // MARK: ButtonDelegate
    // the delegated logic is here
    func onButtonTap(sender: UIButton) {
        print("This button was clicked in the subview!")
    }

}

// The protocol to delegate the

// button tap to the ViewController

protocol ButtonDelegate {

func onButtonTap(sender: UIButton)

}

class ViewWithTextAndButton: UIView {

// keeping track of the delegate to use later

var delegate: ButtonDelegate?

func onButtonTap(sender: UIButton) {

// invoking the delegate when the

// button is actually tapped

delegate?.onButtonTap(sender)

}

class MyViewController: UIViewController, ButtonDelegate {

let viewWithTextAndButton = ViewWithTextAndButton(frame: CGRect(x: 0, y: 0, width: 100, height: 100))

override func viewDidLoad() {

super.viewDidLoad()

// assigning the delegate

viewWithTextAndButton.delegate = self

view.addSubview(viewWithTextAndButton)

}

// MARK: ButtonDelegate

// the delegated logic is here

func onButtonTap(sender: UIButton) {

print("This button was clicked in the subview!")

}

But there is one BIG problem! Since the View is keeping a strong reference to the ViewController as the delegate and the ViewController is keeping a strong reference to the View, this creates a retain cycle. The ViewController references the View, and the View references the ViewController, ensuring that neither one will ever have the retain count of 0, so neither will be deallocated.

The solution is to make one of them hold on to the other weakly! So how do we do this in Swift? We have to constrain the protocol to only be used by Reference Types by adding the class keyword:

// This Protocol can now only be used by Classes!
protocol ButtonDelegate: class {
    func onButtonTap(sender: UIButton)
}

// This Protocol can now only be used by Classes!

protocol ButtonDelegate: class {

func onButtonTap(sender: UIButton)

}

Now, we can say that we want our delegate to be weakly retained:

class ViewWithTextAndButton: UIView {
    
    // Notice that we can now use the weak keyword!
    // this delegate now refers to a reference type only (UIViewController)
    // and that class will be weakly retained
    weak var delegate: ButtonDelegate?
    
    func onButtonTap(sender: UIButton) {
        delegate?.onButtonTap(sender)
    }
}

class ViewWithTextAndButton: UIView {

// Notice that we can now use the weak keyword!

// this delegate now refers to a reference type only (UIViewController)

// and that class will be weakly retained

weak var delegate: ButtonDelegate?

func onButtonTap(sender: UIButton) {

delegate?.onButtonTap(sender)

}

That’s it!

This is another great example as to why you should attempt to use value types when possible – to avoid this problem. With value types, values are copied, so not memory leaks like the one above can occur. But, of course, we have to work within the Cocoa framework, which includes a lot of subclassing (like that of UIView and UIViewController), so that’s when you need to use the constrained class protocols!

Jeremy Pereira

But with value types, you can’t have a cyclic object graph at all.
dasdom

Nice post. Thanks for this.

Just as a remark: This can be more elegantly solved using the responder chain. When you set up the target-action using nil as target, the runtime propagates up the responder chain until it finds an instance that implements the method.

I have put an example of this onto github: https://github.com/dasdom/ResponderChainDemo
Eduardo Irías

Good post, really helpful. I also use:

@objc protocol ButtonDelegate { }
or:
protocol ButtonDelegate : NSObjectProtocol { }

Do you know if there is any difference?

Thanks!
Mauricio Chirino

Huge thanks, those memory leaks were driving me crazy and one of my app’s is already in production. Thanks to this post, this will be one of my next updates.
Echo Guo

But can i have a weak protocol that does NOT depend on the type? A protocol by its self does not care what object is conforming to itself. So both a class, or a struct can conform to it. Is it possible to still have the benefit of both being able to conform to it, but only have the class types that conform be weak?
preslavrachev

The argument is relevant. Keeping weak references to components managed by the runtime is always a good idea. Though, from an architectural design point of view, should one assume that its delegate is always a view controller? Not necessarily. The point of delegation is to abstract the implementation details by providing only a protocol contract. Just keep it mind.