Starting now, the Kotlin Multiplatform (KMP) default project structure is getting a major overhaul. Whether you're building a shared library, a mobile app, or a desktop application, these changes aim to simplify module responsibilities, align with industry conventions, and prepare for future Android Gradle Plugin (AGP) updates. In this article, we break down the seven most important aspects of the new layout, from the split of the old composeApp module to the introduction of dedicated platform-specific application modules. If you're migrating an existing project or starting fresh, this guide will help you understand what's different and why.
1. A Clear Separation Between Shared Code and Application Configuration
Previously, a single composeApp module served double duty: it housed both the shared Kotlin Multiplatform library and the application entry points for multiple platforms. This mixing of concerns made the Gradle build file bloated and confusing. Under the new structure, the shared code lives in its own shared module—a pure Kotlin Multiplatform library with no application responsibilities. Each runnable platform (Android, desktop, web) now has its own dedicated module, such as androidApp, desktopApp, or webApp. This separation mirrors conventions used by other build systems and makes the project easier to understand and maintain.
2. The Old composeApp Module Had Too Many Responsibilities
In the previous layout, the composeApp module contained platform-specific packaging details for all supported platforms, making it hard to tell which configuration belonged to the shared library and which to the application. For example, setting up Compose Multiplatform meant mixing UI framework dependencies with Android manifest entries. This complexity often led to misconfigurations and made onboarding new developers slower. By splitting responsibilities, each module now has a single, well-defined purpose: the shared module only provides business logic and data layers, while each application module focuses solely on platform entry points and packaging. This reduces cognitive load and simplifies debugging.
3. New Dedicated shared Module with One Job
The cornerstone of the revised default structure is the shared module. It is a Kotlin Multiplatform library that contains all the code you want to reuse across platforms—models, repositories, view models, and networking logic. It does not include any platform-specific entry points, manifest files, or application plugins. This clean separation means you can easily publish the shared module as a library, test it independently, and consume it from any number of application modules. The shared module also simplifies dependency management: you only declare multiplatform dependencies once, without worrying about accidental leaks into application-level configuration.
4. Separate Application Modules for Each Platform (androidApp, desktopApp, webApp)
Instead of everything living inside one oversized module, you now get distinct application modules: androidApp, desktopApp, and webApp. Each of these modules is responsible for defining the entry point, app manifest (for Android), window configuration (for desktop), or web setup. This makes it explicit which platform you are configuring and avoids clashes between settings. For example, developers who want to use SwiftUI on iOS can simply not include an iOS app module in the default structure, while still leveraging the full Java-based shared library for Android and desktop. The modularity also improves build caching: changes to one platform's configuration don't invalidate the builds of others.
5. iOS Development Benefits from Consistent Modularity
In the old setup, iOS apps were already separated into an iosApp folder because they require an Xcode project that consumes the shared framework. However, this created asymmetry—Android and desktop apps were inside composeApp, while iOS was outside. The new structure eliminates this inconsistency: all platform application modules are treated equally. iOS developers still get their own iosApp (or a dedicated module) that references the shared library via a framework. This makes the project layout predictable regardless of whether you share UI with Compose Multiplatform or use SwiftUI exclusively. The modular approach also makes it easier to add new platforms like watchOS or tvOS in the future.
6. Full Compatibility with Android Gradle Plugin 9.0
Android Gradle Plugin 9.0 introduces a breaking change: it no longer allows applying the Android application plugin inside a multiplatform module. The old composeApp module would violate this rule because it both shared code and acted as an Android app. The new structure solves this by moving the Android entry point into a dedicated androidApp module. This ensures your project is ready for AGP 9.0 as soon as you update to IntelliJ IDEA 2026.1.2 or newer (and use the latest Android plugin). By adopting the new layout now, you avoid migration headaches later. The KMP wizard and official samples already enforce this pattern.
7. Get Started Today: Migration and Tooling Support
The improved structure is already live in the KMP project wizard—both inside IntelliJ IDEA with the Kotlin Multiplatform plugin and at kmp.jetbrains.com. You can generate a new project and see the shared plus platform-specific modules instantly. For existing projects, JetBrains recommends manually refactoring: extract shared code into a new module, then create application modules for each platform. The kotlinconf-app, KMP-App-Template, and RSS Reader samples demonstrate the new layout. Updating learning materials is ongoing, but these samples serve as reliable references today.
With these seven changes, the Kotlin Multiplatform default project structure becomes more intuitive, scalable, and future-proof. By adopting a dedicated shared module and separate application modules, you'll write cleaner builds, reduce configuration errors, and prepare your codebase for AGP 9.0. Start exploring the new layout in the wizard and see how it simplifies your multiplatform development workflow.