Open-source project
Kotlin/KMP-App-Template avatar
Kotlin/KMP-App-Template

KMP-App-Template: a Kotlin Multiplatform starter with shared Compose UI

Kotlin Multiplatform app template with shared UI

700 stars113 forksKotlinApache-2.0

At a glance

What is it?
The Kotlin organisation's KMP-App-Template is a starting point for an app targeting Android, iOS, desktop and web from one codebase, with shared business logic and a shared Compose Multiplatform user interface. It is deliberately opinionated, it comes with a second variant for native UI, and the iOS target still needs Xcode.
Who is it for?
KMP-App-Template suits a team that has decided on Kotlin Multiplatform and wants a working cross-platform skeleton with shared UI already wired, since the value of the template is that the Gradle configuration, the shared module and the four platform targets are already set up.
Can I use it commercially?
Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 35 days ago.
What is it written in?
Mainly Kotlin, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.

Editorial analysis

One codebase, four targets, one shared interface

The template is described as a basic Kotlin Multiplatform app template for Android, iOS, desktop and web, and the sentence that matters is what follows: it includes shared business logic and data handling, and a shared UI implementation using Compose Multiplatform. That last clause is the whole difference between this template and most cross-platform starters, which share the data layer and then write each screen twice. Here the same Compose code draws the interface on all four platforms, so a change to a screen is one change. The repository layout matches that structure. There are separate application modules for Android, desktop and web, an iosApp directory, and a shared directory holding the code every target consumes, alongside a build.gradle.kts and settings.gradle.kts at the root, a gradle wrapper, gradle.properties and a kotlin-js-store directory. The primary language is Kotlin, the topics list android, compose-multiplatform, ios, kotlin and kotlin-multiplatform, and the licence is Apache-2.0.

Running each target, and the one that needs Xcode

The README's first instruction is to use the run configurations provided by the run widget in your IDE's toolbar, with the Kotlin Multiplatform plugin installed, which is the normal JetBrains workflow. It then gives the command line equivalents, and they are worth reading because the asymmetry between them is the reality of the target matrix. The Android app builds with:

bash
- Android app: `./gradlew :androidApp:assembleDebug`

The desktop app runs with:

bash
- Desktop app: `./gradlew :desktopApp:hotRun --auto`

The web app runs with:

bash
- Web app: `./gradlew :webApp:wasmJsBrowserDevelopmentRun`

And the iOS app is different: you open the iOS project in Xcode and run it from there. So three of the four targets are Gradle tasks and one is an IDE workflow. The web task name is also the first thing to notice about the web story, since it points at the WebAssembly JavaScript target rather than the older JavaScript target. For a team without macOS, the iOS target is simply unavailable, which is the practical limit on how much of this template you can use from Linux or Windows.

The library set the template wires up for you

The template lists the multiplatform dependencies its implementation uses, and the framing is careful. Compose Multiplatform for the UI, Compose Navigation for routing, Ktor for networking, kotlinx.serialization for JSON handling, Coil for image loading, and Koin for dependency injection. Each choice maps to a job a cross-platform app needs, and the point of listing them is that the wiring is done, so a new project inherits a working HTTP client, a working image loader and a working dependency injection setup rather than a folder of empty interfaces. The README is quick to add that these are just some of the possible libraries to use for these tasks with Kotlin Multiplatform, and that their usage here is not a strong recommendation for these specific libraries over the available alternatives, pointing to the kmp-awesome repository as a wider catalogue. That caveat matters. A template is a set of decisions someone else made, and this one tells you explicitly that you may swap any of them.

The app fetches real museum data over HTTP

The data displayed by the app is from The Metropolitan Museum of Art Collection API, which means the template is not a set of hardcoded mock screens. It is a real application that fetches a real public API and renders the result, and that changes what the template demonstrates. You can run it, see the network layer work, see the JSON deserialise, see images load through Coil and see navigation between list and detail. The Met API is a reasonable choice for a sample because it is public and needs no key, and it gives varied data: objects with images, with dates, with metadata that does not fit a single shape. The practical value when you adopt the template is that the plumbing is proven end to end before you replace the data source with your own.

