Introduction

hitTest:withEvent: and pointInside:withEvent: are part of the same touch-routing process, but they do different jobs. pointInside answers a simple yes-or-no question about whether a touch point is inside a view's interactive area. hitTest uses that information while walking the view hierarchy to decide which view should actually receive the event.

The Basic Relationship

When a touch arrives, UIKit starts high in the view tree and asks views whether the touch could belong to them. A view that is hidden, nearly transparent, or not interactive is usually ignored immediately.

At a conceptual level, the flow looks like this:

1. UIKit calls hitTest:withEvent: on a parent view.
2. That method checks whether the view is eligible to receive touches.
3. As part of that process, it calls pointInside:withEvent: on the same view.
4. If the point is outside, the view returns nil.
5. If the point is inside, hitTest continues by asking subviews, usually from frontmost to backmost.

That is why pointInside is best thought of as a filter and hitTest as the chooser.

A Modern Swift Example

The current Swift method names are point(inside:with:) and hitTest(_:with:), but they map directly to the older Objective-C names in the article title.

1import UIKit
2
3final class EnlargedButton: UIButton {
4    override func point(inside point: CGPoint, with event: UIEvent?) -> Bool {
5        let largerArea = bounds.insetBy(dx: -20, dy: -20)
6        return largerArea.contains(point)
7    }
8}

Here, you override point(inside:with:) to make the tappable area larger without changing the button's visible frame. You do not need to override hitTest for that use case because the default hit-testing logic will use your new inside-area rule automatically.

When to Override hitTest

Override hitTest when you want to reroute or customize which subview wins the event, not just whether a point counts as inside the current view.

1import UIKit
2
3final class PassthroughOverlayView: UIView {
4    override func hitTest(_ point: CGPoint, with event: UIEvent?) -> UIView? {
5        let candidate = super.hitTest(point, with: event)
6        return candidate === self ? nil : candidate
7    }
8}

This pattern creates an overlay that lets touches pass through empty parts of the overlay while still allowing interactive subviews to receive touches.

How the Two Methods Work Together

The default implementation of hitTest typically checks the current view first, then converts the touch point into each subview's coordinate system and asks those subviews in reverse order. Reverse order matters because frontmost views should usually win the hit test.

If pointInside returns false, the view is not a candidate and its subviews are not considered through that branch. That is why a custom pointInside implementation can dramatically change touch behavior even when you never override hitTest directly.

Common Pitfalls

The most common mistake is overriding hitTest when pointInside would have been enough. If all you need is a larger or smaller touch area, changing the inside check is simpler and safer.

Another mistake is forgetting coordinate systems. The point passed into each method is already expressed in that view's local coordinates, so you should not compare it to another view's frame without conversion.

Be careful when returning nil from hitTest. That can make controls feel untappable if you accidentally discard a legitimate target view.

Finally, remember that gesture recognizers and control events sit on top of hit testing. If the wrong view wins the hit test, everything built on top of it becomes harder to reason about.

Summary

• 'pointInside:withEvent: answers whether a touch point belongs inside a view's touchable region.'
• 'hitTest:withEvent: uses that answer while selecting the final target view.'
• Override pointInside to change touch area size.
• Override hitTest only when you need to reroute event delivery.
• Keep coordinate systems and view ordering in mind when debugging touch behavior.