Thanks for the input. Curiously enough, I came to the same conclusion a few minutes before I got notice of your reply. I’m creating an [FONT=Courier New]FAdvancedGestureRecognizer class that will get ticked from a [FONT=Courier New]UPlayerInput subclass used by our player controller. I’m currently working on defining an interface for gesture delegates now. Unfortunately, Unreal doesn’t make it easy to create a C++ interface, so I’m fighting the build system a bit. “Add Code to Project” doesn’t have an option for subclassing [FONT=Courier New]UInterfaces. I created one manually based on Rama’s Wiki page entry, but the Create Xcode Project service isn’t creating a [FONT=Courier New].generated.h file for it, which the build system is saying it has to have. 
To some extent, I want to model this after the iOS [FONT=Courier New]UIGestureRecognizer, but there are some challenges involved in doing that. In a regular non-game app, it’s okay to wait to see if you’ve gotten a double-tap before firing off the single-tap delegate call. In a game, that half-second or second delay will generally not be acceptable. However, if you support double-taps, you probably don’t want a double-tap to fire both a single- and double-tap delegate call. We generally use “touch down” for most of our stuff for responsiveness, but we can’t exactly call back a bullet after it’s been fired. That means gestures are going to be a challenge.
Yeah, that would offer some nice flexibility to let people define their own delegates. I’d like to structure it that way, but not sure I can justify the time, since our game doesn’t need that level of flexibility.