Uh oh!
There was an error while loading. Please reload this page.
docs(ios-prebuild): correct how SwiftPM consumes the prebuilt React headers - #58007
Closed
chrfalch wants to merge 1 commit into
Closed
docs(ios-prebuild): correct how SwiftPM consumes the prebuilt React headers#58007chrfalch wants to merge 1 commit into
chrfalch wants to merge 1 commit into
Conversation
## Summary: `ios-prebuild/__docs__/README.md` said `React.framework`'s headers-spec layout "is what both CocoaPods and SwiftPM consume". That is right for CocoaPods and misleading for SwiftPM: `React.xcframework` is not a member of the Swift package graph at all, so nothing on the SwiftPM side reads its framework module map. What actually happens is a staging step on the consumer side — `stageReactHeadersTarget` in `scripts/spm/flavored-frameworks.js` copies `React.framework/Headers` into `ReactHeadersTarget/include/React` and rewrites `framework module React` to a plain `module React`, which is then vended as the `ReactHeaders` target. The prebuild output is still the source of those headers, which is why the sentence was nearly right; the consumption path is what differs. Says so, and keeps the CocoaPods half explicit about `FRAMEWORK_SEARCH_PATHS` so the two paths read as the distinct mechanisms they are. ## Changelog: [Internal] - Clarify that SwiftPM consumes the prebuilt React headers through a staged `ReactHeaders` target, not through the XCFramework's module map ## Test Plan: Docs only. Verified against `scripts/spm/generate-spm-package.js`, whose generated `ReactNative` manifest declares exactly three headers-only products and no runtime `binaryTarget`, and against `stageReactHeadersTarget`, which does the copy and the module-map rewrite only after Debug and Release are asserted to expose identical headers. Prettier clean — the file was formatted before this change and still is. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
cipolleschi
approved these changes
Aug 19, 2026
@cipolleschi has imported this pull request. If you are a Meta employee, you can view this in D116598314. |
@cipolleschi merged this pull request in 0c86952. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary:
ios-prebuild/__docs__/README.mdsaidReact.framework's headers-spec layout"is what both CocoaPods and SwiftPM consume". That is right for CocoaPods and
misleading for SwiftPM:
React.xcframeworkis not a member of the Swift packagegraph at all, so nothing on the SwiftPM side reads its framework module map.
What actually happens is a staging step on the consumer side —
stageReactHeadersTargetinscripts/spm/flavored-frameworks.jscopiesReact.framework/HeadersintoReactHeadersTarget/include/Reactand rewritesframework module Reactto a plainmodule React, which is then vended as theReactHeaderstarget. The prebuild output is still the source of those headers,which is why the sentence was nearly right; the consumption path is what differs.
Says so, and keeps the CocoaPods half explicit about
FRAMEWORK_SEARCH_PATHSsothe two paths read as the distinct mechanisms they are.
Changelog:
[Internal] - Clarify that SwiftPM consumes the prebuilt React headers through a
staged
ReactHeaderstarget, not through the XCFramework's module mapTest Plan:
Docs only. Verified against
scripts/spm/generate-spm-package.js, whose generatedReactNativemanifest declares exactly three headers-only products and no runtimebinaryTarget, and againststageReactHeadersTarget, which does the copy and themodule-map rewrite only after Debug and Release are asserted to expose identical
headers. Prettier clean — the file was formatted before this change and still is.
Co-Authored-By: Claude Opus 5 noreply@anthropic.com