Dependencies and Kotlin/Native
summary
Kotlin/Native forces you to reconcile JVM artifacts and real native binaries: Gradle/Kotlin produce IR (klib) then a second compile+link step that emits architecture‑specific object code, and C interop generates headers-to-klib bindings. Using CocoaPods and Swift Package Manager or Carthage yields either vendored frameworks or source that become static or dynamic libs, which leads to the common failure mode of duplicate global symbols and App Store‑time crashes. The practical fix is static vs dynamic linking — prefer static KMP frameworks or use autolinking/linker flags to avoid duplicated symbols — and treat native warnings as urgent errors.
AI-written summary · about
chapters (11)
- 0:00Dependencies and Kotlin/Native
- 2:09JVM vs native dependencies
- 5:00Compilation and linking
- 8:52Native symbols explained
- 13:31Static vs dynamic libraries
- 17:05Dynamic libraries in mobile
- 23:16Kotlin/Native compilation
- 28:03Static library problems
- 34:29System libraries in Kotlin/Native
- 35:53Warnings in native development
- 36:59Kotlin/Native dependency best practices
related talks
33mAdvanced Kotlin Native Integration
18mKotlin native
49mEffective Kotlin-Swift Interoperability
52mBuilding apps using Kotlin Native
30mReusable Cross-Platform Frameworks with Kotlin/Native
22mIntegrate Multiple Kotlin/Native Libraries into Your Android/iOS Apps, Vincent Nicolle Coyote System
52mKEYNOTE: Kotlin/Native – Embracing existing ecosystems
43mThe Triumphs and Tribulations of Kotlin-Native in Practice
