PeopleInSpace: a Kotlin Multiplatform sample that ships eight clients from one shared module

The problem PeopleInSpace actually solves

Most Kotlin Multiplatform write-ups stop at a shared module and a single client. PeopleInSpace goes the other way: one shared module, six UI toolkits. The repository is a working demonstration that the same networking, persistence, dependency injection and view model code can drive SwiftUI on iOS, Jetpack Compose on Android, Compose for Wear OS, Compose for Desktop, Compose for Web compiled to Wasm, and a WinUI 3 application on Windows. The README also lists an Android Glance app widget, a Swift executable package, a plain JVM entry point (Main.kt in the common module), and an MCP server.

The audience is narrower than the feature list suggests. This is for engineers who already know they want Kotlin Multiplatform and want to see the seams: how a view model crosses into Swift, how a shared HTTP client is configured once, how SQLDelight is wired per platform. If you are evaluating whether to adopt KMP at all, the project answers a different question. It assumes the decision and demonstrates the consequences.

One shared module, six rendering targets

The module table in the README is the architecture. The common module holds the KMP code: Ktor for HTTP, SQLDelight for storage, Koin for dependency injection, view models, shared Compose Multiplatform UI, and the Windows NuGet API. Each client module then depends on it. The app module adds Jetpack Compose and the Glance widget, wearApp adds Compose for Wear OS, PeopleInSpaceSwiftUI is the SwiftUI client, compose-desktop and compose-web are the two Compose Multiplatform targets, and windows/WinUiApp is the WinUI 3 client.

Data flows from two external sources. People data (names, bios, images of people currently in space) comes from The Space Devs API. The ISS position comes from the Where the ISS at? API. Neither is called directly by the clients. Both are served through the project's own Ktor backend in the backend module, which the README says is deployable to Google App Engine. That extra hop is the interesting design decision: it gives every client one stable local endpoint instead of spreading two third-party APIs across six codebases. It also means the sample cannot run its clients against live data without the backend running first, which is a real constraint rather than a detail.

The mcp-server module reuses the same shared KMP code and exposes an MCP tools endpoint returning the list of people in space, built on the Kotlin MCP SDK. That is the clearest signal of where the project's author thinks shared Kotlin is heading: the same domain code, surfaced to an AI client instead of a screen.

Installing PeopleInSpace and getting a first response

The README states the requirements plainly: JDK 17, a recent Android Studio for the Android and Wear clients, and Xcode for iOS. There is no published package to install. You clone the repository and build with the Gradle wrapper. The Windows client is the exception, since its prerequisites and build, test and run steps are in windows/README.md rather than the top-level file.

The fastest way to confirm the toolchain works is the backend, because it has no UI dependency. From the repository root:

./gradlew :backend:run

The README says that after starting the server you should be able to open http://localhost:9090/astros_local.json in a browser. That JSON payload is the people data the clients consume. If the port is already taken or the response is empty, stop here: nothing downstream will work.

With the backend running, the desktop client is the next cheapest check, since it does not need an emulator or a simulator:

./gradlew :compose-desktop:run

For the shared module itself, the README gives a JVM test task, and a Maestro flow for the Android UI:

./gradlew :common:jvmTest
maestro test maestro/PeopleInSpace.flow

The web target compiles to Wasm and runs in a browser via a Gradle task named :compose-web:wasmJsBrowserDevelopmentRun. Android and Wear OS use :app:installDebug and :wearApp:installDebug respectively, or the run configurations in Android Studio. iOS is not a Gradle task: you open PeopleInSpaceSwiftUI in Xcode and run from there.

The backend hop is a trade-off, not a free win

Routing both upstream APIs through a self-hosted Ktor service buys consistency and costs a deployment. The README says the author has tested Google App Engine deployment using the shadowJar plugin to build an uber jar, then gcloud app deploy with the app.yaml under backend/src/jvmMain/appengine. The README adds that deploying the jar to other services should be possible, which is an untested claim, not a documented path.

What the README does not document is rollback, staging, health checks, rate limiting, or what happens when The Space Devs API changes shape. The backend is a sample service, and the repository treats it that way. If you fork this as the basis for anything real, the proxy layer is the part you will have to design yourself; the sample only shows that the proxy can exist and can be deployed one way.

The second limitation is scope. Every client here renders a small, read-mostly dataset: a list of people and a position. That is a favourable case for shared code. Screens with heavy platform-specific interaction, background work, or per-platform navigation stacks will exercise parts of KMP that this sample does not reach. Reading it as proof that a complex app shares cleanly would be a mistake.

Compose Multiplatform versus a native UI per platform

The real alternative is not another sample app. It is the choice between sharing UI with Compose Multiplatform and writing a native UI per platform over a shared Kotlin core. PeopleInSpace sits on both sides at once, which is why it is useful.

The iOS client is SwiftUI, not Compose Multiplatform. The Android client is Jetpack Compose, and the desktop and web clients are Compose Multiplatform. So the repository shows a shared core feeding a SwiftUI surface on one platform and a Compose surface on another, plus a WinUI 3 client on Windows. The README's related posts list includes entries on wrapping Kotlin Flow with a Swift Combine publisher, using Swift's async/await to call Kotlin, and using Swift packages in a KMP project, which is the material you would read if you take the SwiftUI route.

If you instead want one Compose UI everywhere, the compose-desktop and compose-web modules are the reference, and the README notes the web target is Kotlin/Wasm based. The difference in approach is concrete: SwiftUI means you maintain a second UI layer and bridge the shared state across the language boundary; Compose Multiplatform means you accept the Compose runtime on each target and get the same composables back. PeopleInSpace does not argue for either. It shows what each costs.

Maintenance, licence and what a fork owes you

The repository is not archived, and the last push was on 2026-09-06. That is recent enough that the code reflects current Kotlin and Compose Multiplatform practice; the README badge shows Kotlin 2.4.0. There are no retrieved releases, so there is no version to pin and no changelog to read. Upgrade cost therefore falls on you: you track the upstream Kotlin, Compose Multiplatform, Ktor and SQLDelight versions yourself, and renovate.json in the repository root suggests dependency updates are automated rather than hand-managed.

The licence is Apache-2.0, which permits commercial use and modification and requires that you preserve the licence and attribution notices for the parts you copy. That is the general shape of Apache-2.0, not legal advice; check the LICENSE file and your own counsel before shipping derived code. One point worth noting for anyone copying the module layout: the README credits specific contributions, including the Glance app widget and the Wear OS client. Attribution in a fork is not optional under this licence, and the sample's own README is where those credits live.

Editorial conclusion

Adopt PeopleInSpace as a reading reference if you are planning a Kotlin Multiplatform app and want to see shared Ktor, SQLDelight, Koin and view models consumed by six different UI toolkits, including the WinUI 3 client whose prerequisites live in windows/README.md. Do not adopt it as an application skeleton if you need a stable API, published artifacts or a support commitment: there are no retrieved releases, and the README documents a sample, not a versioned product. Before copying anything, run ./gradlew :backend:run and confirm http://localhost:9090/astros_local.json responds, then run ./gradlew :common:jvmTest so you know the shared module builds on your JDK 17 toolchain before you transplant it.

Frequently asked questions

Official sources

1. Issues
2. joreilly/PeopleInSpace on GitHub
3. License: Apache-2.0
4. README