Skip to content

Add an iOS withDangerousMod to the Expo config plugin that patches RCTThirdPartyComponentsProvider.mm#176

Open
Th0mYT wants to merge 8 commits intoazesmway:mainfrom
Th0mYT:main
Open

Add an iOS withDangerousMod to the Expo config plugin that patches RCTThirdPartyComponentsProvider.mm#176
Th0mYT wants to merge 8 commits intoazesmway:mainfrom
Th0mYT:main

Conversation

@Th0mYT
Copy link

@Th0mYT Th0mYT commented Feb 20, 2026

What was changed: plugin/src/index.ts (and its compiled output plugin/build/index.js)

What was broken: Expo's prebuild ran the C++ codegen for unityview but never generated the Fabric registration step. RNUnityViewCls() was defined in RNUnityView.mm but never
called, so Fabric couldn't find the component by name, fell back to the legacy interop layer, and updateProps was never dispatched.

The fix — withIosFabricRegistration: A new iOS withDangerousMod that runs at the end of every npx expo prebuild and patches RCTThirdPartyComponentsProvider.mm with two insertions:

// 1. Forward declaration (before @implementation)
Class RNUnityViewCls(void);

// 2. Dictionary entry (inside thirdPartyFabricComponents)
@"RNUnityView" : RNUnityViewCls(),

Call chain after the fix (matches what should happen):
codegenNativeComponent('RNUnityView')
→ Fabric finds RNUnityView via RCTThirdPartyComponentsProvider
→ initWithFrame: (lambda set, initUnityModule called as belt-and-suspenders)
→ updateEventEmitter:
→ updateProps: ← initUnityModule() ← Unity starts ✓

The initUnityModule call in initWithFrame: from the previous commit remains — it acts as a safety net for any edge case where updateProps might still be delayed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant