Shadowgraph
TrendingBuzzResearch
Chrome extension
Sign in

yshrsmz/BuildKonfig

BuildConfig for Kotlin Multiplatform Project

Kotlin

1,221

489 commits

updated Oct 14, 2026

See the code

README

BuildKonfig

Maven Central

BuildConfig for Kotlin Multiplatform and Kotlin/JVM projects.
It currently supports embedding values from gradle file.

Table Of Contents

Motivation

Passing values from Android/iOS or any other platform code should work, but it's a hassle.
Setting up Android to read values from properties and add those into BuildConfig, and do the equivalent in iOS?
Rather I'd like to do it once.

Usage

Requirements

  • Kotlin 2.4.20 or later
    • The plugin depends on the Kotlin Gradle Plugin 2.4.20, so declaring an older version resolves to 2.4.20 anyway.
  • One of: Kotlin Multiplatform or Kotlin/JVM plugin applied to the project (use Kotlin/JS via the KMP js() target)
  • Gradle 8.14 or later

Gradle Configuration

Simple configuration

Kotlin DSL 
import com.codingfeline.buildkonfig.compiler.FieldSpec.Type.STRING

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath("org.jetbrains.kotlin:kotlin-gradle-plugin:2.4.20")
        classpath("com.codingfeline.buildkonfig:buildkonfig-gradle-plugin:latest_version")
    }
}

plugins {
    kotlin("multiplatform")
    id("com.codingfeline.buildkonfig")
}

kotlin {
    // your target config...
    androidTarget()
    iosX64('ios')
}

buildkonfig {
    packageName = "com.example.app"
    // objectName = "YourAwesomeConfig"
    // exposeObjectWithName = "YourAwesomePublicConfig"

    defaultConfigs {
        buildConfigField(STRING, "name", "value")
    }
}
Groovy DSL 
buildScript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath 'org.jetbrains.kotlin:kotlin-gradle-plugin:2.4.20'
        classpath 'com.codingfeline.buildkonfig:buildkonfig-gradle-plugin:latest_version'
    }
}

apply plugin: 'org.jetbrains.kotlin.multiplatform'
apply plugin: 'com.codingfeline.buildkonfig'

kotlin {
    // your target config...
    androidTarget()
    iosX64('ios')
}

buildkonfig {
    packageName = 'com.example.app'
    // objectName = 'YourAwesomeConfig'
    // exposeObjectWithName = 'YourAwesomePublicConfig'

    defaultConfigs {
        buildConfigField 'STRING', 'name', 'value'
    }
}
  • packageName Set the package name where BuildKonfig is being placed. Required.
  • objectName Set the name of the generated object. Defaults to BuildKonfig.
  • exposeObjectWithName Set the name of the generated object, and make it public.
  • defaultConfigs Set values which you want to have in common. If omitted, a warning is logged and code generation is skipped.

To generate BuildKonfig files, run generateBuildKonfig task.
This task will be automatically run upon execution of kotlin compile tasks.

Above configuration will generate following simple object.

// commonMain
package com.example.app

internal object BuildKonfig {
    val name: String = "value"
}

Configuring target dependent values

If you want to change value depending on your targets, you can use targetConfigs to define target-dependent values.

Kotlin DSL 
import com.codingfeline.buildkonfig.compiler.FieldSpec.Type.STRING

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath("org.jetbrains.kotlin:kotlin-gradle-plugin:2.4.20")
        classpath("com.codingfeline.buildkonfig:buildkonfig-gradle-plugin:latest_version")
    }
}

plugins {
    kotlin("multiplatform")
    id("com.codingfeline.buildkonfig")
}

kotlin {
    // your target config...
    androidTarget()
    iosX64('ios')
}

buildkonfig {
    packageName = "com.example.app"

    // default config is required
    defaultConfigs {
        buildConfigField(STRING, "name", "value")
    }

    targetConfigs {
        // names in create should be the same as target names you specified
        create("android") {
            buildConfigField(STRING, "name2", "value2")
            buildConfigField(STRING, "nullableField", "NonNull-value", nullable = true)
        }

        create("ios") {
            buildConfigField(STRING, "name", "valueForNative")
        }
    }
}
Groovy DSL 
buildScript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath 'org.jetbrains.kotlin:kotlin-gradle-plugin:2.4.20'
        classpath 'com.codingfeline.buildkonfig:buildkonfig-gradle-plugin:latest_version'
    }
}

apply plugin: 'org.jetbrains.kotlin.multiplatform'
apply plugin: 'com.codingfeline.buildkonfig'

kotlin {
    // your target config...
    androidTarget()
    iosX64('ios')
}

buildkonfig {
    packageName = 'com.example.app'

    // default config is required
    defaultConfigs {
        buildConfigField 'STRING', 'name', 'value'
        buildConfigField 'STRING', 'nullableField', null, nullable: true
    }

    targetConfigs {
        // this name should be the same as target names you specified
        android {
            buildConfigField 'STRING', 'name2', 'value2'
            buildConfigField 'STRING', 'nullableField', 'NonNull-value', nullable: true
        }

        ios {
            buildConfigField 'STRING', 'name', 'valueForNative'
        }
    }
}
  • packageName
    • Sets the package name where BuildKonfig is being placed. Required.
  • objectName
    • Sets the name of the generated object. Defaults to BuildKonfig.
  • exposeObjectWithName
    • Sets the name of the generated object, and make it public.
  • defaultConfigs
    • Sets values which you want to have in common. If omitted, a warning is logged and code generation is skipped.
  • targetConfigs
    • Sets target specific values as closure. You can overwrite values specified in defaultConfigs.
  • buildConfigField(type: String, name: String, value: String)
    • Adds new value or overwrite existing one.
  • buildConfigField(type: String, name: String, value: String, nullable: Boolean = false, const: Boolean = false)
    • In addition to above method, this can configure nullable and const declarations.

[!NOTE] When targetConfigs are present, BuildKonfig is generated as expect/actual. The K2 compiler (Kotlin 2.x) does not allow expect const val, so the common-side declaration is emitted as plain val even if you set const = true. Each target's actual declaration still uses actual const val, so the value is a compile-time constant inside target-specific source sets — but common code cannot reference it as a compile-time constant (e.g. inside when branches that require constants, or annotation arguments). A warning is logged at generation time for affected fields.

Above configuration will generate following codes.

// commonMain
package com.example.app

internal expect object BuildKonfig {
    val name: String
    val nullableField: String?
}

// androidMain
package com.example.app

internal actual object BuildKonfig {
    actual val name: String = "value"
    actual val nullableField: String? = "NonNull-value"
    val name2: String = "value2"
}

// iosMain
package com.example.app

internal actual object BuildKonfig {
    actual val name: String = "valueForNative"
    actual val nullableField: String? = null
}

Non-multiplatform projects

BuildKonfig also works on standalone Kotlin/JVM projects. Apply org.jetbrains.kotlin.jvm instead of multiplatform, and use the same buildkonfig { ... } block. For Kotlin/JS, use the Kotlin Multiplatform plugin with a js() target — the standalone org.jetbrains.kotlin.js plugin was removed in Kotlin 2.4.0.

Kotlin DSL 
import com.codingfeline.buildkonfig.compiler.FieldSpec.Type.STRING

plugins {
    kotlin("jvm")
    id("com.codingfeline.buildkonfig")
}

buildkonfig {
    packageName = "com.example.app"

    defaultConfigs {
        buildConfigField(STRING, "name", "value")
    }
}
Groovy DSL 
apply plugin: 'org.jetbrains.kotlin.jvm'
apply plugin: 'com.codingfeline.buildkonfig'

buildkonfig {
    packageName = 'com.example.app'

    defaultConfigs {
        buildConfigField 'STRING', 'name', 'value'
    }
}

A single concrete object is generated into the main source set — there is no expect/actual split, since there is only one target.

// src/main/kotlin (generated)
package com.example.app

internal object BuildKonfig {
    val name: String = "value"
}

The defaultConfigs block (including flavors) is fully supported. targetConfigs are not meaningful for a single-target project; if you declare them, a warning is logged and they are ignored.

Product Flavor?

Yes(sort of).
Kotlin Multiplatform Project does not support product flavor. Kotlin/Native part of the project has release/debug distinction, but it's not global.
So to mimick product flavor capability of Android, we need to provide additional property in order to determine flavors.

Specify default flavor in your gradle.properties

# ROOT_DIR/gradle.properties
buildkonfig.flavor=dev
Kotlin DSL 
import com.codingfeline.buildkonfig.compiler.FieldSpec.Type.STRING
import com.codingfeline.buildkonfig.gradle.TargetConfigDsl