A native UI variant and a Kotlin Toolchain branch

Two related options are offered from the same organisation. The first is a separate repository, KMP-App-Template-Native, described as the same template available with native UI written in Jetpack Compose and SwiftUI. That is the choice for a team that wants the shared business logic but a platform-idiomatic interface, where an iOS user should get a SwiftUI screen rather than a Compose one rendered on iOS. The second is a branch of this repository, the kotlin-toolchain branch, which showcases the same project configured with the Kotlin Toolchain. Both are signposted from the main README, which is a sensible arrangement because they are variations on one project rather than separate products. The branch approach is worth noting for a specific reason: a template that is under active configuration experimentation will move its own build setup around, and a branch is a cheap way to try a different toolchain configuration without destabilising the default.

What a template cannot decide for you

The limits of the template are the limits of the shared UI approach, and they are worth naming before you adopt it. Compose Multiplatform on iOS is not SwiftUI, and if your product requirement is a native feel on Apple devices, the shared UI is the wrong answer and the Native variant is the one to start from. Second, a multiplatform Gradle build is more configuration than a single-platform one: every dependency you add has to be a multiplatform artifact, and the occasional library that is Android-only will break the shared module. The README's own pointer to a wide variety of curated multiplatform libraries is a reminder of how much of the ecosystem you are choosing from a smaller shelf. Third, this is a template and not a library, so it carries no compatibility promise. There are no GitHub releases in this repository, so there is no tagged version to pin, and the last push was on 2026-09-18. If you fork it, the maintenance is yours.

Editorial conclusion

KMP-App-Template suits a team that has decided on Kotlin Multiplatform and wants a working cross-platform skeleton with shared UI already wired, since the value of the template is that the Gradle configuration, the shared module and the four platform targets are already set up. It is the wrong tool if you need native UI, since the shared Compose implementation is the point of this variant and the separate KMP-App-Template-Native repository exists for Jetpack Compose and SwiftUI, and it is the wrong tool if you are starting a single-platform app, where the multiplatform build adds complexity for no benefit. Verify first that the iOS target meets your needs, because the README's own instruction is to open the iOS project in Xcode and run it from there rather than a Gradle command, and note that the repository publishes no GitHub releases while the last push was on 2026-09-18.

Frequently asked questions

How do I run the Android app from the KMP-App-Template?

Use the run configurations from the run widget in your IDE toolbar with the Kotlin Multiplatform plugin installed, or run ./gradlew :androidApp:assembleDebug from the command line.

How do I run the iOS app?

The README says to open the iOS project in Xcode and run it from there, rather than giving a Gradle command, so the iOS target needs a Mac with Xcode.

Which libraries does the KMP app template use?

Compose Multiplatform for UI, Compose Navigation, Ktor for networking, kotlinx.serialization for JSON, Coil for image loading and Koin for dependency injection. The README notes these are examples rather than a strong recommendation, and points to the kmp-awesome repository for more options.

Is there a version of the template with native UI?

Yes. The README links a separate repository, KMP-App-Template-Native, with native UI written in Jetpack Compose and SwiftUI, and a kotlin-toolchain branch in this repository configured with the Kotlin Toolchain.

What data does the template app display?

The data displayed by the app is from The Metropolitan Museum of Art Collection API, so the sample exercises a real HTTP call, JSON handling and image loading rather than hardcoded content.

Official sources

  1. Issues
  2. Kotlin/KMP-App-Template on GitHub
  3. License: Apache-2.0
  4. Project website
  5. README
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/kotlin-kmp-app-template.svg)](https://hysenlabs.com/projects/kotlin-kmp-app-template)

Was this useful?