@synthesize bridge = _bridge not working with bridgeless mode and TurboModule

[louiszawadzki]

Description

I'm developing a module that uses the bridge to access the uiManager and run code on the JS thread.

I'm calling @synthesize bridge = _bridge to get a reference to the bridge in my module.

When turning bridgeless mode on, the reference to the bridge is null.
This document specifies that we should get a RCTBridgeProxy, which is not the case.

I've investigated a little bit and figured that the issue disappears when I remove RCTTurboModule from the protocols of the generated Spec module:

// in React-Codegen/RNMyModuleSpec/RNMyModuleSpec.h
// from
@protocol MyModuleSpec <RCTBridgeModule, RCTTurboModule>

// to
@protocol MyModuleSpec <RCTBridgeModule>

Similarly, if I declare that my interface inherits RCTBridgeModule instead of my generated Spec, the issue is fixed.

I've checked and this issue happens with RN 0.73.6 and 0.74.0-rc.3.

Steps to reproduce

I've created a repo containing a package and a sample app reproducing the issue: https://github.com/louiszawadzki/react-native-rn074-synthesize-issue

The installation and reproduction steps are in the README of this repo.

Run the app and check the iOS logs to see the value of the bridge.

React Native Version

0.74.0-rc.3

Affected Platforms

Runtime - iOS

Areas

Bridgeless - The New Initialization Flow

Output of npx react-native info

System:
  OS: macOS 14.3.1
  CPU: (10) arm64 Apple M1 Max
  Memory: 111.36 MB / 64.00 GB
  Shell:
    version: "5.9"
    path: /bin/zsh
Binaries:
  Node:
    version: 18.19.0
    path: ~/.volta/tools/image/node/18.19.0/bin/node
  Yarn:
    version: 1.22.19
    path: ~/.volta/tools/image/yarn/1.22.19/bin/yarn
  npm:
    version: 10.2.3
    path: ~/.volta/tools/image/node/18.19.0/bin/npm
  Watchman:
    version: 2023.11.20.00
    path: /opt/homebrew/bin/watchman
Managers:
  CocoaPods:
    version: 1.12.1
    path: /Users/louis.zawadzki/.rbenv/shims/pod
SDKs:
  iOS SDK:
    Platforms:
      - DriverKit 23.4
      - iOS 17.4
      - macOS 14.4
      - tvOS 17.4
      - visionOS 1.1
      - watchOS 10.4
  Android SDK: Not Found
IDEs:
  Android Studio: 2023.1 AI-231.9392.1.2311.11330709
  Xcode:
    version: 15.3/15E204a
    path: /usr/bin/xcodebuild
Languages:
  Java:
    version: 17.0.8
    path: /Users/louis.zawadzki/.sdkman/candidates/java/17.0.8-oracle/bin/javac
  Ruby:
    version: 2.7.5
    path: /Users/louis.zawadzki/.rbenv/shims/ruby
npmPackages:
  "@react-native-community/cli": Not Found
  react:
    installed: 18.2.0
    wanted: 18.2.0
  react-native:
    installed: 0.74.0-rc.3
    wanted: 0.74.0-rc.3
  react-native-macos: Not Found
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: true
  newArchEnabled: true
iOS:
  hermesEnabled: Not found
  newArchEnabled: false

Stacktrace or Logs

N/A

Reproducer

https://github.com/louiszawadzki/react-native-rn074-synthesize-issue

Screenshots and Videos

No response

[RSNara]

When turning bridgeless mode on, the reference to the bridge is null.

@louiszawadzki, @synthesize bridge = _bridge only works with legacy modules, and interop modules.

By directly conforming to RCTTurboModule, or conforming to the code-generated interface, you made your module turbomodule-compatible. So, it started going through the all new code-paths, which don't decorate modules with the RCTBridge property.

I'm developing a module that uses the bridge to access the uiManager and run code on the JS thread.

Why do you need the bridge? Is it only for dispatching to the javascript thread? If so, have you tried to make your module conform to RCTJSDispatcherModule? That should give your module an api to call onto javascript.

[louiszawadzki]

Hi @RSNara, thanks a lot for your reply!
I'm not maintaining the repo anymore but this might get picked up again in a few months.

cc @plousada going through my github notifications I noticed this that should help regarding supporting the bridgeless mode for SR and JS framerate.

[cortinico]

I'm not maintaining the repo anymore but this might get picked up again in a few months.

Closing then as we're actively tracking those kind of issues.
If you need further support, please comment here or open a new issue.