iOS build fails on React Native 0.87 (prebuilt core): "declaration of 'facebook' must be imported from module 'React'" — Video-Bridging-Header.h published as a public header

[GratwickEnt]

What happened?

Building an iOS Debug simulator target fails while compiling the ReactNativeVideo Objective-C module, with:

Pods/Headers/Private/NitroModules/JSIConverter.hpp:19:17: error: declaration of 'facebook' must be imported from module 'React' before it is required
Pods/Headers/Private/NitroModules/JSIConverter.hpp:36:32: error: missing '#include "jsi/jsi.h"'; 'Runtime' must be declared before it is used
<unknown>:0: error: could not build Objective-C module 'ReactNativeVideo'

raised by swift-frontend -emit-module for the ReactNativeVideo target.

Mechanism: ReactNativeVideo.podspec sets s.public_header_files = ["ios/Video-Bridging-Header.h"]. add_nitrogen_files() (in nitrogen/generated/ios/ReactNativeVideo+autolinking.rb) then appends the Nitrogen-generated public headers to whatever public_header_files already contains:

current_public_header_files = Array(spec.attributes_hash['public_header_files'])
spec.public_header_files = current_public_header_files + [
  "nitrogen/generated/shared/**/*.{h,hpp}",
  "nitrogen/generated/ios/ReactNativeVideo-Swift-Cxx-Bridge.hpp"
]

so Video-Bridging-Header.h always lands first in the generated ReactNativeVideo-umbrella.h, ahead of the Nitrogen Hybrid*Spec.hpp headers. Video-Bridging-Header.h is one line: #import <React/RCTViewManager.h>.

Under React Native 0.87's default prebuilt core (RCT_USE_PREBUILT_RNCORE=1), module React's module.modulemap (umbrella header "React-umbrella.h") owns jsi/jsi.h - the prebuilt Headers/ tree that ships with the core contains it. Because the umbrella imports React/RCTViewManager.h first, module React is already fully loaded by the time NitroModules' JSIConverter.hpp does its own textual #include "jsi/jsi.h". Clang then treats jsi.h as already owned by module React and refuses the textual include from inside a different module's build, producing the error above.

Control: two other Nitro-based libraries in the same app - react-native-iap 16.5.1 (NitroIap) and react-native-mmkv 4.3.2 (NitroMmkv) - build cleanly against the same NitroModules headers in the same build. Neither publishes a bridging header in its own umbrella (only their Nitrogen-generated headers are public), which is what isolates the trigger to this one podspec line.

Also checked and confirmed on this repo: no Swift file in packages/react-native-video/ios references any symbol from RCTViewManager.h, and both ObjC view manager files that need it (ios/view/paper/RCTVideoViewViewManager.m, ios/view/fabric/RCTVideoViewViewManager.mm) already #import <React/RCTViewManager.h> directly themselves. There is no SWIFT_OBJC_BRIDGING_HEADER wiring anywhere in the package that references Video-Bridging-Header.h by name - the only place it is referenced today is that one public_header_files line.

This reproduces the same way on v7.0.0-beta.9 and current master (v7.0.0-beta.11 plus later commits) - git diff between those two tags shows ReactNativeVideo.podspec's public_header_files line and ios/Video-Bridging-Header.h are byte-identical between them, and unchanged on master since v7.0.0-beta.11.

The same app built cleanly against react-native-video on React Native 0.86.2 with the same Nitro versions.

I'm opening this alongside a one-line fix PR: removing Video-Bridging-Header.h from public_header_files (it stays compiled into the pod via the existing ios/*.{h,m,mm,swift} source_files glob; it just no longer sits in the public umbrella ahead of the Nitrogen headers).

Steps to reproduce

There's no separate reproduction repository; any React Native 0.87.1 app with react-native-video 7.0.0-beta.9 (or beta.11), CocoaPods static linkage (no use_frameworks!), the default prebuilt core, and New Architecture on reproduces this:

1. Add react-native-video (7.0.0-beta.9 or 7.0.0-beta.11) to a React Native 0.87.1 app that also uses at least one other Nitro module (e.g. react-native-nitro-modules 0.36.5, react-native-mmkv, or react-native-iap).
2. pod install with static libraries (no use_frameworks!), New Architecture on, default RCT_USE_PREBUILT_RNCORE=1 / RCT_USE_RN_DEP=1.
3. xcodebuild ... -sdk iphonesimulator (Debug configuration) for the app.
4. The build fails compiling the ReactNativeVideo Objective-C module with the error above; react-native-mmkv / react-native-iap in the same build succeed.

