React Native: When Will Swift Package Manager Support Be Ready?

If you ship iOS apps with React Native today, your dependency workflow is still mostly driven by CocoaPods. That raises a recurring question for teams standardizing their native stack around Swift Package Manager: when will React Native support be ready in a real production sense?

The short answer is that SPM support is improving, but ready depends less on a single release date and more on whether your app's native surface area can run without Pod-specific assumptions.

What ready actually means

1 Core artifacts integrate cleanly

React Native iOS artifacts should be consumable without CocoaPods glue scripts.

2 Module ecosystem is stable

Critical third-party native modules should publish and test SPM manifests.

3 Build and CI remain deterministic

Codegen, archive, and release workflows should run reproducibly with SPM-first pipelines.

So the target is not that SPM can build a sample app. The target is that your production app builds, tests, archives, and upgrades reliably.

Why CocoaPods still shows up

React Native has deep iOS integration points, including generated native code, Hermes and mixed-language dependencies, and target-specific build configuration. Historically, CocoaPods has wired those pieces together.

Typical Podfile integration

      platform :ios, '15.0'

target 'MyApp' do
  config = use_native_modules!

  use_react_native!(
    :path => config[:reactNativePath],
    :hermes_enabled => true,
    :fabric_enabled => true
  )
end
    

In practice, this file is not only dependency metadata. It is also an integration entrypoint, which is why full replacement can take time.

What partial SPM adoption looks like

A practical pattern is hybrid adoption: keep React Native core and Pod-locked modules on CocoaPods, while moving independent Swift packages to SPM first.

SPM dependency example

      .package(url: "https://github.com/pointfreeco/swift-dependencies", from: "1.9.0")
    

This does not replace React Native integration by itself, but it reduces the surface area that Pods must handle.

What module authors need to ship

For React Native module maintainers, SPM readiness usually means shipping a valid Package.swift, declaring platform minimums, and removing Pod-only post-install assumptions.

Simplified Package.swift

      import PackageDescription

let package = Package(
  name: "RNAnalyticsKit",
  platforms: [.iOS(.v15)],
  products: [
    .library(name: "RNAnalyticsKit", targets: ["RNAnalyticsKit"])
  ],
  targets: [
    .target(
      name: "RNAnalyticsKit",
      path: "ios/Sources",
      publicHeadersPath: "include"
    )
  ]
)
    

Readiness checklist for app teams

Area	Ready signal
React Native core	Your RN version can be integrated without Pod-only steps in official workflows.
Native modules	All required iOS modules publish tested SPM support.
Codegen and build	Local and CI builds run without hidden Pod post-install assumptions.
Release engineering	Archive, symbols, and crash reporting pipelines remain stable.
Rollback plan	You can restore Pod-based integration in one release if needed.

Prepare now, migrate later

Reduce native sprawl Track which dependencies are Pod-locked and prioritize alternatives.

Prefer explicit CI steps Make package resolution and build inputs reproducible across environments.

Pilot with a hybrid model Move low-risk dependencies first and keep rollback options available.

Separate integration layers Isolate custom native glue so package manager changes stay localized.

CI package resolution command

      xcodebuild -resolvePackageDependencies \
  -workspace ios/MyApp.xcworkspace \
  -scheme MyApp
    

Bottom line

SPM support for React Native is ready for selective adoption now, and production-ready for your app when your required module ecosystem is SPM-complete.

Teams that plan this as an engineering maturity curve, not a one-day switch, usually migrate with fewer release surprises and better long-term upgrade velocity.

React Native:When Will Swift Package Manager Support Be Ready?