KMP Gets Alpha SwiftPM Support — Here's the CocoaPods Migration Path
Teams maintaining KMP shared modules for iOS have been locked into CocoaPods for years. Alpha SwiftPM support removes a friction point that made KMP feel like a second-class citizen in Xcode-native workflows, though the inability to export as a Swift package means the shared module still can't be distributed the way pure-Swift libraries are.
The migration path keeps CocoaPods and SwiftPM dependencies coexisting in the same Gradle file until compilation succeeds, then removes the old pod declarations. JetBrains ships a Junie AI Skill that automates parts of the migration, though the generated changes still need manual review against the Git diff.
Two hard boundaries apply: KMP modules that consume SwiftPM dependencies cannot themselves be exported as Swift packages, and dynamic Kotlin/Native frameworks often need to switch to static linking to avoid symbol conflicts. Platform constraints also matter — a Swift package like Google Maps that only supports iOS must be scoped to iOS targets when the project also builds for macOS.
For Firebase and other SDKs where the Clang module name differs from the Swift product name, `discoverClangModulesImplicitly` must be set to false and the correct module names listed explicitly in `importedClangModules`.
JetBrains is using its own AI tooling to smooth a migration that would otherwise be tedious and error-prone, which is a pragmatic dogfooding move — but the explicit warning not to trust the AI output keeps expectations grounded.
The coexistence strategy of running both package managers side-by-side during migration is the only safe path, because a clean cutover would leave no fallback when imports break at the Kotlin/Native linking stage.
Not being able to export a SwiftPM-consuming KMP module as a Swift package is a significant distribution gap. It means iOS teams consuming a shared KMP module still need the Gradle build, which undercuts the promise of fitting into a pure-Swift ecosystem.