Cocoapods deprecation

[roryabraham]

Cocoapods is slated to be EOL in December 2026. Creating this issue as a reminder to investigate what's needed to transition fully to Swift Package Manager.

Some resources:

• https://dev.to/estolegion/react-native-roadmap-to-swift-package-manager-2026-3elg
• https://www.callstack.com/blog/integrating-swift-package-manager-with-react-native-libraries

[roryabraham]

no update for now. Hoping that someone else will do the heavy lifting to figure this out in the React Native upstream.

[roryabraham]

@mateuuszzzzz would you be interested in helping to supervise this? With your experience in the cocoapods/prebuilt binaries, I think you'd be a good fit.

[roryabraham]

@MelvinBot is there any upstream tracking issue in the React Native repo to migrate from Cocoapods to SPM?

[MelvinBot]

There's no single umbrella tracking issue in the React Native repo itself. Upstream tracking lives in react-native-community/discussions-and-proposals, and the plan of record is RFC0994: Swift Package Manager Support for React Native iOS Projects — open since 2026-04-21, authored by chrfalch (Callstack), explicitly framed around the December 2026 CocoaPods deprecation.

The two places to watch:

Where	What it is
react-native-community/discussions-and-proposals#994	The RFC / plan of record. Covers core packaging (prebuilt XCFrameworks + headers-only SPM products), autolinking, Codegen, an npx react-native spm CLI with add --deintegrate for existing Podfile apps, and the adoption strategy.
react-native-community/discussions-and-proposals#587	The long-running community discussion (open since Jan 2023, 80+ comments). This is where the vendor CocoaPods-EOL notices land — Firebase (no new CocoaPods releases after Oct 2026), Google Maps, reCAPTCHA.

Implementation is already landing, not just proposed. Note the repo moved: it's now react/react-native, not facebook/react-native.

Current upstream status

• SwiftPM commits are landing on main right now, e.g. Derive an SPM library's Swift name from its podspec (#58290), landed 2026-09-09. RN closes these PRs via the Meta importer, so GitHub shows them as "closed" rather than "merged" — check main's commit log for the real state.
• An experimental SwiftPM path exists as of 0.87 — see #57917 (Hermes bytecode mismatch on 0.87 SwiftPM release builds, since closed) and #58359 (SPM setup generates set -euo pipefail scripts but runs them with /bin/sh, still open).
• Open workstreams: #52909 (build from source with SwiftPM), #53529 (build HelloWorld from source), #58084 (docs).
• Adoption strategy from the RFC: opt-in first, CocoaPods and SPM supported in parallel for several releases, SPM becomes the default for new apps only "after ecosystem readiness is high enough," and existing apps are not expected to migrate immediately. There is no committed date beyond the Dec 2026 CocoaPods read-only deadline — a direct timeline question to cipolleschi on Update version to 1.0.1-92 #587 (2026-06-22) is still unanswered.
• Background talk from App.js 2026: https://youtu.be/5nHDA39K4NE

So the heavy lifting you were hoping for is in progress. The practical read for us: subscribe to #994 and #587, and the thing that will actually gate us is third-party library readiness — every native dep we use needs a Package.swift or SPM metadata, and the RFC pushes that onto library authors during the transition.

---

Next Steps: Reply with @MelvinBot <your feedback> to refine this.

---

view run · no recording available

[roryabraham]

seems like @mrousavy also likely has good context on the Nitro side of things

[mrousavy]

Yup, we can do that @ margelo