CocoaPods trunk goes read-only: what it means for React Native and Expo

The topic keeps coming up, usually phrased wrongly: "CocoaPods shuts down in December." That is not what CocoaPods says. This guide goes back to the primary sources, separates what has shipped from what has been announced, and lays out what a React Native or Expo team can do today.

The calendar

Orta Therox published the plan on November 30, 2024 as CocoaPods Trunk Read-only Plan (opens in a new window), and updated it in May 2025. It follows the August 2024 post on CocoaPods maintenance (opens in a new window), which already described the project as being in "maintenance mode" and wrote, about React Native, that the situation "could be fine as-is, as most of their libraries come via npm instead of the Trunk".

Date	Event	Source
November 30, 2024	Read-only plan published	blog.cocoapods.org (opens in a new window)
May 2025	New pods using prepare_command are refused; existing pods that use it are exempted	blog.cocoapods.org (opens in a new window)
August 18, 2025	Google Maps SDK for iOS: CocoaPods "in maintenance mode", no more CocoaPods versions after Q2 2026	Maps release notes (opens in a new window)
May 26, 2026	Firebase 12.14.0: no new CocoaPods versions after October 2026	Firebase release notes (opens in a new window)
August 6, 2026	Google Maps SDK for iOS 11.0.0: "CocoaPods is deprecated as of version 11.0.0"	Maps release notes (opens in a new window)
August 11, 2026	React Native 0.87: experimental SPM support, npx react-native spm	reactnative.dev (opens in a new window)
September 9, 2026	Firebase 12.19.0: "the final scheduled release published to CocoaPods"	Firebase release notes (opens in a new window)
October 7, 2026	Firebase 13.0.0: distributed only through SPM and binaries	Firebase release notes (opens in a new window)
October 15, 2026	React Native 0.88.0 and Expo SDK 58	RN releases (opens in a new window), Expo changelog (opens in a new window)
October 19, 2026	react-native-firebase 27.0.0: Firebase through SPM only	RNFB CHANGELOG (opens in a new window)
November 1 to 7, 2026	Read-only dry run: "I will trigger a test run, giving automation a chance to break early"	blog.cocoapods.org (opens in a new window)
December 2, 2026	"I will switch trunk to not accept new Podspecs permanently"; the CocoaPods/Specs repo is then to be archived on GitHub	blog.cocoapods.org (opens in a new window)

Three notes on this calendar.

The dates can still move. The post says "These dates are not set in stone", and the author adds that he is not inclined to move the deadline forward but that there is room to push it back. As of October 26, 2026, the blog's source repo (opens in a new window) shows no change to the timeline since May 2025, and the only newer post is a security note from February 18, 2026 (opens in a new window).

The CocoaPods/Specs (opens in a new window) repo is not archived yet: it was still receiving pushes on October 26, 2026.

The banner on cocoapods.org shows a rounded countdown ("2 months to go" on October 26, 2026). Use the dates from the post.

What keeps working, what stops

The mechanism CocoaPods describes is narrow: any new podspec submission "will always be denied at the server level". Nothing else is cut. The post adds that infrastructure "like the Specs repo and the CDN would still operate as long as GitHub and jsDelivr continue to exist", and concludes: "This will keep all existing builds working."

Operation	After December 2, 2026	Basis
pod trunk push of a new pod or new version to the public trunk	Refused server-side	CocoaPods post (opens in a new window)
pod install resolving versions already on trunk, through the CDN	Keeps working as long as GitHub and jsDelivr exist	CocoaPods post (opens in a new window)
pod install --repo-update, pod repo update	Should succeed and bring nothing new from trunk, since the Specs repo is frozen. CocoaPods does not state this explicitly	Inference
Private spec repos (source 'https://…/my-specs.git'), pod repo push	Unaffected: "This shouldn't affect people who use CocoaPods with their own specs repos"	CocoaPods post (opens in a new window)
Local podspecs through :path, which is what React Native autolinking does from node_modules	Unaffected: the post cites dependencies that are "vendored (e.g. they all come from npm.)"	CocoaPods post (opens in a new window)
Source download of an existing trunk pod (:git, :http hosted by the vendor)	Not guaranteed by CocoaPods: trunk hosts specs, not code. Availability depends on each vendor	Inference
Security fixes for a native SDK distributed through trunk	No longer reach CocoaPods users: "you're not getting any more updates to dependencies which come though CocoaPods trunk" (the typo is in the original)	CocoaPods post (opens in a new window)