Reproduction repository

No response - see "Steps to reproduce"; the bug reproduces in any RN 0.87.1 app matching the environment above, not from anything specific to one app's code.

react-native-video version

7.0.0-beta.9 (also confirmed reproducing on 7.0.0-beta.11 - see mechanism above)

react-native version

0.87.1

react-native-nitro-modules version

0.36.5

Platforms

iOS

OS version

Xcode 26.6 (Build 17F113), iOS Simulator

Device

Simulator / Emulator

Architecture

New Architecture

Expo

No (bare / React Native CLI)

Last working version

Same react-native-video and react-native-nitro-modules versions built cleanly against react-native 0.86.2.

Media / source type

No response - this is a build-time module-compilation failure, unrelated to media/source type.

[github-actions]

Thanks for creating the issue! It will be triaged soon.

• You reported 7.0.0-beta.9 (also confirmed reproducing on 7.0.0-beta.11 - see mechanism above), but a newer version (7.0.0-beta.11) is available - please retest on it and update the report if it still happens; many problems are already fixed there.
• We could not find a reproduction link - a minimal repro helps us fix it much faster, so please add one if you can.

[mziolkowskii]

Thanks for the unusually thorough report. I reproduced this locally and your diagnosis is correct in every detail.

Repro setup: our RNTA-based E2E test app bumped to RN 0.87.1 / React 19.2.3, CocoaPods static libs, New Arch, default prebuilt core (pod install logs [ReactNativeCore] Configuring xcconfig for prebuilt React Native Core), Xcode 26, iOS 26 simulator.

Confirmed

The failure reproduces exactly as described, and the compiler names the ownership your write-up rests on:

Pods/Headers/Private/NitroModules/JSIConverter.hpp:19:17: error: declaration of 'facebook'
    must be imported from module 'React' before it is required
Pods/Headers/Public/React-Core-prebuilt/jsi/jsi.h:705:18: note: declaration here is not visible

jsi/jsi.h is owned by module React under the prebuilt core, as you said. Also confirmed: the generated ReactNativeVideo-umbrella.h starts with #import "Video-Bridging-Header.h" ahead of every Nitrogen *.hpp, and the header is dead code — no Swift file in the package references RCTViewManager or any RCT* symbol, both view managers import <React/RCTViewManager.h> themselves, and nothing sets SWIFT_OBJC_BRIDGING_HEADER to it.

RN 0.87 needs two more changes beyond #5085

Your podspec fix is correct but only clears the first blocker. With it applied, the build fails one layer down:

ios/view/fabric/RCTVideoViewViewManager.mm:3:9: fatal error: 'RCTBridge.h' file not found

Three quoted imports of React headers don't resolve under the prebuilt core:

• ios/view/fabric/RCTVideoViewViewManager.mm:3 — #import "RCTBridge.h"
• ios/view/paper/RCTVideoViewViewManager.m:2 — #import "RCTEventDispatcher.h"
• ios/view/fabric/RCTVideoViewComponentView.mm:8 — #import "RCTFabricComponentsPlugins.h"

Under RN 0.77 built from source, CocoaPods flattens the React-Core headers and the quoted form resolves. Under 0.87's prebuilt core it doesn't — RCTBridge.h isn't in the Pods header tree at all, it lives inside the vendored React.framework. Switching all three to <React/...> fixes it.

Then a runtime blocker: with react-native-nitro-modules@0.35.0 the app builds and launches but immediately red-screens with Failed to install Nitro: installJSIBindingsWithRuntime: was not called. Bumping to 0.37.1 resolves it — and the library's committed nitrogen-0.35 generated output compiles and runs fine against that newer runtime, so no regeneration is needed.

With all three in place, our full Maestro E2E suite passes 10/10 on RN 0.87.1.

Status

So the full picture for RN 0.87 support is three changes, of which #5085 is the first. Keeping this open until all three land — #5085 alone won't make an 0.87 build pass, so it shouldn't auto-close this.