Define RN_BUILDING for React Native's own CocoaPods targets (#57858) - #57858
Open
coado wants to merge 2 commits into
Open
Define RN_BUILDING for React Native's own CocoaPods targets (#57858)#57858coado wants to merge 2 commits into
coado wants to merge 2 commits into
Conversation
meta-cla
Bot
added
the
CLA Signed
facebook-github-tools
Bot
added
p: Software Mansion
|
@coado has exported this pull request. If you are a Meta employee, you can view the originating Diff in D115051089. |
meta-codesync
Bot
changed the title
coado
force-pushed
the
export-D115051089
branch
from
August 11, 2026 09:25
855c8d8 to
dd822b4
Compare
coado
added a commit
to coado/react-native
that referenced
this pull request
Aug 11, 2026
) Summary: Pull Request resolved: react#57858 `RN_BUILDING` marks React Native's own targets so the react/cxxstableapi guards stay inert for internal sources, which keep including fine-grained headers directly. It is required whenever `RN_STRICT_API` reaches React Native's own compilation rather than only the consumer's: - Project-wide enablement — a consumer applying the flag to every pod target (the CocoaPods post_install idiom) or through a global Buck config. Without RN_BUILDING, React Native's own translation units fail against their own guards. - Private headers — `PrivateGuard.h` has no umbrella escape (#if defined(RN_STRICT_API) && !defined(RN_BUILDING)), so RN_BUILDING is the only way internal code can include them at all. Mark every first-party pod as part of React Native's own build by defining `RN_BUILDING` for it, through a new `mark_as_react_native_build` helper called last in each spec block This change is inert on its own: nothing behaves differently unless a consumer defines `RN_STRICT_API`. Changelog: [Internal] Differential Revision: D115051089
Summary: `install_modules_dependencies` is the helper every third-party New Architecture library calls from its own podspec, and `update_search_paths` covers the user project and the pod targets that don't go through it. Neither knew about `React-cxxstableapi`. React Native's public C++ headers are starting to include the shared guard header `<react/cxxstableapi/UmbrellaGuard.h>`. The include is unconditional, so a third-party pod that includes any guarded React Native header has to be able to resolve it. Today it can't: in the default static-library mode `$(PODS_ROOT)/Headers/Public/React-cxxstableapi` is missing from the search path, and under `use_frameworks!` the `React_cxxstableapi.framework/Headers` entry is missing. Declare the dependency and add the matching framework header search path in both places. Changelog: [iOS][Added] - Add a `React-cxxstableapi` dependency to third-party New Architecture pods so they can resolve React Native's C++ API guard headers Differential Revision: D110052811
) Summary: Pull Request resolved: react#57858 `RN_BUILDING` marks React Native's own targets so the react/cxxstableapi guards stay inert for internal sources, which keep including fine-grained headers directly. It is required whenever `RN_STRICT_API` reaches React Native's own compilation rather than only the consumer's: - Project-wide enablement — a consumer applying the flag to every pod target (the CocoaPods post_install idiom) or through a global Buck config. Without RN_BUILDING, React Native's own translation units fail against their own guards. - Private headers — `PrivateGuard.h` has no umbrella escape (#if defined(RN_STRICT_API) && !defined(RN_BUILDING)), so RN_BUILDING is the only way internal code can include them at all. Mark every first-party pod as part of React Native's own build by defining `RN_BUILDING` for it, through a new `mark_as_react_native_build` helper called last in each spec block This change is inert on its own: nothing behaves differently unless a consumer defines `RN_STRICT_API`. Changelog: [Internal] Differential Revision: D115051089
coado
force-pushed
the
export-D115051089
branch
from
August 11, 2026 09:56
dd822b4 to
c484781
Compare
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 free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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:
RN_BUILDINGmarks React Native's own targets so the react/cxxstableapi guards stay inert for internal sources, which keep including fine-grained headers directly.It is required whenever
RN_STRICT_APIreaches React Native's own compilation rather than only the consumer's:PrivateGuard.hhas no umbrella escape (#if defined(RN_STRICT_API) && !defined(RN_BUILDING)), so RN_BUILDING is the only way internal code can include them at all.Mark every first-party pod as part of React Native's own build by defining
RN_BUILDINGfor it, through a newmark_as_react_native_buildhelper called last ineach spec block
This change is inert on its own: nothing behaves differently unless a consumer defines
RN_STRICT_API.Changelog: [Internal]
Differential Revision: D115051089