Wrapping a Swift Package in a Gradle Module: How RevenueCat's KMP SDK Builds purchases-ios Without CocoaPods

RevenueCat’s Kotlin Multiplatform SDK replaced its CocoaPods-based iOS integration in version 3.0.0 with custom Gradle logic that builds Swift Package Manager targets from source and packages their Objective-C-compatible interfaces and static archives into Kotlin/Native klibs. Because Kotlin/Native cinterop requires Objective-C headers, Clang modules, and linkable libraries rather than Swift source, the implementation uses SwiftPM’s JSON package description, invokes `swift build` per Apple target, emits Objective-C headers, creates static archives with `libtool`, and generates module maps and `.def` files for cinterop. A source hash embedded in each `.def` file forces cinterop to rerun when Swift code changes, preventing stale Swift archives or bindings from being retained in cached klibs. Nearly empty facade modules such as `kn-core` then publish the generated bindings and compiled Swift code so client applications need only a Gradle dependency rather than CocoaPods or Xcode configuration. The system also handles release-build behavior, fixed toolchain versions, Swift resources through Compose Resources, dependencies and duplicated bindings across separate Swift targets, and Swift shims for APIs that cinterop cannot represent directly, illustrating both the flexibility and maintenance costs of integrating Swift packages into Kotlin Multiplatform before official SwiftPM import support matures.

No tracked trend matches for this post yet.

Use this post, company, and trend context to find content marketing opportunities, perform competitive analysis, or address product feature gaps via the Plushcap MCP server or the Plushcap API.