[0.87] fix(iOS): prevent UUID collision corrupting Pods project in spm_dependency (#57576)

[cipolleschi]

Target Branch

0.87

Link to commit or PR to be picked

react/react-native@1cdf784 (PR react/react-native#57576)

Description

This is a hotfix for a breaking regression introduced by the prebuilt/SwiftPM stack that is being picked into 0.87 (see pick request #1344 and PR react/react-native#57578).

Symptom: any library using spm_dependency breaks the build in prebuilt mode. pod install succeeds, but xcodebuild cannot load the generated Pods project:

-[XCRemoteSwiftPackageReference _setSavedArchiveVersion:]: unrecognized selector sent to instance
Failed to load container at path: .../Pods/Pods.xcodeproj — "The project 'Pods' is damaged and cannot be opened."

This was caught by the first nightly containing the SwiftPM stack, which broke the react-native-enriched-markdown job in react-native-community/nightly-tests.

Root cause: spm_dependency injects package-reference objects from a post_install hook via project.new(...). CocoaPods' Pod::Project uses a deterministic UUID counter and skips collision checks (it assumes a freshly generated project). When the counters are out of sync with the loaded object graph, the first generated UUID collides with an existing object (in the observed failure, the root PBXProject's own UUID), silently overwriting the root object so the saved rootObject points at the injected package reference. The bug has been latent in spm_dependency since it was introduced; the larger Pods object graph in the new stack merely exposed it.

Fix: route object creation through a new_object helper that keeps the deterministic counter but probes generate_uuid forward past any UUID already present in objects_by_uuid, guaranteeing uniqueness against the live object table. Repeated pod installs stay idempotent via the existing find-before-create dedup guards.

Scope: small and contained — 2 files, +126/-3, touching only scripts/cocoapods/spm.rb and a new standalone test scripts/cocoapods/__tests__/spm-test.rb. Already merged on main.

Applicable criteria: fix to a bug in core React Native (#2) and fix of an accidental breaking change (#6) — this repairs a break in the very SwiftPM feature being shipped in 0.87.

[github-actions]

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

1. ✅ Fixes for regressions to core APIs. Examples:
   • A core component is behaving differently between versions 0.X and 0.X-1
   • The TurboModule.getEnforcing function is throwing an unexpected assertion error.
2. ✅ 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
3. ✅ Fixes to APIs used by third-party libraries and out-of-tree platforms. Examples:
   • An API used by react-native-macos is not behaving as expected or is regressing
4. ✅ Bump of patch version of dependencies. Example:
   • Bump Gradle from 8.11.0 to 8.11.1
5. ✅ 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.
6. ✅ 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.
7. ✅ Performance improvements. Examples:
   • Fixing unnecessary re-renders in FlatList.
8. ✅ Any Pick Request if the release is still in RC0 (after RC1, the previously listed criteria apply)

❌ Which Pick Requests we don't accept

9. ❌ 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
10. ❌ 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.
11. ❌ 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
12. ❌ Bump of a dependency to a pre-release version. Example:
    • Bump Gradle from 8.11.0 to 8.11.1-beta.1
13. ❌ 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
14. ❌ 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.
15. ❌ Any non-critical improvement that landed on main.
    • These will generally ship in the following version unless they fit one of the criteria above.
16. ❌ 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.

[zeyap]

@react-native-bot merge 1cdf784a068e2ed16842b74c0b87b7ff7532fe03 0.87-stable

[react-native-bot]

✅ Successfully picked up your commit react/react-native@1cdf784 on the branch https://github.com/facebook/react-native/commits/0.87-stable