Article

Understanding Event Handling, Responders, and the Responder Chain

Learn how events are propagated through your app and how you handle them.

Overview

Apps receive and handle events using responder objects. A responder object is any instance of the UIResponder class, and common subclasses include UIView, UIViewController, and UIApplication. Responders receive the raw event data and must either handle the event or forward it to another responder object. When your app receives an event, UIKit automatically directs that event to the most appropriate responder object, known as the first responder. Unhandled events are passed from responder to responder in the active responder chain, which is a dynamic configuration of your app’s responder objects. There is no single responder chain within your app. UIKit defines default rules for how objects are passed from one responder to the next, but you can always change those rules by overriding the appropriate properties in your responder objects.Figure 1 shows the default responder chains in an app whose interface contains a label, a text field, a button, and two background views. If the text field does not handle an event, UIKit sends the event to the text field’s parent UIView object, followed by the root view of the window. From the root view, the responder chain diverts to the owning view controller before directing the event to the window. If the window does not handle the event, UIKit delivers the event to the UIApplication object, and possibly to the app delegate if that object is an instance of UIResponder and not already part of the responder chain.

Figure 1

Responder chains in an app

A flow diagram that shows how an event moves along the responder chain

Determining the First Responder for an Event

For every type of event, UIKit designates a first responder and sends the event to that object first. The first responder varies based on the type of event.

Touch events

The first responder is the view in which the touch occurred.

Press events

The first responder is the responder that has focus.

Shake-motion events

The first responder is the object that you (or UIKit) designate as the first responder.

Remote-control events

The first responder is the object that you (or UIKit) designate as the first responder.

Editing menu messages

The first responder is the object that you (or UIKit) designate as the first responder.

Controls communicate directly with their associated target object using action messages. When the user interacts with a control, the control calls the action method of its target object—in other words, it sends an action message to its target object. Action messages are not events, but they may still take advantage of the responder chain. When the target object of a control is nil, UIKit starts from the target object and walks the responder chain until it finds an object that implements the appropriate action method. For example, the UIKit editing menu uses this behavior to search for responder objects that implement methods with names like cut(_:), copy(_:), or paste(_:).

If a view has an attached gesture recognizer, the gesture recognizer receives touch and press events before the view receives them. If all of the view’s gesture recognizers fail to recognize their gestures, the events are passed to the view for handling. If the view does not handle them, UIKit passes the events up the responder chain. For more information about using gesture recognizer’s to handle events, see Handling UIKit Gestures.

Determining Which Responder Contained a Touch Event

UIKit uses view-based hit-testing to determine where touch events occur. Specifically, UIKit compares the touch location to the bounds of view objects in the view hierarchy. The hitTest(_:with:) method of UIView walks the view hierarchy, looking for the deepest subview that contains the specified touch. That view becomes the first responder for the touch event.

UIKit permanently assigns each touch to the view that contains it. UIKit creates each UITouch object when the touch first occurs, and it releases that touch object only after the touch ends. As the touch location or other parameters change, UIKit updates the UITouch object with the new information. The only property that does not change is the containing view. Even when the touch location moves outside the original view, the value in the touch’s view property does not change.

Altering the Responder Chain

You can alter the responder chain by overriding the next property of your responder objects. When you do this, the next responder is the object that you return.

Many UIKit classes already override this property and return specific objects.

  • UIView objects. If the view is the root view of a view controller, the next responder is the view controller; otherwise, the next responder is the view’s superview.

  • UIViewController objects.

    • If the view controller’s view is the root view of a window, the next responder is the window object.

    • If the view controller was presented by another view controller, the next responder is the presenting view controller.

  • UIWindow objects. The window's next responder is the UIApplication object.

  • UIApplication object. The next responder is the app delegate, but only if the app delegate is an instance of UIResponder and is not a view, view controller, or the app object itself.

See Also

User Interactions

Touches, Presses, and Gestures

Encapsulate your app's event-handling logic in gesture recognizers so that you can reuse that code throughout your app.

Drag and Drop

Bring drag and drop to your app by using interaction APIs with your views.

Peek and Pop

Use 3D Touch input to display custom previews and actions for your content.

Keyboard and Menus

Handle keyboard input, and display a menu of custom actions.