buildkonfig {
    packageName = "com.example.app"

    // default config is required
    defaultConfigs {
        buildConfigField(STRING, "name", "value")
    }
    // flavor is passed as a first argument of defaultConfigs
    defaultConfigs("dev") {
        buildConfigField(STRING, "name", "devValue")
    }

    targetConfigs {
        create("android") {
            buildConfigField(STRING, "name2", "value2")
        }

        create("ios") {
            buildConfigField(STRING, "name", "valueIos")
        }
    }
    // flavor is passed as a first argument of targetConfigs
    targetConfigs("dev") {
        create("ios") {
            buildConfigField(STRING, "name", "devValueIos")
        }
    }
}
Groovy DSL 
// ./kmp_project/build.gradle

buildkonfig {
    packageName = 'com.example.app'

    // default config is required
    defaultConfigs {
        buildConfigField 'STRING', 'name', 'value'
    }
    // flavor is passed as a first argument of defaultConfigs
    defaultConfigs("dev") {
        buildConfigField 'STRING', 'name', 'devValue'
    }

    targetConfigs {
        android {
            buildConfigField 'STRING', 'name2', 'value2'
        }

        ios {
            buildConfigField 'STRING', 'name', 'valueIos'
        }
    }
    // flavor is passed as a first argument of targetConfigs
    targetConfigs("dev") {
        ios {
            buildConfigField 'STRING', 'name', 'devValueIos'
        }
    }
}

In a development phase you can change value in gradle.properties as you like.
In CI environment, you can pass value via CLI $ ./gradlew build -Pbuildkonfig.flavor=release

Overwriting Values

If you configure same field across multiple defaultConfigs and targetConfigs, flavored targetConfigs is the strongest.

Lefter the stronger.

Flavored TargetConfig > TargetConfig > Flavored DefaultConfig > DefaultConfig

HMPP Support

a.k.a Intermediate SourceSets. (see Share code on platforms for detail.)
BuildKonfig supports HMPP. However there's some limitations.

When you add a targetConfigs for a intermediate source set, you can't define another targetConfigs for its children source sets.

For example, say your have a source set structure like below.

- commonMain
  - appMain
    - androidMain
    - desktopMain
      - macosArm64Main
      - linuxX64Main
      - mingwX64Main
  - jsCommonMain
    - browserMain
    - nodeMain
  - iosMain
    - iosArm64Main
    - iosX64Main

If you add a targetConfigs for appMain, you can't add configs for androidMain, desktopMain, or children of desktopMain. This is because BuildKonfig uses expect/actual to provide different values for each BuildKonfig object. When you provide a configuration for appMain, actual declaration of BuildKonfig object is created in appMain. So any additional actual declarations in children SourceSets leads to compile-time error.

Supported Types

  • String
  • Int
  • Long
  • Float
  • Boolean

Try out the sample

There are two samples; sample and sample-kts. As its name implies, sample-kts a Kotlin DSL sample, and the other is a traditional Groovy DSL.

Have a look at ./sample directory.

# Publish the latest version of the plugin to test maven repository(./build/localMaven)
$ ./gradlew publishAllPublicationsToTestMavenRepository -PRELEASE_SIGNING_ENABLED=false

# Try out the samples.
# BuildKonfig will be generated in ./sample/build/buildkonfig
$ ./gradlew -p sample generateBuildKonfig
buildconfig
gradle-plugin
kmp
kotlin
kotlin-mpp
kotlin-multiplatform

Significant stargazers

Bartek Pacia

557 followers · starred Jun 2025

Paul Merlin

224 followers · starred Oct 2019

Yahor Berdnikau

97 followers · starred Feb 2019

Yongshun Ye

77 followers · starred Aug 2026

Similar repos

gmazzo/gradle-buildconfig-plugin

A plugin for generating BuildConstants for any kind of Gradle projects: Java, Kotlin, Groovy, etc.…

894

google/ksp

Kotlin Symbol Processing API

3,481

Kotlin/kotlinx-benchmark

Kotlin multiplatform benchmarking toolkit

643

icerockdev/moko-resources

Resources access for mobile (android & ios) Kotlin Multiplatform development

1,352

Kotlin/kmp-basic-sample

Example of Kotlin multiplatform project

1,138

touchlab/KaMPKit

KaMP Kit by Touchlab. A collection of code & tools designed to get your mobile team started quickly…

2,453

russhwolf/multiplatform-settings

A Kotlin Multiplatform library for saving simple key-value data

2,254

google/secrets-gradle-plugin

