Publishing Native Artifacts from Kotlin Multiplatform Projects
Article Summary
Guillermo Mazzola from Glovo cracked a problem most teams avoid: using Kotlin Multiplatform without forcing everyone into a monorepo. His solution? Publishing native CocoaPods and NPM packages directly from KMP.
Most KMP implementations require all platforms to live in one repository with shared build chains. Glovo needed to share tracking event logic across iOS, Android, and web while keeping each platform's existing repos and workflows intact. Mazzola's team built custom Gradle plugins to publish native artifacts.
Key Takeaways
- Extended Gradle's publishing plugin to support CocoaPods and NPM repositories natively
- Created fat frameworks for iOS combining multiple architectures into single CocoaPod
- Bundled transitive dependencies into NPM packages to solve module resolution issues
- Kotlin Native's memory model forced thread safe collections and frozen objects everywhere
- Team ultimately stopped scaling due to maintenance complexity and breaking compiler changes
Glovo successfully shipped KMP libraries as native packages to avoid monorepo migration, but the custom tooling and platform quirks made long term maintenance unsustainable.
About This Article
When Glovo compiled Kotlin to JavaScript, function parameters got mangled unless developers explicitly named them with @JsName. This caused naming clashes in overloaded functions and broke integration for consumer apps.
Glovo required all parameterized functions in the public API to use @JsName annotations. It's a necessary tradeoff when using KMP's JavaScript compilation model.
The team published NPM packages with predictable function names. Web teams could integrate the tracking library without hitting runtime resolution errors or symbol collisions.