A Flow does not cross to Swift. A callback does.
Exporting a Flow hands Swift something it has no way to collect.
coroutines
12 posts
Dispatchers.IO is not in commonMain, and the reason matters
A browser has no thread pool to offload to.
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.
runTest skips your delays, which is why the flaky test passed
Virtual time makes a 30-second timeout instant — and makes a real-dispatcher leak invisible.
shareIn's replay count is a product decision, not a tuning knob
replay = 1 re-delivers the last value to every new collector.
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.
The coroutine that kept collecting after the screen was gone
Android cancels viewModelScope for you and SwiftUI does not. One scope, two lifetimes, and only one of them has a callback that fires when the screen ends.
Dispatchers.Main throws on a target you forgot to configure
Main is supplied by a platform integration, so it exists on Android and iOS and fails at runtime on desktop tests — a crash whose message names a module, not a mistake.
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.
Wasm has no threads, and that decides your dispatcher
Dispatchers.Default is a single thread in the browser. Code that was merely slow on Android becomes a frozen tab.
Your composable ran four times. So did your network call.
A network call written directly in a composable fires an unpredictable number of times. LaunchedEffect, DisposableEffect and SideEffect each define a different notion of when work should happen.