A Gradle plugin for providing your secrets to your Android project.

1,288

yshrsmz/BuildKonfig

BuildConfig for Kotlin Multiplatform Project

Kotlin

1,221

489 commits

updated Oct 14, 2026

See the code

README

BuildKonfig

Maven Central

BuildConfig for Kotlin Multiplatform and Kotlin/JVM projects.
It currently supports embedding values from gradle file.

Table Of Contents

Motivation

Passing values from Android/iOS or any other platform code should work, but it's a hassle.
Setting up Android to read values from properties and add those into BuildConfig, and do the equivalent in iOS?
Rather I'd like to do it once.

Usage

Requirements

  • Kotlin 2.4.20 or later
    • The plugin depends on the Kotlin Gradle Plugin 2.4.20, so declaring an older version resolves to 2.4.20 anyway.
  • One of: Kotlin Multiplatform or Kotlin/JVM plugin applied to the project (use Kotlin/JS via the KMP js() target)
  • Gradle 8.14 or later

Gradle Configuration

Simple configuration

Kotlin DSL 
import com.codingfeline.buildkonfig.compiler.FieldSpec.Type.STRING

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath("org.jetbrains.kotlin:kotlin-gradle-plugin:2.4.20")
        classpath("com.codingfeline.buildkonfig:buildkonfig-gradle-plugin:latest_version")
    }
}

plugins {
    kotlin("multiplatform")
    id("com.codingfeline.buildkonfig")
}

kotlin {
    // your target config...
    androidTarget()
    iosX64('ios')
}

buildkonfig {
    packageName = "com.example.app"
    // objectName = "YourAwesomeConfig"
    // exposeObjectWithName = "YourAwesomePublicConfig"

    defaultConfigs {
        buildConfigField(STRING, "name", "value")
    }
}
Groovy DSL 
buildScript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath 'org.jetbrains.kotlin:kotlin-gradle-plugin:2.4.20'
        classpath 'com.codingfeline.buildkonfig:buildkonfig-gradle-plugin:latest_version'
    }
}

apply plugin: 'org.jetbrains.kotlin.multiplatform'
apply plugin: 'com.codingfeline.buildkonfig'

kotlin {
    // your target config...
    androidTarget()
    iosX64('ios')
}

buildkonfig {
    packageName = 'com.example.app'
    // objectName = 'YourAwesomeConfig'
    // exposeObjectWithName = 'YourAwesomePublicConfig'

    defaultConfigs {
        buildConfigField 'STRING', 'name', 'value'
    }
}
  • packageName Set the package name where BuildKonfig is being placed. Required.
  • objectName Set the name of the generated object. Defaults to BuildKonfig.
  • exposeObjectWithName Set the name of the generated object, and make it public.
  • defaultConfigs Set values which you want to have in common. If omitted, a warning is logged and code generation is skipped.

To generate BuildKonfig files, run generateBuildKonfig task.
This task will be automatically run upon execution of kotlin compile tasks.

Above configuration will generate following simple object.

// commonMain
package com.example.app

internal object BuildKonfig {
    val name: String = "value"
}

Configuring target dependent values

If you want to change value depending on your targets, you can use targetConfigs to define target-dependent values.

Kotlin DSL 
import com.codingfeline.buildkonfig.compiler.FieldSpec.Type.STRING

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath("org.jetbrains.kotlin:kotlin-gradle-plugin:2.4.20")
        classpath("com.codingfeline.buildkonfig:buildkonfig-gradle-plugin:latest_version")
    }
}

plugins {
    kotlin("multiplatform")
    id("com.codingfeline.buildkonfig")
}

kotlin {
    // your target config...
    androidTarget()
    iosX64('ios')
}

buildkonfig {
    packageName = "com.example.app"

    // default config is required
    defaultConfigs {
        buildConfigField(STRING, "name", "value")
    }

    targetConfigs {
        // names in create should be the same as target names you specified
        create("android") {
            buildConfigField(STRING, "name2", "value2")
            buildConfigField(STRING, "nullableField", "NonNull-value", nullable = true)
        }

        create("ios") {
            buildConfigField(STRING, "name", "valueForNative")
        }
    }
}
Groovy DSL 
buildScript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath 'org.jetbrains.kotlin:kotlin-gradle-plugin:2.4.20'
        classpath 'com.codingfeline.buildkonfig:buildkonfig-gradle-plugin:latest_version'
    }
}

