expect/actual is not an interface, and the difference shows up at link time
An interface is resolved at runtime by an instance. expect/actual is resolved at compile time by the source set.
Engineering
Compose, Kotlin, and multiplatform work — the mechanism under the symptom.
296 posts
The iOS framework you export is an API, and nobody reviews it
Every public declaration in the shared module becomes Swift API. internal is the design tool.
Your shared database needs a driver per platform, and that is the easy half
The driver is a one-line expect/actual. Threading, file location, and the OS deleting your file are the rest of it.
A DI module that compiles on every target and only works on one
Registration is common. The bindings are not. DI defers the error to first use, which is usually on a user's device.
Your Kotlin class becomes an Objective-C class, which is why the name is wrong
Obj-C has no namespaces. Everything exported is prefixed and flattened, and each Kotlin idiom loses something specific.
Kotlin/Native memory is not the JVM's, and a retain cycle crosses the bridge
Kotlin objects held by Swift are ARC-counted. A loop through both runtimes is invisible to both profilers.
One Gradle build, five outputs, and the cache that only helps three
Android and JVM targets cache well. Native link steps mostly do not, and that asymmetry is where your CI time goes.
One Ktor client, four engines, and the timeouts that don't mean the same thing
You configure one connect timeout. OkHttp, NSURLSession and the browser each enforce a different thing with it.
A platform bridge is an interface with a lifetime problem
Permissions, biometrics and share sheets all need something shared code does not have: a host that outlives the call.
kotlinx.serialization is compile-time, which is why your polymorphism fails at runtime
No reflection on Native, so the serializer is generated. Sealed hierarchies work; open polymorphism needs a module you register by hand.
Your suspend function becomes a callback in Swift, and cancellation does not survive
Swift cancels its Task. The Kotlin Job never hears about it, so the work keeps running.
The third time this filled up, I diagnosed it as an outage
A consumable with no recorded lifetime is indistinguishable from a service that is down.