The CDN has been the default source since CocoaPods 1.8 (opens in a new window) in August 2019: "CocoaPods 1.8 switches the CDN as the default spec repo source". A Podfile with no source line already uses it.

The CocoaPods client itself is still maintained, slowly. 1.17.0 (opens in a new window) came out on July 6, 2026. That pace is a second source of risk, independent of trunk; see the Xcode 27 section below.

Where React Native stands

Discussion #587 (opens in a new window), opened January 24, 2023, is still open. The formal proposal, Christian Falch's RFC0994 (opens in a new window), was opened April 21, 2026 and is not merged. Its latest revision, dated October 12, 2026, ends with "Aligned with React Native main; no deprecation date".

Release by release:

Version	Date	What changes	Status
0.75	August 2024	The spm_dependency helper lets a library podspec declare a SwiftPM dependency (PR #44627 (opens in a new window), merged June 25, 2024)	Shipped, CocoaPods path
0.81	August 12, 2025	Experimental precompiled iOS builds (opens in a new window), opt-in through RCT_USE_RN_DEP=1 RCT_USE_PREBUILT_RNCORE=1, still integrated by CocoaPods	Shipped, experimental
0.84	February 11, 2026	"React Native 0.84 now ships precompiled binaries on iOS by default", downloaded during pod install; opt out with RCT_USE_PREBUILT_RNCORE=0 (0.84 post (opens in a new window))	Shipped, default, through CocoaPods
0.87	August 11, 2026	"experimental support for Swift Package Manager as an alternative to CocoaPods on iOS. It is opt-in and additive; CocoaPods remains the default and the supported path" (0.87 post (opens in a new window))	Shipped, experimental
0.88	October 15, 2026 (post on the 19th)	"Swift Package Manager support remains experimental and opt-in in React Native 0.88, while CocoaPods remains fully supported" (0.88 post (opens in a new window))	Shipped, experimental
0.89	Not released	"Target Swift Package Manager as the default, with an opt-out to CocoaPods for apps that are still blocked"; "We plan to remove CocoaPods support in a later release of React Native" (0.88 post (opens in a new window))	Stated plan, no date

Two common mix-ups are worth clearing up.

Precompiled does not mean SPM. React Native's XCFrameworks have been the default since 0.84, and CocoaPods integrates them. The 0.87 SwiftPM path "consumes the same prebuilt XCFrameworks React Native already publishes": it is a second integration pipeline, not a new binary format.

spm_dependency does not make a library "SPM-native". It is a CocoaPods-side bridge: the pod stays a pod, and the SwiftPM dependency is attached to its target in the Pods project. PR #44627 (opens in a new window) states that it "only works USE_FRAMEWORKS=dynamic pod install" and that otherwise "the linker fails", because of the -ObjC flag and duplicate symbols. A bug in embedding transitive dynamic frameworks, which crashed the app at launch with Library not loaded: @rpath/..., was fixed by PR #58781 (opens in a new window) on October 1, 2026 on main. The fix is not in 0.88.0.

What npx react-native spm actually does, per the 0.87 post (opens in a new window) and the RFC:

• the command injects Swift package references into the existing .xcodeproj instead of replacing it; signing, capabilities and build phases stay untouched, and npx react-native spm deinit removes that injection (after --deintegrate, restore the Podfile from git and run pod install to return to CocoaPods);
• three local packages are referenced: ReactNative (prebuilt XCFrameworks), React-GeneratedCode (codegen) and Autolinked (generated at build/generated/autolinking/Package.swift);
• a library must ship a Package.swift, at its root or in ios/; otherwise npx react-native spm scaffold generates one from the podspec;
• after a fresh clone, and in CI, you run npx react-native spm once before building, "the analog of pod install";
• "The commands, flags, and generated layout may change in later releases. Do not use it in production yet."

0.88 hardened that tooling (full list (opens in a new window)): the minimum iOS version is read from the app's deployment target instead of a hardcoded iOS 15, a library's SwiftPM settings go in the swiftpmConfig section of its package.json (the equivalent block in react-native.config.js is deprecated), the scaffolder takes the name from the podspec, and prebuilt artifacts download from the React Native Maven mirror first.

One design detail worth knowing before you talk to your crash-reporting vendor: the runtime binaries (React.framework, hermes-engine, ReactNativeDependencies, in debug and release flavors) are linked through Xcode build settings, not as SwiftPM binaryTargets, because, per the RFC, "SwiftPM binary targets cannot vary by build configuration". The RFC also lists dSYM distribution for Sentry and Crashlytics among its unresolved questions.

Where Expo stands

Expo is on the same road, with an intermediate step already in production.

SDK 56 (opens in a new window), May 21, 2026: "SDK 56 ships prebuilt XCFrameworks for our most complex Expo modules on iOS", on by default, measured at about one minute (16%) off median clean iOS builds. Opt out with EXPO_USE_PRECOMPILED_MODULES=0. CocoaPods consumes those XCFrameworks.

On June 11, 2026, Christian Falch wrote on the Expo blog (opens in a new window) that "Expo, React Native, and most React Native libraries currently rely heavily on CocoaPods", that CocoaPods "will be deprecated eventually and will become read-only in December 2026", and that "This transition will take time".

SDK 58 (opens in a new window), October 15, 2026, moves to React Native 0.88. The changelog is explicit: "SDK 58 lays the groundwork for Expo apps to use it. Expo's iOS sources have been restructured so their Swift, Objective-C, and C++ compile as separate SwiftPM targets […], and an Expo autolinking plugin for React Native's npx react-native spm pipeline is available as a preview (#49823). CocoaPods remains the default and supported path, and precompiled Expo modules keep working there." PR #49823 (opens in a new window) was merged on September 16, 2026. The changelog gives no Expo-specific procedure to enable the preview; it points to the React Native 0.87 post.

For an Expo app on SDK 58, the supported path is therefore still npx expo prebuild followed by pod install. Work continues on the Expo side (for instance PRs #51661 (opens in a new window) and #51588 (opens in a new window), merged, and #52077 (opens in a new window), open), but nothing indicates a default switch in SDK 58.

EAS Build support for the SPM path was not verified for this guide.

The real exposure: third-party native SDKs

In a React Native 0.88 project, React Native's own pods no longer depend on trunk. The RNTester Podfile.lock (opens in a new window) at 0.88.0 lists a single pod under SPEC REPOS: trunk:, OCMock, a test dependency. boost, DoubleConversion, fmt, glog, RCT-Folly and SocketRocket come from local facades under build/rndeps-facades/, and hermes-engine and ReactNativeDependencies from local podspecs. It is reasonable to infer that a typical 0.88 app is in the same position for its React Native part; check it on your own lock.

What does depend on trunk is the third-party native SDKs your React Native libraries pull in through s.dependency. And several vendors have already stopped publishing to CocoaPods, ahead of December 2.

Dependency	State as of October 26, 2026	Source
Firebase Apple SDK	13.0.0 (October 7, 2026): "Firebase 13.0.0 and later releases are distributed exclusively through Swift Package Manager and binary distributions." 12.19.0 (September 9, 2026) is "the final scheduled release published to CocoaPods". 12.19.3 (October 22, 2026) is a Firestore security fix "for apps using Firebase 12, including projects that depend on CocoaPods".	Release notes (opens in a new window)
Firebase migration guide	"Firebase 12 is the final major version published to CocoaPods". Existing versions remain available; Firebase provides no support for installing directly from the podspec. The page does not mention React Native.	cocoapods-deprecation (opens in a new window)
react-native-firebase	26.1.0 (August 3, 2026) adds SPM resolution alongside CocoaPods. 27.0.0 (October 19, 2026), breaking: "ios: drop CocoaPods Firebase matrix; SPM-only". The RNFB package itself still installs through CocoaPods; only the Firebase SDK comes from SPM, through spm_dependency. Requirements: React Native 0.75 or newer, and use_frameworks! :linkage => :dynamic.	CHANGELOG (opens in a new window), ios-spm (opens in a new window)
Google Maps SDK for iOS	Note dated August 18, 2025: "CocoaPods is in maintenance mode as of 8/18/2025 and we won't release more versions of CocoaPods after Q2 2026. Use Swift Package Manager instead." 11.0.0 (August 6, 2026): "CocoaPods is deprecated as of version 11.0.0." The last version on trunk is 10.15.0 (June 24, 2026).	Release notes (opens in a new window)
react-native-maps	Issue #5700 (opens in a new window), opened August 19, 2025, is still open. In June 2026 the maintainer said the project is waiting for React Native to settle its own migration spec. The 1.29.11 podspec (opens in a new window) detects Google Maps through $PODS_ROOT/GoogleMaps, a CocoaPods-specific path.	GitHub, unpkg
Sentry Cocoa	"CocoaPods is no longer a supported installation method for the Sentry Apple SDK. We no longer publish to CocoaPods after v9.19.1." Older versions remain available, and the 8.x line got one more trunk release, 8.58.4, on July 14, 2026. Sentry recommends SPM or the XCFramework from GitHub releases.	docs.sentry.io (opens in a new window)
@sentry/react-native	8.32.0 (October 22, 2026) ships a Package.swift at the root of the npm tarball. We only checked that the file is present, not how it behaves under npx react-native spm.	unpkg (opens in a new window)

Firebase shows the underlying technical tension. spm_dependency requires dynamic frameworks. Yet, per a Firebase maintainer in the #587 thread, "Anything that Firebase distributes as a binary is built for static linking". react-native-firebase 27 absorbs that constraint in its integration, and its documentation is blunt: "Do not use RNFB's SPM mode with use_frameworks! :linkage => :static". On an Expo project this goes through expo-build-properties with ios.useFrameworks: "dynamic", and by not passing disableSPM: true to the @react-native-firebase/app config plugin. A Podfile with no use_frameworks! line is static linkage, so it is incompatible. If your app is not on dynamic frameworks today, upgrading to RNFB 27 is a linkage change for the whole iOS project, not a version bump.

Audit your Podfile.lock

The Podfile.lock holds everything you need. Its SPEC REPOS section lists, per spec source, the pods resolved from a spec repo; its EXTERNAL SOURCES section lists the ones that come from a :path, a :git or a :podspec. On an Expo project, generate the native folder first with npx expo prebuild if you do not commit it.

List the pods resolved from a spec repo, grouped by source:

awk '/^SPEC REPOS:/{f=1;next} /^[A-Z]/{f=0} f' ios/Podfile.lock

On RNTester 0.88.0 the output is:

  trunk:
    - OCMock

Keep only trunk pods, one per line:

awk '/^SPEC REPOS:/{f=1;next} /^[A-Z]/{f=0}
     f && /^  [^ ]/{src=$1}
     f && /^    - / && (src=="trunk:" || src ~ /CocoaPods\/Specs/){print $2}' ios/Podfile.lock

Count the pods linked from a local podspec, which covers the React Native and Expo libraries in node_modules:

awk '/^EXTERNAL SOURCES:/{f=1;next} /^[A-Z]/{f=0} f' ios/Podfile.lock | grep -cE ':path|:podspec'

An entry listed under https://github.com/CocoaPods/Specs.git instead of trunk: is the same public repo, reached through Git: the awk above counts it. Any other URL is a private or custom spec repo, which the plan does not affect.

Then, for each pod listed under trunk::

1. Identify the vendor and check whether it has already stopped publishing to CocoaPods (Firebase from 13, Google Maps from 11, Sentry after 9.19.1 on the 9.x line). The version in your lock stays installable; the next one is what will not arrive.
2. Check whether the vendor offers a SwiftPM package, and whether the React Native wrapper you use can consume it through spm_dependency, as react-native-firebase 27 does.
3. Check the linkage constraint: spm_dependency requires use_frameworks! :linkage => :dynamic.
4. Find any internal SDK your company publishes itself with pod trunk push. This is the one case where December 2 actually blocks a workflow: those specs must move to a private spec repo or to SPM before that date, and the automation should expect refusals during the November 1 to 7 test week.

A grep over your CI finds that last case quickly:

grep -rn "pod trunk push\|pod trunk register" .github fastlane bitrise.yml 2>/dev/null

For library authors

RFC0994 (opens in a new window) asks authors to "Continue supporting podspec during the transition period". For a library published on npm, the target is therefore to ship both: a podspec that works today, and a Package.swift for the experimental path.

Consuming an SPM-only SDK from a podspec (CocoaPods path, React Native 0.75 and newer):

spm_dependency(s,
  url: 'https://github.com/apple/swift-atomics.git',
  requirement: {kind: 'upToNextMajorVersion', minimumVersion: '1.1.0'},
  products: ['Atomics']
)

That is the example from PR #44627 (opens in a new window). The signature in react_native_pods.rb (opens in a new window) at 0.88.0 is spm_dependency(spec, url:, requirement:, products:). The limits again: dynamic frameworks are mandatory, and the transitive framework embedding fix (#58781 (opens in a new window)) is only on main.

Preparing the SwiftPM path (React Native 0.87 and newer, experimental):

• ship a Package.swift at the root of the npm package or in ios/; it is detected automatically;
• declare the configuration in package.json, under swiftpmConfig (name, dependencies, autolinkingPlugin, scaffold), since the react-native.config.js block is deprecated as of 0.88;
• declare native dependencies on other React Native libraries explicitly in swiftpmConfig.dependencies, because, per the RFC, "SwiftPM has no equivalent of a podspec's s.dependency";
• do not rely on swiftpmConfig.xcframework or swiftpmConfig.source: the RFC says "The current prototype does not yet implement" those fields. The npx react-native-prebuild CLI for libraries is a proposal.

State of common libraries, checked on the npm tarball through unpkg on October 26, 2026. We verified that the file is present, not that it builds under npx react-native spm.

Package	Version	Package.swift in the tarball
react-native-reanimated	4.7.1 (opens in a new window)	Yes, root
react-native-worklets	0.13.0 (opens in a new window)	Yes, root
react-native-gesture-handler	3.4.0 (opens in a new window)	Yes, root
react-native-safe-area-context	5.10.1 (opens in a new window)	Yes, root
@sentry/react-native	8.32.0 (opens in a new window)	Yes, root
react-native-screens	4.30.0	Not in the tarball; present on the GitHub main branch
@react-native-firebase/app	27.1.0 (opens in a new window)	ios/RNFBFirebase/Package.swift, annotated "CI probe only"; the shipped podspecs keep spm_dependency
react-native-svg, async-storage, react-native-maps, react-native-mmkv, flash-list, stripe-react-native, react-native-purchases, react-native-vision-camera	default branch	No non-example Package.swift found in the repo tree (listing-based check, not exhaustive)

On the tooling side, create-react-native-library (opens in a new window) has a PR open since October 5, 2026 that adds an --experimental-spm flag generating a Package.swift for Turbo Modules and Fabric views, targeting 0.87's SPM support. It is not merged. For Nitro Modules (opens in a new window), we found no shipped SwiftPM package for react-native-nitro-modules; in June 2025 its author cited SwiftPM's limits on Swift-from-C++ interop as a blocker, and the technical question has not been settled publicly.

Test before it bites

The read-only switch itself cannot be tested locally, but its side effects can.

A "clean install" CI job on a fresh runner, with no cache, which reproduces what a new developer or an ephemeral runner will do after December 2:

rm -rf ~/Library/Caches/CocoaPods ~/Library/Caches/ReactNative ios/Pods
pod cache clean --all
cd ios && bundle exec pod install --repo-update

~/Library/Caches/ReactNative is the cache React Native uses for prebuilt tarballs. Follow with a release archive and the dSYM upload to your crash reporter, since the RFC lists dSYM distribution as an open question on the SPM side.

An SPM trial on a throwaway branch, from React Native 0.87:

cd ios
npx react-native spm --deintegrate   # removes CocoaPods from the project
# build in Xcode or with xcodebuild
npx react-native spm deinit          # removes the SPM injection only
git checkout -- Podfile && bundle exec pod install   # back to CocoaPods

You will quickly see which libraries have no Package.swift. npx react-native spm scaffold generates one into node_modules, to persist with patch-package. On Expo SDK 58 the autolinking plugin is a preview with no documented procedure in the changelog; treat the trial as exploratory.

Xcode 27, finally. CocoaPods issue #12927 (opens in a new window), opened September 24, 2026, reports that a project created from the default Xcode 27.0 template has objectVersion = 110 and that pod install fails with "Unable to find compatibility version string for object version 110". As of October 26, 2026 the issue is open with no maintainer reply, and the Xcodeproj releases (opens in a new window) list shows nothing after 1.28.1 from July 6, 2026. We did not verify whether Xcode 27 rewrites the objectVersion of an existing React Native project. If you move to Xcode 27, check that value in ios/*.xcodeproj/project.pbxproj before blaming trunk.

What we recommend

In order.

1. Read the SPEC REPOS section of every Podfile.lock in the organization and extract the list of trunk: pods.
2. For each pod on that list, note the vendor, the last version published to CocoaPods, and whether the React Native wrapper has an SPM path.
3. Before November 1, 2026, move any internal spec published with pod trunk push to a private spec repo, and adjust the automation.
4. Set up the "clean install" CI job described above, and keep it.
5. Treat Firebase, Google Maps and Sentry as migrations in their own right, with the dynamic-linkage question settled before the version bump.
6. Stay on CocoaPods in production for React Native 0.87 and 0.88 and Expo SDK 58, as both teams say.
7. Run the npx react-native spm trial on a branch, list the libraries without a Package.swift, and open or follow the corresponding issues.
8. For internal libraries, ship Package.swift and swiftpmConfig alongside the podspec, and declare inter-library dependencies.
9. Reassess when React Native 0.89 ships, and at each revision of RFC0994.

The collective can run this audit if you would rather hand it off.

What we do not know yet

• Whether CocoaPods sent the second email planned for September-October 2026, and whether the November 1 to 7 test is still scheduled. No official post after February 2026 confirms it.
• What the test does exactly: full refusal for the week, or intermittent. The post does not say.
• The actual date CocoaPods/Specs gets archived.
• The React Native 0.89 release date, and whether "SPM by default" holds its schedule. RFC0994 is not merged and its latest revision says "no deprecation date".
• How npx react-native spm behaves in a project driven only by Expo CLI, beyond the preview plugin.
• EAS Build support for the SPM path.
• The SPM roadmap for Nitro Modules.
• Whether the Package.swift files in reanimated, gesture-handler, safe-area-context and Sentry target React Native's spm pipeline or another use.
• The end of CocoaPods support for reCAPTCHA Enterprise. A Google maintainer announced it in the #587 thread for 18.9.0; we did not find it on a vendor page.
• Whether Xcode 27 moves existing projects to objectVersion = 110.

This guide will be updated as these points get settled. The last revision date is at the top of the page.

Sources

• CocoaPods Trunk Read-only Plan (opens in a new window), November 30, 2024, updated May 2025
• CocoaPods Support & Maintenance Plans (opens in a new window), August 13, 2024
• CocoaPods Trunk: Minor security updates (opens in a new window), February 18, 2026
• CocoaPods 1.8 Beta (opens in a new window), August 5, 2019
• CocoaPods 1.17.0 (opens in a new window), July 6, 2026
• CocoaPods issue #12927 (opens in a new window), September 24, 2026
• React Native 0.81 (opens in a new window), 0.84 (opens in a new window), 0.87 (opens in a new window), 0.88 (opens in a new window)
• RFC0994 (opens in a new window) and discussion #587 (opens in a new window)
• PR #44627 (opens in a new window), PR #58781 (opens in a new window), RNTester Podfile.lock at 0.88.0 (opens in a new window)
• Expo SDK 56 (opens in a new window), SDK 58 (opens in a new window), Faster iOS Builds with Precompiled XCFrameworks (opens in a new window), PR expo/expo #49823 (opens in a new window)
• Firebase Apple SDK release notes (opens in a new window), Firebase CocoaPods deprecation (opens in a new window)
• react-native-firebase CHANGELOG (opens in a new window), rnfirebase.io/ios-spm (opens in a new window)
• Google Maps SDK for iOS release notes (opens in a new window), react-native-maps #5700 (opens in a new window)
• Sentry Apple SDK, CocoaPods (opens in a new window)
• react-native-builder-bob PR #955 (opens in a new window)