PeopleInSpace

john-oreilly‘s Kotlin Multiplatform sample app, Apache-2.0, ~3.4k★, 310 forks, and cited in JetBrains’ official KMP docs and Google’s Dev Library. Its own one-line description: “Kotlin Multiplatform project with SwiftUI, Jetpack Compose, Compose for Wear, Compose for Desktop, and Compose for Web clients along with Ktor backend.”

It shows who’s aboard the ISS and where the station is. The app is trivial on purpose — the point is the wiring, and the wiring is the source.

Six clients, one shared core

• Android — Jetpack Compose
• iOS — SwiftUI, not Compose
• Wear OS — Compose for Wear OS
• Desktop — Compose for Desktop
• Web — Compose for Web on Kotlin/Wasm
• JVM — a Ktor backend, plus an MCP server module

Shared across all of them: Ktor client, SQLDelight for local storage, Koin (annotation-based) for DI, coroutines, kotlinx.serialization. Around the edges: Coil, Kermit, SKIE for Swift interop, Maestro for UI tests. Data comes from The Space Devs and Open Notify APIs through the project’s own Ktor service rather than direct from the clients.

Why it matters here

The iOS client is the interesting one. Every other surface uses Compose Multiplatform; iOS gets hand-written SwiftUI over the same shared Kotlin. So a single repo demonstrates both answers to the question this spoke keeps asking: share the UI too, or share only what’s underneath and write the interface natively per platform. The project doesn’t argue for one — it ships both in parallel, which is a stronger statement than an argument.

Read as evidence it’s a demo, not a deployment: nothing here reports what either strategy costs at app scale. It’s an existence proof of the architecture and a canonical one (the docs cite it), not a performance or maintenance claim.

Related

compose-multiplatform · ui-framework · flutter · john-oreilly