You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.
Create Plan
🧪 Issue enrichment is currently in open beta.
To disable automatic issue enrichment, add the following to your .coderabbit.yaml:
issue_enrichment:
auto_enrich:
enabled: false
💬 Have feedback or questions? Drop into our discord!
The macOS build breaks because UIGestureRecognizer and UIGestureRecognizerDelegate are UIKit-only symbols. They are undeclared on macOS. The code uses them without guards in RNGestureHandler.h, RNGestureHandler.mm, and RNGestureHandlerManager.mm.
Add a platform-conditional recognizer type alias and delegate protocol alias in RNGHUIKit.h. This mirrors the existing typedef pattern in the file.
Replace the bare recognizer references with the aliases. Route bare recognizer state constants through the existing state macros.
Verify the fix by building the macOS example and an iOS example. This confirms the fix and prevents regressions.
Design ChoicesDesign Choice 1: How should the code bridge the recognizer class type across iOS and macOS?
Options Considered:
Add one platform-conditional typedef (and protocol alias) in RNGHUIKit.h, then replace bare usages with the alias.
Wrap each affected declaration and method in #if !TARGET_OS_OSX / #else blocks with duplicated signatures.
Chosen Option: 1
Rationale: The header already guards one method pair (isUIScrollViewPanGestureRecognizer:) with dual signatures, but most declarations use the bare class. A single decision is needed for the whole codebase. A single alias mirrors the existing RNGHUIView/RNGHWindow typedef pattern, keeps changes small and consistent, and avoids duplicating dozens of method signatures.
💡 User Tips
Regenerate the plan with different choices with @coderabbitai <feedback>.
Implementation Steps
Phase 1: Add a platform-neutral recognizer abstraction
This phase extends the existing abstraction layer so that the recognizer class and its delegate protocol have macOS-safe aliases. This makes downstream fixes small and consistent with the current pattern.
Add recognizer type and delegate aliases to RNGHUIKit.h
Extend the central abstraction header so consumers never reference the raw UIKit recognizer symbols.
Update apple/RNGHUIKit.h.
In the #if !TARGET_OS_OSX branch, add a typedef that maps a new name (for example RNGHGestureRecognizer) to UIGestureRecognizer.
In the #else (macOS) branch, map the same name to NSGestureRecognizer.
Add a matching alias for the delegate protocol name (for example RNGHGestureRecognizerDelegate): map it to UIGestureRecognizerDelegate on iOS and NSGestureRecognizerDelegate on macOS.
Keep the alias names consistent with the existing RNGH* naming convention.
Do not remove or rename the existing RNGHGestureRecognizerState* macros.
🤖 Prompt for AI agents
Goal: extend `apple/RNGHUIKit.h` with a platform-neutral recognizer type and
delegate protocol abstraction, so downstream files never reference raw
UIKit-only recognizer symbols.
- In the `#if !TARGET_OS_OSX` branch of `apple/RNGHUIKit.h`, add a typedef named
`RNGHGestureRecognizer` that maps to `UIGestureRecognizer`.
- In the `#else` (macOS) branch, map `RNGHGestureRecognizer` to
`NSGestureRecognizer`.
- Add a matching protocol alias named `RNGHGestureRecognizerDelegate`: map it to
`UIGestureRecognizerDelegate` on iOS, and to `NSGestureRecognizerDelegate` on
macOS.
- Keep the new alias names consistent with the existing `RNGH*` naming
convention used for `RNGHUIView`, `RNGHWindow`, `RNGHScrollView`, `RNGHUITouch`,
`RNGHUIScrollView`, `RNGHColor`.
- Do not remove or rename the existing `RNGHGestureRecognizerState*` macros.
Phase 2: Apply the abstraction to the unguarded Apple sources
This phase replaces every unguarded UIKit-only recognizer reference with the new aliases and routes bare recognizer state constants through the existing macros. This removes the macOS compile break.
Task 1: Update RNGestureHandler.h
Replace bare recognizer type and delegate references in the public header.
Update apple/RNGestureHandler.h.
Replace the protocol conformance <UIGestureRecognizerDelegate> on both the RNRootViewGestureRecognizerDelegate protocol and the RNGestureHandler interface with the new delegate alias.
Replace the _recognizer ivar type, the recognizer property type, and the parameter/return types in findGestureHandlerByRecognizer:, chooseViewForInteraction:, and the gestureRecognizer:didActivateInViewWithTouchHandler: declaration with the new recognizer alias.
Replace the subject of the UIGestureRecognizer (GestureHandler) category with the new recognizer alias.
Keep the already-guarded isUIScrollViewPanGestureRecognizer: and pointer-type method pairs unchanged, or convert them to the alias if it simplifies the guards without changing behavior.
Task 2: Update RNGestureHandler.mm
Replace bare recognizer types, delegate implementations, and bare state constants in the implementation.
Update apple/RNGestureHandler.mm.
Replace the UIGestureRecognizer (GestureHandler) category implementation subject with the new recognizer alias.
Replace bare UIGestureRecognizer * parameter and local variable types in eventExtraData:, chooseViewForInteraction:, all handleGesture:... variants, eventTagForRecognizer:, findGestureHandlerByRecognizer:, the delegate methods (shouldBeRequiredToFailByGestureRecognizer:, shouldRequireFailureOfGestureRecognizer:, shouldRecognizeSimultaneouslyWithGestureRecognizer:, gestureRecognizerShouldBegin:, gestureRecognizer:shouldReceiveTouch:), and areScrollViewRecognizersCompatible:otherRecognizer: with the new recognizer alias.
Replace bare UIGestureRecognizerState* enum references with the existing RNGHGestureRecognizerState* macros so they resolve on both platforms.
Keep the existing #if !TARGET_OS_OSX import block for UIGestureRecognizerSubclass.h and UIPanGestureRecognizer.h unchanged.
If a delegate method body calls a UIKit-only API that has no macOS counterpart, keep or add a #if TARGET_OS_OSX branch for that body, consistent with the current style.
Task 3: Update RNGestureHandlerManager.mm
Replace the file's own bare recognizer usages.
Update apple/RNGestureHandlerManager.mm.
Replace the bare UIGestureRecognizer * usages in registerViewWithGestureRecognizerAttachedIfNeeded: and in gestureRecognizer:didActivateInViewWithTouchHandler: (method signature and local variables) with the new recognizer alias.
Leave the existing #if !TARGET_OS_OSX blocks in this file unchanged.
🤖 Prompt for AI agents
Goal: remove all unguarded UIKit-only recognizer references in
`apple/RNGestureHandler.h`, `apple/RNGestureHandler.mm`, and
`apple/RNGestureHandlerManager.mm` by substituting the `RNGHGestureRecognizer`
and `RNGHGestureRecognizerDelegate` aliases from Phase 1, and by routing bare
state constants through the existing `RNGHGestureRecognizerState*` macros.
In `apple/RNGestureHandler.h`:
- Replace the `<UIGestureRecognizerDelegate>` conformance on the
`RNRootViewGestureRecognizerDelegate` protocol and on the `RNGestureHandler`
interface with `RNGHGestureRecognizerDelegate`.
- Replace the `_recognizer` ivar type and the `recognizer` property type with
`RNGHGestureRecognizer`.
- Replace the parameter and return types in `findGestureHandlerByRecognizer:`,
`chooseViewForInteraction:`, and
`gestureRecognizer:didActivateInViewWithTouchHandler:` with
`RNGHGestureRecognizer`.
- Replace the subject of the `UIGestureRecognizer (GestureHandler)` category
with `RNGHGestureRecognizer`.
- Keep the already-guarded `isUIScrollViewPanGestureRecognizer:` and
pointer-type method pairs unchanged, or convert them to the alias only if it
simplifies the guards without changing behavior.
In `apple/RNGestureHandler.mm`:
- Replace the `UIGestureRecognizer (GestureHandler)` category implementation
subject with `RNGHGestureRecognizer`.
- Replace bare `UIGestureRecognizer *` parameter and local variable types with
`RNGHGestureRecognizer *` in: `eventExtraData:`, `chooseViewForInteraction:`,
all `handleGesture:...` variants, `eventTagForRecognizer:`,
`findGestureHandlerByRecognizer:`, the delegate methods
`shouldBeRequiredToFailByGestureRecognizer:`,
`shouldRequireFailureOfGestureRecognizer:`,
`shouldRecognizeSimultaneouslyWithGestureRecognizer:`,
`gestureRecognizerShouldBegin:`, `gestureRecognizer:shouldReceiveTouch:`, and
`areScrollViewRecognizersCompatible:otherRecognizer:`.
- Replace bare `UIGestureRecognizerState*` enum references with the existing
`RNGHGestureRecognizerState*` macros.
- Keep the existing `#if !TARGET_OS_OSX` import block for
`UIGestureRecognizerSubclass.h` and `UIPanGestureRecognizer.h` unchanged.
- If a delegate method body calls a UIKit-only API with no macOS counterpart,
keep or add a `#if TARGET_OS_OSX` branch for that body, matching the current
file style.
In `apple/RNGestureHandlerManager.mm`:
- Replace bare `UIGestureRecognizer *` usages with `RNGHGestureRecognizer *` in
`registerViewWithGestureRecognizerAttachedIfNeeded:` and in the
`gestureRecognizer:didActivateInViewWithTouchHandler:` method signature and
local variables.
- Leave the existing `#if !TARGET_OS_OSX` blocks in this file unchanged.
Do not change `RNGestureHandlerPointerTracker.mm`,
`RNGestureHandlerEvents.mm`/`.h`, the podspec, `gesture_handler_utils.rb`, the
worklets/reanimated versions, or the legacy `RNGestureHandler.xcodeproj`.
Phase 3: Verify the macOS build
This phase confirms the fix resolves the compile break and does not regress iOS or tvOS.
Build the macOS example and validate other Apple targets
Confirm the pod compiles for macOS and remains correct for iOS/tvOS.
Build apps/macos-example (New Architecture and Fabric are forced on) and confirm the RNGestureHandler pod compiles.
Confirm no remaining bare UIGestureRecognizer or UIGestureRecognizerDelegate symbols exist outside #if !TARGET_OS_OSX guards in the changed files (RNGestureHandlerPointerTracker.mm and RNGestureHandlerEvents.* are already clean and need no change).
Build an iOS example to confirm the alias substitution did not change iOS behavior.
🤖 Prompt for AI agents
Goal: verify that the alias substitution fixes the macOS compile break and does
not regress iOS or tvOS builds.
- Build `apps/macos-example` (New Architecture and Fabric are forced on) and
confirm the `RNGestureHandler` pod compiles.
- Confirm that no bare `UIGestureRecognizer` or `UIGestureRecognizerDelegate`
symbols remain outside `#if !TARGET_OS_OSX` guards in the changed files. Note
that `RNGestureHandlerPointerTracker.mm` and `RNGestureHandlerEvents.*` are
already clean and need no change.
- Build an iOS example to confirm the alias substitution did not change iOS
behavior.
Research
The library is at packages/react-native-gesture-handler. The Apple native code is in apple/. The podspec compiles every file under apple/** for all Apple platforms, including macOS (osx: '14.0'), with no per-platform exclusion.
The header apple/RNGHUIKit.h is the central platform abstraction. It defines cross-platform typedefs (RNGHUIView, RNGHWindow, RNGHScrollView, RNGHUITouch, RNGHUIScrollView, RNGHColor) and gesture-recognizer state macros (RNGHGestureRecognizerState*) using #if !TARGET_OS_OSX / #else. On macOS, UIKit is not imported; only <React/RCTUIKit.h> is. Any bare UIKit-only symbol therefore fails to compile on macOS.
RNGHUIKit.h has no alias for the recognizer class itself, and RNGestureHandler.h, RNGestureHandler.mm, and RNGestureHandlerManager.mm use the bare UIGestureRecognizer class and UIGestureRecognizerDelegate protocol without guards.
🚀 Next Steps
🤖 All AI agent prompts combined
Task: 1
Goal: extend `apple/RNGHUIKit.h` with a platform-neutral recognizer type and
delegate protocol abstraction, so downstream files never reference raw
UIKit-only recognizer symbols.
- In the `#if !TARGET_OS_OSX` branch of `apple/RNGHUIKit.h`, add a typedef named
`RNGHGestureRecognizer` that maps to `UIGestureRecognizer`.
- In the `#else` (macOS) branch, map `RNGHGestureRecognizer` to
`NSGestureRecognizer`.
- Add a matching protocol alias named `RNGHGestureRecognizerDelegate`: map it to
`UIGestureRecognizerDelegate` on iOS, and to `NSGestureRecognizerDelegate` on
macOS.
- Keep the new alias names consistent with the existing `RNGH*` naming
convention used for `RNGHUIView`, `RNGHWindow`, `RNGHScrollView`, `RNGHUITouch`,
`RNGHUIScrollView`, `RNGHColor`.
- Do not remove or rename the existing `RNGHGestureRecognizerState*` macros.
===============================================================================
Task: 2
Goal: remove all unguarded UIKit-only recognizer references in
`apple/RNGestureHandler.h`, `apple/RNGestureHandler.mm`, and
`apple/RNGestureHandlerManager.mm` by substituting the `RNGHGestureRecognizer`
and `RNGHGestureRecognizerDelegate` aliases from Phase 1, and by routing bare
state constants through the existing `RNGHGestureRecognizerState*` macros.
In `apple/RNGestureHandler.h`:
- Replace the `<UIGestureRecognizerDelegate>` conformance on the
`RNRootViewGestureRecognizerDelegate` protocol and on the `RNGestureHandler`
interface with `RNGHGestureRecognizerDelegate`.
- Replace the `_recognizer` ivar type and the `recognizer` property type with
`RNGHGestureRecognizer`.
- Replace the parameter and return types in `findGestureHandlerByRecognizer:`,
`chooseViewForInteraction:`, and
`gestureRecognizer:didActivateInViewWithTouchHandler:` with
`RNGHGestureRecognizer`.
- Replace the subject of the `UIGestureRecognizer (GestureHandler)` category
with `RNGHGestureRecognizer`.
- Keep the already-guarded `isUIScrollViewPanGestureRecognizer:` and
pointer-type method pairs unchanged, or convert them to the alias only if it
simplifies the guards without changing behavior.
In `apple/RNGestureHandler.mm`:
- Replace the `UIGestureRecognizer (GestureHandler)` category implementation
subject with `RNGHGestureRecognizer`.
- Replace bare `UIGestureRecognizer *` parameter and local variable types with
`RNGHGestureRecognizer *` in: `eventExtraData:`, `chooseViewForInteraction:`,
all `handleGesture:...` variants, `eventTagForRecognizer:`,
`findGestureHandlerByRecognizer:`, the delegate methods
`shouldBeRequiredToFailByGestureRecognizer:`,
`shouldRequireFailureOfGestureRecognizer:`,
`shouldRecognizeSimultaneouslyWithGestureRecognizer:`,
`gestureRecognizerShouldBegin:`, `gestureRecognizer:shouldReceiveTouch:`, and
`areScrollViewRecognizersCompatible:otherRecognizer:`.
- Replace bare `UIGestureRecognizerState*` enum references with the existing
`RNGHGestureRecognizerState*` macros.
- Keep the existing `#if !TARGET_OS_OSX` import block for
`UIGestureRecognizerSubclass.h` and `UIPanGestureRecognizer.h` unchanged.
- If a delegate method body calls a UIKit-only API with no macOS counterpart,
keep or add a `#if TARGET_OS_OSX` branch for that body, matching the current
file style.
In `apple/RNGestureHandlerManager.mm`:
- Replace bare `UIGestureRecognizer *` usages with `RNGHGestureRecognizer *` in
`registerViewWithGestureRecognizerAttachedIfNeeded:` and in the
`gestureRecognizer:didActivateInViewWithTouchHandler:` method signature and
local variables.
- Leave the existing `#if !TARGET_OS_OSX` blocks in this file unchanged.
Do not change `RNGestureHandlerPointerTracker.mm`,
`RNGestureHandlerEvents.mm`/`.h`, the podspec, `gesture_handler_utils.rb`, the
worklets/reanimated versions, or the legacy `RNGestureHandler.xcodeproj`.
===============================================================================
Task: 3
Goal: verify that the alias substitution fixes the macOS compile break and does
not regress iOS or tvOS builds.
- Build `apps/macos-example` (New Architecture and Fabric are forced on) and
confirm the `RNGestureHandler` pod compiles.
- Confirm that no bare `UIGestureRecognizer` or `UIGestureRecognizerDelegate`
symbols remain outside `#if !TARGET_OS_OSX` guards in the changed files. Note
that `RNGestureHandlerPointerTracker.mm` and `RNGestureHandlerEvents.*` are
already clean and need no change.
- Build an iOS example to confirm the alias substitution did not change iOS
behavior.
💡 Iterate on the plan with:
`@coderabbitai` <feedback>
Example Feedback
- `@coderabbitai` You can skip phase 3. Add a simple unit test case for phase 2.
- `@coderabbitai` For design choice 1 go ahead with option 3 and replan.
💬 Have feedback or questions? Drop into our discord!
@m-bert, the label is present on #4447. The issue has both Missing repro and Missing Repro v2.
The reproduction-missing comment is also present. github-actions[bot] posted it at 2026-08-19 08:00:38 UTC:
The issue doesn't seem to contain a minimal reproduction.
That comment came from the repository GitHub Actions workflow. It did not come from CodeRabbit. CodeRabbit posted the issue-enrichment and plan comments.
I cannot determine from the issue metadata why both missing-reproduction labels exist. They likely come from separate labeling automation.
🐇⬛
🧠 Learnings used
Learnt from: m-bert
Repo: software-mansion/react-native-gesture-handler PR: 0
File: :0-0
Timestamp: 2026-08-19T07:43:11.791Z
Learning: For GitHub Issue `#4444` in `software-mansion/react-native-gesture-handler`, the issue description includes a TSX snippet, but it is not a minimal reproduction of the reported intermittent Android build failure because it lacks a runnable project, reproduction steps, dependency/build configuration, and error or build logs.
@m-bert, I removed the Missing Repro v2 label from #4447.
The remaining labels are Missing repro, Platform: MacOS, and Maintainer issue.
🧠 Learnings used
Learnt from: m-bert
Repo: software-mansion/react-native-gesture-handler PR: 0
File: :0-0
Timestamp: 2026-08-19T07:43:11.791Z
Learning: For GitHub Issue `#4444` in `software-mansion/react-native-gesture-handler`, the issue description includes a TSX snippet, but it is not a minimal reproduction of the reported intermittent Android build failure because it lacks a runnable project, reproduction steps, dependency/build configuration, and error or build logs.
@m-bert, your request can change labels because you are a repository administrator.
A maintainer should request label removal directly.
If a non-maintainer provides a reproduction and pings me, I should first review the reproduction. If it is sufficient, I can report that Missing repro is no longer applicable. A maintainer should then confirm or request the label removal.
A ping and a reproduction do not by themselves grant label-management authority to a non-maintainer.
For #4447, Missing repro is still present.
🧠 Learnings used
Learnt from: m-bert
Repo: software-mansion/react-native-gesture-handler PR: 0
File: :0-0
Timestamp: 2026-08-19T07:43:11.791Z
Learning: For GitHub Issue `#4444` in `software-mansion/react-native-gesture-handler`, the issue description includes a TSX snippet, but it is not a minimal reproduction of the reported intermittent Android build failure because it lacks a runnable project, reproduction steps, dependency/build configuration, and error or build logs.
@m-bert, if the reproduction is sufficient, I should post a comment that states the Missing repro label is no longer applicable and ping the repository maintainers for confirmation or removal.
I should not wait silently for maintainer action.
I should leave the label unchanged until a maintainer confirms the removal or requests it directly.
🐇
✏️ Learnings added
Learnt from: m-bert
URL: https://github.com/software-mansion/react-native-gesture-handler/issues/4447
Timestamp: 2026-08-19T08:57:50.921Z
Learning: For `software-mansion/react-native-gesture-handler`, when a non-maintainer provides a sufficient reproduction for an issue labeled `Missing repro`, CodeRabbit should comment that the label is no longer applicable and ping repository maintainers. CodeRabbit should not silently wait. The label remains until a maintainer confirms or directly requests its removal.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
🧠 Learnings used
Learnt from: m-bert
Repo: software-mansion/react-native-gesture-handler PR: 0
File: :0-0
Timestamp: 2026-08-19T07:43:11.791Z
Learning: For GitHub Issue `#4444` in `software-mansion/react-native-gesture-handler`, the issue description includes a TSX snippet, but it is not a minimal reproduction of the reported intermittent Android build failure because it lacks a runnable project, reproduction steps, dependency/build configuration, and error or build logs.
Activity
github-actions commentedon Aug 19, 2026
Hey! 👋
The issue doesn't seem to contain a minimal reproduction.
Could you provide a snack or a link to a GitHub repository under your username that reproduces the problem?
coderabbitai commentedon Aug 19, 2026
🔗 Related PRs
#4310 - Bump to React Native 0.87 [merged]
#4389 - [macOS] Fix
manualActivationnever blocking gesture activation [merged]#4410 - [macOS] Downgrade
react-native-worklets[merged]#4422 - Remove
REACT_NATIVE_MINOR_VERSIONbuild flag [merged]📝 Issue Planner
Check the box below or use the
@coderabbitai plancommand to generate an implementation plan and prompts that you can use with your favorite coding assistant.🧪 Issue enrichment is currently in open beta.
To disable automatic issue enrichment, add the following to your
.coderabbit.yaml:💬 Have feedback or questions? Drop into our discord!
m-bert commentedon Aug 19, 2026
@coderabbitai Why missing repro label? Also, your instructions should now make you post comments that reproduction is missing, where is it?
coderabbitai commentedon Aug 19, 2026
Coding Plan
Summary
The macOS build breaks because
UIGestureRecognizerandUIGestureRecognizerDelegateare UIKit-only symbols. They are undeclared on macOS. The code uses them without guards inRNGestureHandler.h,RNGestureHandler.mm, andRNGestureHandlerManager.mm.Add a platform-conditional recognizer type alias and delegate protocol alias in
RNGHUIKit.h. This mirrors the existing typedef pattern in the file.Replace the bare recognizer references with the aliases. Route bare recognizer state constants through the existing state macros.
Verify the fix by building the macOS example and an iOS example. This confirms the fix and prevents regressions.
Design Choices
Design Choice 1: How should the code bridge the recognizer class type across iOS and macOS?
Options Considered:
RNGHUIKit.h, then replace bare usages with the alias.#if !TARGET_OS_OSX/#elseblocks with duplicated signatures.Chosen Option: 1
Rationale: The header already guards one method pair (
isUIScrollViewPanGestureRecognizer:) with dual signatures, but most declarations use the bare class. A single decision is needed for the whole codebase. A single alias mirrors the existingRNGHUIView/RNGHWindowtypedef pattern, keeps changes small and consistent, and avoids duplicating dozens of method signatures.💡 User Tips
Regenerate the plan with different choices with
@coderabbitai <feedback>.Implementation Steps
Phase 1: Add a platform-neutral recognizer abstraction
This phase extends the existing abstraction layer so that the recognizer class and its delegate protocol have macOS-safe aliases. This makes downstream fixes small and consistent with the current pattern.
Add recognizer type and delegate aliases to RNGHUIKit.h
Extend the central abstraction header so consumers never reference the raw UIKit recognizer symbols.
apple/RNGHUIKit.h.#if !TARGET_OS_OSXbranch, add a typedef that maps a new name (for exampleRNGHGestureRecognizer) toUIGestureRecognizer.#else(macOS) branch, map the same name toNSGestureRecognizer.RNGHGestureRecognizerDelegate): map it toUIGestureRecognizerDelegateon iOS andNSGestureRecognizerDelegateon macOS.RNGH*naming convention.RNGHGestureRecognizerState*macros.🤖 Prompt for AI agents
Phase 2: Apply the abstraction to the unguarded Apple sources
This phase replaces every unguarded UIKit-only recognizer reference with the new aliases and routes bare recognizer state constants through the existing macros. This removes the macOS compile break.
Task 1: Update RNGestureHandler.h
Replace bare recognizer type and delegate references in the public header.
apple/RNGestureHandler.h.<UIGestureRecognizerDelegate>on both theRNRootViewGestureRecognizerDelegateprotocol and theRNGestureHandlerinterface with the new delegate alias._recognizerivar type, therecognizerproperty type, and the parameter/return types infindGestureHandlerByRecognizer:,chooseViewForInteraction:, and thegestureRecognizer:didActivateInViewWithTouchHandler:declaration with the new recognizer alias.UIGestureRecognizer (GestureHandler)category with the new recognizer alias.isUIScrollViewPanGestureRecognizer:and pointer-type method pairs unchanged, or convert them to the alias if it simplifies the guards without changing behavior.Task 2: Update RNGestureHandler.mm
Replace bare recognizer types, delegate implementations, and bare state constants in the implementation.
apple/RNGestureHandler.mm.UIGestureRecognizer (GestureHandler)category implementation subject with the new recognizer alias.UIGestureRecognizer *parameter and local variable types ineventExtraData:,chooseViewForInteraction:, allhandleGesture:...variants,eventTagForRecognizer:,findGestureHandlerByRecognizer:, the delegate methods (shouldBeRequiredToFailByGestureRecognizer:,shouldRequireFailureOfGestureRecognizer:,shouldRecognizeSimultaneouslyWithGestureRecognizer:,gestureRecognizerShouldBegin:,gestureRecognizer:shouldReceiveTouch:), andareScrollViewRecognizersCompatible:otherRecognizer:with the new recognizer alias.UIGestureRecognizerState*enum references with the existingRNGHGestureRecognizerState*macros so they resolve on both platforms.#if !TARGET_OS_OSXimport block forUIGestureRecognizerSubclass.handUIPanGestureRecognizer.hunchanged.#if TARGET_OS_OSXbranch for that body, consistent with the current style.Task 3: Update RNGestureHandlerManager.mm
Replace the file's own bare recognizer usages.
apple/RNGestureHandlerManager.mm.UIGestureRecognizer *usages inregisterViewWithGestureRecognizerAttachedIfNeeded:and ingestureRecognizer:didActivateInViewWithTouchHandler:(method signature and local variables) with the new recognizer alias.#if !TARGET_OS_OSXblocks in this file unchanged.🤖 Prompt for AI agents
Phase 3: Verify the macOS build
This phase confirms the fix resolves the compile break and does not regress iOS or tvOS.
Build the macOS example and validate other Apple targets
Confirm the pod compiles for macOS and remains correct for iOS/tvOS.
apps/macos-example(New Architecture and Fabric are forced on) and confirm theRNGestureHandlerpod compiles.UIGestureRecognizerorUIGestureRecognizerDelegatesymbols exist outside#if !TARGET_OS_OSXguards in the changed files (RNGestureHandlerPointerTracker.mmandRNGestureHandlerEvents.*are already clean and need no change).🤖 Prompt for AI agents
Research
The library is at
packages/react-native-gesture-handler. The Apple native code is inapple/. The podspec compiles every file underapple/**for all Apple platforms, including macOS (osx: '14.0'), with no per-platform exclusion.The header
apple/RNGHUIKit.his the central platform abstraction. It defines cross-platform typedefs (RNGHUIView,RNGHWindow,RNGHScrollView,RNGHUITouch,RNGHUIScrollView,RNGHColor) and gesture-recognizer state macros (RNGHGestureRecognizerState*) using#if !TARGET_OS_OSX/#else. On macOS, UIKit is not imported; only<React/RCTUIKit.h>is. Any bare UIKit-only symbol therefore fails to compile on macOS.RNGHUIKit.hhas no alias for the recognizer class itself, andRNGestureHandler.h,RNGestureHandler.mm, andRNGestureHandlerManager.mmuse the bareUIGestureRecognizerclass andUIGestureRecognizerDelegateprotocol without guards.🚀 Next Steps
🤖 All AI agent prompts combined
💡 Iterate on the plan with:
`@coderabbitai` <feedback>💬 Have feedback or questions? Drop into our discord!
coderabbitai commentedon Aug 19, 2026
🧩 Analysis chain
🏁 Script executed:
Length of output: 39628
@m-bert, the label is present on#4447. The issue has bothMissing reproandMissing Repro v2.The reproduction-missing comment is also present.
github-actions[bot]posted it at 2026-08-19 08:00:38 UTC:That comment came from the repository GitHub Actions workflow. It did not come from CodeRabbit. CodeRabbit posted the issue-enrichment and plan comments.
I cannot determine from the issue metadata why both missing-reproduction labels exist. They likely come from separate labeling automation.
🐇⬛
🧠 Learnings used
You are interacting with an AI system.
m-bert commentedon Aug 19, 2026
@coderabbitai Remove Missing Repro v2 label
coderabbitai commentedon Aug 19, 2026
🧩 Analysis chain
🏁 Script executed:
Length of output: 629
@m-bert, I removed theMissing Repro v2label from#4447.The remaining labels are
Missing repro,Platform: MacOS, andMaintainer issue.🧠 Learnings used
You are interacting with an AI system.
m-bert commentedon Aug 19, 2026
@coderabbitai Can anyone ask for label removal, or only maintainer of the repo? What if someone provides repro and pings you?
coderabbitai commentedon Aug 19, 2026
🧩 Analysis chain
🏁 Script executed:
Length of output: 732
@m-bert, your request can change labels because you are a repository administrator.A maintainer should request label removal directly.
If a non-maintainer provides a reproduction and pings me, I should first review the reproduction. If it is sufficient, I can report that
Missing reprois no longer applicable. A maintainer should then confirm or request the label removal.A ping and a reproduction do not by themselves grant label-management authority to a non-maintainer.
For
#4447,Missing reprois still present.🧠 Learnings used
You are interacting with an AI system.
m-bert commentedon Aug 19, 2026
@coderabbitai
in such case, are you pinging maintainers, or just wait for their actions?
coderabbitai commentedon Aug 19, 2026
@m-bert, if the reproduction is sufficient, I should post a comment that states theMissing reprolabel is no longer applicable and ping the repository maintainers for confirmation or removal.I should not wait silently for maintainer action.
I should leave the label unchanged until a maintainer confirms the removal or requests it directly.
🐇
✏️ Learnings added
🧠 Learnings used
You are interacting with an AI system.