A shared ViewModel has no lifecycle, so you have to give it one
androidx.lifecycle.ViewModel is Android's. The shared class needs an explicit clear() and two platforms that call it.
architecture
70 posts
A Flow is cold, and that is why your ViewModel fires three network calls
Each collector re-runs the producer. Two UI observers plus a test is three executions.
There is no Logcat in commonMain, and println is not a logger
Five targets, five sinks, and one of them discards your output silently.
Source sets are a graph, and iosMain is not where you think it is
The default hierarchy creates intermediate source sets you never declared.
StateFlow drops what you needed and keeps what you didn't
Conflation turns two identical emissions into one, so a repeated event vanishes.
One failed child cancelled the whole screen, and the scope was the reason
Structured concurrency propagates failure upward by design. SupervisorJob is how you declare independence.
commonTest runs on every target, which is the point and the cost
One test, five executions. That is how you find platform bugs — and how one flaky test fails five jobs.
kotlinx-datetime has no Calendar, and the timezone database ships per platform
Instant is unambiguous. LocalDateTime is not. The same arithmetic can disagree across targets.
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.
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.