annoying • C interop is sometimes a pain (JNI, Swift/C++ interop is new) • C interop is sometimes not as free as you think (Java Native Interface) • Misses advantages of virtual machines with JIT (like the Android Runtime) • Can bloat binary size unnecessarily • Misses JIT-level optimizations (especially pro fi le guided optimizations)
incorporating msbuild • Slow, generational stop-the-world GC • Misses advantages of platform-native virtual machines • ART pro fi le-guided optimizations • LLVM JIT negatively impacts startup performance, which is already bad
<> (n:kotlin.Int) returnType:kotlin.Int VALUE_PARAMETER name:n index:0 type:kotlin.Int BLOCK_BODY RETURN type=kotlin.Nothing from='public fi nal fun square (n: kotlin.Int): kotlin.Int declared in <root>' CALL 'public fi nal fun times (other: kotlin.Int): kotlin.Int [operator] declared in kotlin.Int' type=kotlin.Int $this: GET_VAR 'n: kotlin.Int declared in <root>.square' type=kotlin.Int origin=null other: GET_VAR 'n: kotlin.Int declared in <root>.square' type=kotlin.Int origin=null fun square(n: Int): Int { return n * n }
& actual • Glue for platform-native libraries • Application • Kotlin all the way down (Compose Multiplatform) • Library • For Kotlin Multiplatform • For platform targets (XCFramework, Android Archive, NPM Package) How What Lots of Options
• And a weird one (cashapp/ Redwood) • Kotlin/kotlinx.serialization • Kotlin/kotlinx-datetime • Kotlin/kotlinx-io • Kotlin/kotlinx.collections.immutable Some Good First Party Libraries
- so Kotlin common is missing String.format. • Building JS-native NPM packages is onerous. • Sometimes you want (or need) API boundaries to be di ff erent between platform targets. Doable but a little awkward. • Pure Swift dependencies aren’t supported for Apple targets.