Debugging the Responder Chain in Swift

Somewhat related to my previous post about responder chains, sometimes it is useful to be able to debug what all is in the responder chain at any given time. As a good rule of thumb, all ancestor views of a view are in that view’s responder chain, as well as (usually) the related controllers.

But this information is not always clear, so here’s a little class that will print the entire responder chain for any given object, starting with the current object and proceeding up the chain until it reaches the end.

class DebugHelper {
    static func printResponderChain(from responder: NSResponder?) {
        var responder = responder
        while let r = responder {
            print(r)
            responder = r.nextResponder
        }
    }
}

This is for macOS. For iOS, just change NSResponder to UIResponder.

You can call it like this from a view controller:

override func viewDidAppear() {
    DebugHelper.printResponderChain(from: self)
}

And it will output something like this:

<Example.FilesViewController: 0x600003500b00>
<_NSSplitViewItemViewWrapper: 0x600003b01340>
<NSSplitView: 0x6000033010e0>
<NSView: 0x6000033012c0>
<Example.MainSplitViewController: 0x600002c07900>
<NSView: 0x600003301040>
<NSView: 0x600003300fa0>
<Example.ViewController: 0x60000350c000>
<NSWindow: 0x600003e08200>
<Example.MainWindowController: 0x6000033108c0>

The above example was taken from a subclass of NSViewController. As you can see, there is more in the responder chain than you might have guessed. In addition to the view controllers, all the views as well as the windows and window controllers are also in the responder chain.

Did something I wrote help you out?

That's great! I don't earn any money from this site - I run no ads, sell no products and participate in no affiliate programs. I do this solely because it's fun; I enjoy writing and sharing what I learn.

All the same, if you found this article helpful and want to show your appreciation, here's my Amazon.com wishlist.

Read More

Hierarchies: Finding Parents, Children and Descendents using Swift

It usually doesn’t take beginning macOS/iOS developers long to discover NotificationCenter and see it as the solution to every single problem of passing data around to different controllers. And NotificationCenter is great, but it has some downsides. Notably, it is very easy to introduce retain cycles (and memory leaks) unless you are very careful to track and free the listener when the object is released. This has bitten me on several occasions. In general, excessive use of NotificationCenter ends up creating a difficult to maintain app where it is not entirely clear what is responding to what and where.

Creating Traits or Mixins in Swift

Object oriented programming is great, but sometimes things don’t fit neatly into a superclass/subclass hierarchy. You may have a piece of code that would be needed in several contexts, but for technical reasons beyond your control you cannot merge them into a single hierarchy. Some languages have the concept of multiple inheritence, where a subclass can specifically inherit from several parents. But this has it’s own set of problems. Many other languages, however, solve this through the use of traits or mixins. These allow us to have a set of methods that are basically copied into the object at compile time. This way they can be used anywhere they are needed. Swift doesn’t have the concept of mixins or traits per se. But, starting with Swift 3, you can get very equivalent functionality using protocol default implementations.