apply plugin: 'org.jetbrains.kotlin.multiplatform'
apply plugin: 'com.codingfeline.buildkonfig'

kotlin {
    // your target config...
    androidTarget()
    iosX64('ios')
}

buildkonfig {
    packageName = 'com.example.app'

    // default config is required
    defaultConfigs {
        buildConfigField 'STRING', 'name', 'value'
        buildConfigField 'STRING', 'nullableField', null, nullable: true
    }

    targetConfigs {
        // this name should be the same as target names you specified
        android {
            buildConfigField 'STRING', 'name2', 'value2'
            buildConfigField 'STRING', 'nullableField', 'NonNull-value', nullable: true
        }

        ios {
            buildConfigField 'STRING', 'name', 'valueForNative'
        }
    }
}
  • packageName
    • Sets the package name where BuildKonfig is being placed. Required.
  • objectName
    • Sets the name of the generated object. Defaults to BuildKonfig.
  • exposeObjectWithName
    • Sets the name of the generated object, and make it public.
  • defaultConfigs
    • Sets values which you want to have in common. If omitted, a warning is logged and code generation is skipped.
  • targetConfigs
    • Sets target specific values as closure. You can overwrite values specified in defaultConfigs.
  • buildConfigField(type: String, name: String, value: String)
    • Adds new value or overwrite existing one.
  • buildConfigField(type: String, name: String, value: String, nullable: Boolean = false, const: Boolean = false)
    • In addition to above method, this can configure nullable and const declarations.

[!NOTE] When targetConfigs are present, BuildKonfig is generated as expect/actual. The K2 compiler (Kotlin 2.x) does not allow expect const val, so the common-side declaration is emitted as plain val even if you set const = true. Each target's actual declaration still uses actual const val, so the value is a compile-time constant inside target-specific source sets — but common code cannot reference it as a compile-time constant (e.g. inside when branches that require constants, or annotation arguments). A warning is logged at generation time for affected fields.

Above configuration will generate following codes.

// commonMain
package com.example.app

internal expect object BuildKonfig {
    val name: String
    val nullableField: String?
}

// androidMain
package com.example.app

internal actual object BuildKonfig {
    actual val name: String = "value"
    actual val nullableField: String? = "NonNull-value"
    val name2: String = "value2"
}

// iosMain
package com.example.app

internal actual object BuildKonfig {
    actual val name: String = "valueForNative"
    actual val nullableField: String? = null
}

Non-multiplatform projects

BuildKonfig also works on standalone Kotlin/JVM projects. Apply org.jetbrains.kotlin.jvm instead of multiplatform, and use the same buildkonfig { ... } block. For Kotlin/JS, use the Kotlin Multiplatform plugin with a js() target — the standalone org.jetbrains.kotlin.js plugin was removed in Kotlin 2.4.0.

Kotlin DSL 
import com.codingfeline.buildkonfig.compiler.FieldSpec.Type.STRING

plugins {
    kotlin("jvm")
    id("com.codingfeline.buildkonfig")
}

buildkonfig {
    packageName = "com.example.app"

    defaultConfigs {
        buildConfigField(STRING, "name", "value")
    }
}
Groovy DSL 
apply plugin: 'org.jetbrains.kotlin.jvm'
apply plugin: 'com.codingfeline.buildkonfig'

buildkonfig {
    packageName = 'com.example.app'

    defaultConfigs {
        buildConfigField 'STRING', 'name', 'value'
    }
}

A single concrete object is generated into the main source set — there is no expect/actual split, since there is only one target.

// src/main/kotlin (generated)
package com.example.app

internal object BuildKonfig {
    val name: String = "value"
}

The defaultConfigs block (including flavors) is fully supported. targetConfigs are not meaningful for a single-target project; if you declare them, a warning is logged and they are ignored.

Product Flavor?

Yes(sort of).
Kotlin Multiplatform Project does not support product flavor. Kotlin/Native part of the project has release/debug distinction, but it's not global.
So to mimick product flavor capability of Android, we need to provide additional property in order to determine flavors.

Specify default flavor in your gradle.properties

# ROOT_DIR/gradle.properties
buildkonfig.flavor=dev
Kotlin DSL 
import com.codingfeline.buildkonfig.compiler.FieldSpec.Type.STRING
import com.codingfeline.buildkonfig.gradle.TargetConfigDsl

