We've been using padding for that. I feel like while that attribute is useful, it's dangerous to be able to increase hit range like this as you're likely going to overlap with other elements and have an undefined behavior

Hit slop is especially useful when you Have completed your layout and just need to adjust the tappable areas. Comfortable hit-test areas are one of those features that makes apps feel "native" and it would be good if they were easy to customize. Sometimes the tappable region may overlap with other views, which is unambiguous when those views don't handle touches. When touchable areas do overlap I believe the behavior can be well-defined (e.g. use z-index and responder chain) and the programmer can later fine-tune the hit area. There may be another good way to resolve tap conflicts / UIKit might have a clever approach.

Right now, we've made the conscious choice not to introduce apis that cannot be polyfilled on the web. Unfortunately it's basically impossible to polyfill this without having to reimplement hit testing.

At some point in the future we'll want to reimplement hit testing on web, layout, ... but until then, I feel like it's best to have a slightly worse api but that's backward compatible.

OK. I will think about it some more to see if there is a solution that can be built in user space, either with pure JS or a native module that swizzles native hit-testing methods. I do think it is useful to adjust hit-test areas easily even when you can't run the same code everywhere.

@ide - did you ever look into this?

Last I looked at the touch handler the easiest way would be to override the hit testing of views. I haven't experimented with this, just have been making my views bigger to compensate for now.

I'm going to close this out - if you come up with an elegant solution, put up a PR?

Reopening this since we're actively working on a hit-test slop API that works across iOS and Android, with iOS's hit-test semantics. Specifically, if there are two overlapping hit boxes, they are treated the exact same way as if you had two overlapping views -- the one that comes last in the view hierarchy receives the touch.

To get this same behavior on Android requires some extra work since the de facto way to adjust hit areas on Android ends up sending touch events to all views with overlapping hit boxes. It's confusing and inconsistent with how overlapping views function (where the hit box size == view size) so we're working towards fixing this for RN Android so no one else has to. We're still a little bit away from sending a PR (need to do Android) but plan to when we have something working well.