Building the Architecture in KMP: Data Flow, MVI, and Hard Decisions

Part 2 — Architecture, MVI, and the Offline-First Decision In Part 1 I wrote about the stack and the first walls — library compatibility, Navigation3 bugs, Coil 3 differences. Now we get into the decisions that shaped how the whole app is structured. Fair warning: this post has opinions. Architecture is one of those topics where everyone has a preferred approach, and mine was shaped by years of Android development followed by three years of Flutter. Your mileage may vary. The Overall Structure I'm following a simplified Clean Architecture. Not strict by the book, but principled enough that I can navigate the codebase without thinking too hard about where things live: data/ remote/ model/ ← DTOs — what the API returns service/ ← Ktor clients (WordPress, Spotify) mapper/ ← DTO → Entity, Entity → Domain repository/ ← PostRepository — single source of truth domain/ model/ ← PostDetail, PostSummary, ContentPart ui/ screens/ ← ViewModels + Composables components/ ← Shared UI components navig