Swift Package Manager (SwiftPM)

Swift’s official package manager, built into Xcode, which React Native is adopting to replace CocoaPods (experimental in 0.87 and 0.88).

Updated October 26, 2026

Definition

Swift Package Manager (SwiftPM) is the official dependency manager and build system of the Swift language, built into Xcode. A package is described by a Package.swift manifest declaring its targets, its products (libraries), and its dependencies, and Xcode resolves the graph into a Package.resolved file. For React Native, it is the way out of CocoaPods: React Native 0.87 introduced experimental, opt-in support where the npx react-native spm command injects package references into the existing .xcodeproj and consumes the same prebuilt XCFrameworks core already publishes, with no Ruby, Bundler, or pod install. 0.88 hardened the tooling (minimum iOS version read from the deployment target, swiftpmConfig in package.json), and the team targets SwiftPM as the default in 0.89 with a CocoaPods opt-out, then CocoaPods removal in a later release. You meet it when an iOS library ships only through SwiftPM, or when preparing for the end of CocoaPods.

In a real app

Concretely, in 0.87 and 0.88 you opt in from ios/ with npx react-native spm --deintegrate, which removes CocoaPods and adds the packages; npx react-native spm deinit reverses it. After a fresh clone or in CI, npx react-native spm plays the role of pod install, but it does not need re-running on every dependency change: the project detects the change and re-runs autolinking. A library must ship a Package.swift; npx react-native spm scaffold generates one from the podspec for those that do not. The docs are explicit: do not use it in production yet, commands and generated layout may still change.

The visible change for library maintainers is the arrival of two header-only XCFrameworks, ReactNativeHeaders and ReactNativeDependenciesHeaders, and the import rule #import <React/RCTAppDelegate.h> instead of the bare form. A podspec relying on internal header paths needs a review. On the Expo side, SDK 58 split its iOS sources into SwiftPM targets and offers an autolinking plugin in preview, but CocoaPods remains the default, supported path.

For an app project, my recommendation in October 2026: stay on CocoaPods in production, try SwiftPM on a branch to list the libraries without a Package.swift, and report blockers on RFC #0994. The team targets 0.89 to make it the default; no production switch before that.

Sources

All 35 glossary terms

In a real app

Related terms

Sources

One of these is blocking your app?