kotlin-flows

Use StateFlow for UI state that new collectors need immediately, Channel(BUFFERED).receiveAsFlow() for single-consumer fire-once events like navigation and snackbars, and SharedFlow only for multi-collector broadcasts where missed events are acceptable. Plain Flow suits one-off cold data streams.

Use callbackFlow with trySend for emissions and always include awaitClose to unregister the listener, otherwise the callback leaks. For single-value callbacks, prefer suspendCancellableCoroutine so cancellation propagates to the underlying call.

Channel(Channel.BUFFERED).receiveAsFlow() is the default for single-consumer events because send suspends until consumed, so events are never dropped. SharedFlow with replay = 0 silently drops emissions when no collector is active, such as during configuration changes.

A broad catch (e: Exception) inside collect or a suspend function swallows CancellationException, breaking structured concurrency. Catch only specific exception types, rethrow CancellationException explicitly, or use the Flow catch operator which skips it automatically.

No. Exposing MutableStateFlow lets external callers mutate state and bypass ViewModel logic. Keep the mutable instance private and expose an immutable StateFlow, updating it with the atomic update { } function rather than non-atomic value reads and writes.

Yes. Expose Flow from shared KMP code and collect it on iOS using SKIE or manual collection wrapped in a CoroutineScope. Avoid accessing StateFlow.value directly from non-coroutine iOS contexts; use collection wrappers instead.