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
pod install succeeds but immediately warns, and the subsequent Xcode build fails outright, on a fresh install of react-native@0.88.0-rc.0 (via expo@58.0.0-preview.2, Expo SDK 58 preview) using the standard CocoaPods prebuilt-binary integration. This is a different, independent issue from #58561 (which is about 0.86.3's prebuilt binary having an ABI mismatch with Hermes) — this one fails to even compile.
pod install warning (printed before any build step runs)
[!] [Expo] Prebuilt React-Core-prebuilt is missing Headers/module.modulemap — skipping Expo module-map coverage.
If the build fails with a missing module map or -Wnon-modular-include, the installed prebuilt React does not
match React Native's CocoaPods scripts; install a tarball that ships ReactNativeHeaders via
RCT_TESTONLY_RNCORE_TARBALL_PATH.
Build failure
error: module map file '.../ios/Pods/React-Core-prebuilt/Headers/module.modulemap' not found (in target 'libwebp' from project 'Pods')
(repeated across every target that depends on the React-Core-prebuilt module map — libwebp and others)
Repro
Fresh Expo SDK 58 preview bare-workflow app (or any app pinning react-native@0.88.0-rc.0 via the standard CocoaPods prebuilt-binary integration).
pod install — note the Headers/module.modulemap warning above.
Build for iphonesimulator.
Build fails with the module-map error above; does not compile at all.
Environment
react-native: 0.88.0-rc.0
expo: 58.0.0-preview.2 (SDK 58 preview)
Xcode: 27.0
Platform: macOS, arm64 (Apple Silicon)
Additional note (not this bug, but encountered getting to this repro)
react-native-worklets and react-native-reanimated's published peer ranges (0.83 - 0.87, as of react-native-worklets@0.12.2 / react-native-reanimated@4.6.0) don't yet include 0.88.x — npm install requires --legacy-peer-deps to get past that. Separate concern, flagging in case it's useful context for release sequencing.
Expected behavior
The React-Core-prebuilt tarball fetched for 0.88.0-rc.0 should ship a complete Headers/ directory including module.modulemap, matching what React Native's own CocoaPods integration scripts expect — no missing-file build failure.
Missing reproducer: We could not detect a reproducible example in your issue report. Reproducers are mandatory and we can accept only one of those as a valid reproducer:
For majority of bugs: send us a Pull Request with the RNTesterPlayground.js edited to reproduce your bug.
Closing — we're no longer pursuing the Expo SDK 58 preview upgrade this was found under, so this is no longer something we need fixed.
Also flagging honestly: unlike #58561 (which I was able to disprove as project-specific via a blank-app repro before closing it), I never got the chance to verify whether this modulemap failure is a genuine react-native@0.88.0-rc.0 defect or something specific to our project's dependency graph the same way #58561 turned out to be. Given that history, I don't want to leave this open implying a verified general bug when it isn't one — closing rather than asserting either way. Apologies for the churn.
Activity
react-native-bot commentedon Sep 16, 2026
Warning
Missing reproducer: We could not detect a reproducible example in your issue report. Reproducers are mandatory and we can accept only one of those as a valid reproducer:
You can read more about about it on our website: How to report a bug.
bryandent commentedon Sep 16, 2026
Closing — we're no longer pursuing the Expo SDK 58 preview upgrade this was found under, so this is no longer something we need fixed.
Also flagging honestly: unlike #58561 (which I was able to disprove as project-specific via a blank-app repro before closing it), I never got the chance to verify whether this modulemap failure is a genuine
react-native@0.88.0-rc.0defect or something specific to our project's dependency graph the same way #58561 turned out to be. Given that history, I don't want to leave this open implying a verified general bug when it isn't one — closing rather than asserting either way. Apologies for the churn.