buildkonfig {
    packageName = "com.example.app"

    // default config is required
    defaultConfigs {
        buildConfigField(STRING, "name", "value")
    }
    // flavor is passed as a first argument of defaultConfigs
    defaultConfigs("dev") {
        buildConfigField(STRING, "name", "devValue")
    }

    targetConfigs {
        create("android") {
            buildConfigField(STRING, "name2", "value2")
        }

        create("ios") {
            buildConfigField(STRING, "name", "valueIos")
        }
    }
    // flavor is passed as a first argument of targetConfigs
    targetConfigs("dev") {
        create("ios") {
            buildConfigField(STRING, "name", "devValueIos")
        }
    }
}
Groovy DSL 
// ./kmp_project/build.gradle

buildkonfig {
    packageName = 'com.example.app'

    // default config is required
    defaultConfigs {
        buildConfigField 'STRING', 'name', 'value'
    }
    // flavor is passed as a first argument of defaultConfigs
    defaultConfigs("dev") {
        buildConfigField 'STRING', 'name', 'devValue'
    }

    targetConfigs {
        android {
            buildConfigField 'STRING', 'name2', 'value2'
        }

        ios {
            buildConfigField 'STRING', 'name', 'valueIos'
        }
    }
    // flavor is passed as a first argument of targetConfigs
    targetConfigs("dev") {
        ios {
            buildConfigField 'STRING', 'name', 'devValueIos'
        }
    }
}

In a development phase you can change value in gradle.properties as you like.
In CI environment, you can pass value via CLI $ ./gradlew build -Pbuildkonfig.flavor=release

Overwriting Values

If you configure same field across multiple defaultConfigs and targetConfigs, flavored targetConfigs is the strongest.

Lefter the stronger.

Flavored TargetConfig > TargetConfig > Flavored DefaultConfig > DefaultConfig

HMPP Support

a.k.a Intermediate SourceSets. (see Share code on platforms for detail.)
BuildKonfig supports HMPP. However there's some limitations.

When you add a targetConfigs for a intermediate source set, you can't define another targetConfigs for its children source sets.

For example, say your have a source set structure like below.

- commonMain
  - appMain
    - androidMain
    - desktopMain
      - macosArm64Main
      - linuxX64Main
      - mingwX64Main
  - jsCommonMain
    - browserMain
    - nodeMain
  - iosMain
    - iosArm64Main
    - iosX64Main

If you add a targetConfigs for appMain, you can't add configs for androidMain, desktopMain, or children of desktopMain. This is because BuildKonfig uses expect/actual to provide different values for each BuildKonfig object. When you provide a configuration for appMain, actual declaration of BuildKonfig object is created in appMain. So any additional actual declarations in children SourceSets leads to compile-time error.

Supported Types

  • String
  • Int
  • Long
  • Float
  • Boolean

Try out the sample

There are two samples; sample and sample-kts. As its name implies, sample-kts a Kotlin DSL sample, and the other is a traditional Groovy DSL.

Have a look at ./sample directory.

# Publish the latest version of the plugin to test maven repository(./build/localMaven)
$ ./gradlew publishAllPublicationsToTestMavenRepository -PRELEASE_SIGNING_ENABLED=false

# Try out the samples.
# BuildKonfig will be generated in ./sample/build/buildkonfig
$ ./gradlew -p sample generateBuildKonfig
buildconfig
gradle-plugin
kmp
kotlin
kotlin-mpp
kotlin-multiplatform

Significant stargazers

Bartek Pacia

557 followers · starred Jun 2025

Paul Merlin

224 followers · starred Oct 2019

Yahor Berdnikau

97 followers · starred Feb 2019

Yongshun Ye

77 followers · starred Aug 2026

Similar repos

gmazzo/gradle-buildconfig-plugin

A plugin for generating BuildConstants for any kind of Gradle projects: Java, Kotlin, Groovy, etc.…

894

google/ksp

Kotlin Symbol Processing API

3,481

Kotlin/kotlinx-benchmark

Kotlin multiplatform benchmarking toolkit

643

icerockdev/moko-resources

Resources access for mobile (android & ios) Kotlin Multiplatform development

1,352

Kotlin/kmp-basic-sample

Example of Kotlin multiplatform project

1,138

touchlab/KaMPKit

KaMP Kit by Touchlab. A collection of code & tools designed to get your mobile team started quickly…

2,453

russhwolf/multiplatform-settings

A Kotlin Multiplatform library for saving simple key-value data

2,254

google/secrets-gradle-plugin

A Gradle plugin for providing your secrets to your Android project.

1,288