How iOS Touch Events Are Generated, Propagated, and Handled

When an iOS touch occurs, the system creates a UITouch object that records the time, phase, tap count, window, and view of the touch, and then packages one or more UITouch objects into a UIEvent object.

The UIEvent object stores the event type, timestamp, and the set of all touches. The event is placed into the event queue managed by UIApplication , which dequeues it and begins delivering it down the view hierarchy.

Event originates from touch: UITouch

@interface UITouch : NSObject
@property (nonatomic, readonly) NSTimeInterval timestamp;
@property (nonatomic, readonly) UITouchPhase phase;
@property (nonatomic, readonly) NSUInteger tapCount;
@property (nullable, nonatomic, readonly, strong) UIWindow *window;
@property (nullable, nonatomic, readonly, strong) UIView *view;
@end

Event itself: UIEvent

@interface UIEvent : NSObject
@property (nonatomic, readonly) UIEventType type API_AVAILABLE(ios(3.0));
@property (nonatomic, readonly) NSTimeInterval timestamp;
@property (nonatomic, readonly, nullable) NSSet<UITouch *> *allTouches;
@end

All UIResponder subclasses (including UIView , UIViewController , and UIApplication ) can receive and handle events. The key UIResponder methods for touch handling are:

- (void)touchesBegan:(NSSet<UITouch *>)touches withEvent:(nullable UIEvent *)event; // touch start
- (void)touchesMoved:(NSSet<UITouch *>)touches withEvent:(nullable UIEvent *)event; // touch move
- (void)touchesEnded:(NSSet<UITouch *>)touches withEvent:(nullable UIEvent *)event; // touch end
- (void)touchesCancelled:(NSSet<UITouch *>)touches withEvent:(nullable UIEvent *)event; // touch cancelled

The system calls these methods on the view that is determined to be the best responder. Determining that view involves the hitTest:withEvent: and pointInside:withEvent: methods of UIView :

- (nullable UIView *)hitTest:(CGPoint)point withEvent:(nullable UIEvent *)event;
- (BOOL)pointInside:(CGPoint)point withEvent:(nullable UIEvent *)event;

hitTest: first asks the view whether the touch point lies inside it via pointInside: . If YES, it recursively asks the view’s subviews (starting from the frontmost) to find a deeper view that also returns YES. The deepest view that returns YES becomes the “best responder”. If pointInside: returns NO, or the view is non‑interactive, hidden, or fully transparent (alpha < 0.01), hitTest: returns nil.

When hitTest: returns a view, that view receives the touch events through the UIResponder methods. If the view does not handle the event, it forwards the event to its nextResponder , which is typically its superview, then possibly the view controller, the window, and finally the application. If none of the responders handle the event, it is discarded.

The responder chain can be altered by overriding the touch methods and optionally calling super to continue propagation.

Summary

After a touch occurs, the event is queued by UIApplication , delivered down the view hierarchy via hitTest and pointInside , and processed by the best‑responding UIView (or its super‑responders) using the UIResponder touch methods. The chain continues upward until the event is handled or ultimately discarded.