Repository navigation
[0.87] Set SWIFT_ACTIVE_COMPILATION_CONDITIONS = DEBUG when injecting SPM #1374
Description
Activity
Thank you for opening a new React Native Pick Request.
These are the criteria we follow when accepting or rejecting a code change into a React Native release branch (source).
If your Pick Request does not satisfy the criteria below, please close it as it will not be considered.
✅ Which Pick Requests we accept
- ✅ Fixes for regressions to core APIs. Examples:
- A core component is behaving differently between versions 0.X and 0.X-1
- The
TurboModule.getEnforcingfunction is throwing an unexpected assertion error.
- ✅ Fixes to bugs in core React Native. Examples:
- Breakpoints in React Native DevTools not working correctly in the debugger
- Fast Refresh not working as expected
- Metro bundler not starting properly or ignoring the configuration file
- Buttons that are not clickable
- ✅ Fixes to APIs used by third-party libraries and out-of-tree platforms. Examples:
- An API used by
react-native-macosis not behaving as expected or is regressing
- An API used by
- ✅ Bump of patch version of dependencies. Example:
- Bump Gradle from 8.11.0 to 8.11.1
- ✅ Fixes for low/high severity security vulnerabilities. Example:
- Bump Gradle from 8.11.0 to 8.12.0 if there is a security vulnerability in 8.11 and no 8.11.x version contains the same fix.
- ✅ Fixes and reverts of accidental breaking changes. Example:
- Reverting or fix-forwarding a Kotlin migration of a file (e.g.
ReactRootView.java) if it is causing a breaking change for the React Native ecosystem.
- Reverting or fix-forwarding a Kotlin migration of a file (e.g.
- ✅ Performance improvements. Examples:
- Fixing unnecessary re-renders in FlatList.
- ✅ Any Pick Request if the release is still in RC0 (after RC1, the previously listed criteria apply)
❌ Which Pick Requests we don't accept
- ❌ Any Pick Request that introduces a breaking change after RC1. Example:
- A bugfix that contains a refactoring, resulting in changes to the public API of a class
- ❌ Any Pick Request that introduces a new feature after RC1. Example:
- A commit that introduces a new API or a specific feature for a component.
- ❌ Bump of major or minor version of dependencies. Examples:
- Bump Gradle from 8.11.0 to 8.12.0
- Bump Gradle from 8.11.0 to 9.0.0
- ❌ Bump of a dependency to a pre-release version. Example:
- Bump Gradle from 8.11.0 to 8.11.1-beta.1
- ❌ Any Pick Request that introduces changes to the React Native testing infrastructure after RC1. Examples:
- Changes to GitHub Actions workflows to optimize them, even if they are on main.
- Changes to the logic used to publish packages to NPM or Maven Central
- ❌ Pick Request composed of multiple commits that have several merge conflicts.
- If your Pick Request is too complex to apply to the release branch, it will be rejected.
- ❌ Any non-critical improvement that landed on main.
- These will generally ship in the following version unless they fit one of the criteria above.
- ❌ Any Pick Request considered a "nice to have".
- Even one-line changes carry a risk of destabilizing and further delaying the release.
ℹ️ What makes for a good Pick Request
In order for your Pick Request to be considered, please do the following:
- ℹ️ Limit your Pick Request to one commit from
main, or one PR against the release branch. - ℹ️ Include a clear explanation of why your Pick Request should be considered, ideally referencing one of the criteria above.
- ℹ️ Target only one minor version of React Native (e.g. [0.76]). To have your Pick Request applied to more versions, please open separate Pick Requests.
- ✅ Fixes for regressions to core APIs. Examples:
Included in for the 0.87.1 release via react/react-native@f0800d9ec446. Closing this pick request.
- moved this from Inbox to Done / Picked in React Native 0.87 Releases
on Aug 26, 2026 Correction: included in branch 0.87-stable for the 0.87.1 release. The commit link in the previous comment is correct.
Target Branch
0.87
Link to commit or PR to be picked
react/react-native#57914
Landed on
mainas react/react-native@4433cdbDescription
Swift's
#if DEBUGis gated bySWIFT_ACTIVE_COMPILATION_CONDITIONS, not byGCC_PREPROCESSOR_DEFINITIONS(which only reaches C/ObjC/C++). The app template does not commit that setting; CocoaPods injects it atpod installtime (react_native_post_install→set_build_setting SWIFT_ACTIVE_COMPILATION_CONDITIONS = ["$(inherited)", "DEBUG"]on Debug).An app set up with the experimental SwiftPM support never runs CocoaPods, so
#if DEBUGis false even in a Debug build:AppDelegate.swift'sbundleURL()skips the Metro URL and falls back to amain.jsbundlethat a Debug build never produced. The app dies at launch withNo script url provided ... unsanitizedScriptURLString = (null)while Metro is running.This makes SwiftPM Debug builds unusable on 0.87 out of the box, which is why it is worth picking.
The fix injects the setting from
spm add/updatealongside the other React build settings, into debug-flavored configurations only (the sameflavorForBuildConfigurationtest that selects the debug xcframeworks). Doing it in the injector rather than in the app template fixes existing apps too, and keeps the setting on the one code path that knows a project is SwiftPM-integrated.The merge is additive and reversible like every other injected setting: a config that already defines
DEBUGis left byte-identical. Related context: react-native-community/template#244.