Understand the KMM project structure

Source sets

The shared module contains the code that is common for Android and iOS applications. However, to implement the same logic on Android and iOS, you sometimes need to write two platform-specific versions of it. To handle such cases, Kotlin offers the expect/actual mechanism. The source code of the shared module is organized in three source sets accordingly:

• commonMain stores the code that works on both platforms, including the expect declarations

• androidMain stores Android-specific parts, including actual implementations

• iosMain stores iOS-specific parts, including actual implementations

Each source set has its own dependencies. Kotlin standard library is added automatically to all source sets, you don’t need to declare it in the build script.

kotlin { sourceSets { val commonMain by getting val androidMain by getting { dependencies { implementation("androidx.core:core-ktx:1.2.0") } } val iosMain by getting // ... } } 

kotlin { sourceSets { commonMain { } androidMain { dependencies { implementation 'androidx.core:core-ktx:1.2.0' } } iosMain { } // ... } } 

When you write your code, add the dependencies you need to the corresponding source sets. Read Multiplatform documentation on adding dependencies for more information.

Along with *Main source sets, there are three matching test source sets:

• commonTest

• androidTest

• iosTest

Use them to store unit tests for common and platform-specific source sets accordingly. By default, they have dependencies on Kotlin test library, providing you with means for Kotlin unit testing: annotations, assertion functions and other. You can add dependencies on other test libraries you need.

kotlin { sourceSets { // ... val commonTest by getting { dependencies { implementation(kotlin("test-common")) implementation(kotlin("test-annotations-common")) } } val androidTest by getting val iosTest by getting } } 

kotlin { sourceSets { //... commonTest { dependencies { implementation kotlin('test-common') implementation kotlin('test-annotations-common') } } androidTest { } iosTest { } } } 

The main and test source sets described above are default. The Kotlin Multiplatform plugin generates them automatically upon target creation. In your project, you can add more source sets for specific purposes. For more information, see Multiplatform DSL reference.

Android library

The configuration of the Android library produced from the shared module is typical for Android projects. To learn about Android libraries creation, see Create an Android library in the Android developer documentation.

To produce the Android library, two more Gradle plugins are used in addition to Kotlin Multiplatform:

• Android library

• Kotlin Android extensions

plugins { // ... id("com.android.library") id("kotlin-android-extensions") } 

plugins { // ... id 'com.android.library' id 'kotlin-android-extensions' } 

The configuration of Android library is stored in the android {} top-level block of the shared module’s build script:

android { compileSdkVersion(29) defaultConfig { minSdkVersion(24) targetSdkVersion(29) versionCode = 1 versionName = "1.0" } buildTypes { getByName("release") { isMinifyEnabled = false } } } 

android { compileSdkVersion 29 defaultConfig { minSdkVersion 24 targetSdkVersion 29 versionCode 1 versionName '1.0' } buildTypes { release { minifyEnabled false } } } 

It’s typical for any Android project. You can edit it to suit your needs. To learn more, see the Android developer documentation.

iOS framework

For using in iOS applications, the shared module compiles into a framework – a kind of hierarchical directory with shared resources used on the Apple platforms. This framework connects to the Xcode project that builds into an iOS application.

The framework is produced via the Kotlin/Native compiler. The framework configuration is stored in the ios {} block of the build script within kotlin {}. It defines the output type framework and the string identifier baseName that is used to form the name of the output artifact. Its default value matches the Gradle module name. For a real project, it’s likely that you’ll need a more complex configuration of the framework production. For details, see Multiplatform documentation.

kotlin { // ... ios { binaries { framework { baseName = "shared" } } } } 

kotlin { // ... ios { binaries { framework { baseName = 'shared' } } } } 

Additionally, there is a Gradle task embedAndSignAppleFrameworkForXcode that exposes the framework to the Xcode project from which the iOS application is built. It uses the configuration of the iOS application project to define the build mode (debug or release) and provide the appropriate framework version to the specified location.

The task is built-in in the multiplatform plugin. It executes upon each build of the Xcode project to provide the latest version of the framework for the iOS application. For details, see iOS application.