Recently, Amper released Kotlin Toolchain 0.11: The Next Step for Amper, the core of which is Amper has evolved into the Kotlin Toolchain and is now Alpha, meaning JetBrains has officially merged Amper into the Kotlin Toolchain and advanced it from the experimental stage to Alpha.

It feels like JetBrains wants to create a unified entry point for the Kotlin ecosystem, similar to cargo / dotnet / go.

Starting from Kotlin Toolchain 0.11, the name Amper has been downgraded in product positioning, with its core capabilities being entirely migrated into the Kotlin Toolchain. There will no longer be an amper command entry point; everything is unified under kotlin:

The original amper / amper.bat wrapper is to be replaced with the new kotlin / kotlin.bat wrapper, and the IDE plugin also switches from the Amper plugin to the Kotlin Toolchain plugin.

From a product perspective, Amper's previous positioning was 'helping you configure Kotlin/KMP projects with YAML,' but now it has become part of the Kotlin Toolchain, serving as the unified entry point for Kotlin projects. You can create, build, run, test, and publish projects through a single kotlin command.

The reason JetBrains is doing this is mainly because they feel the current Kotlin ecosystem is too fragmented. Currently, working on a Kotlin project requires dealing with a pile of things:

Kotlin compiler, Gradle, Kotlin Gradle Plugin, Android Gradle Plugin, Kotlin/Native, Xcode/iOS artifacts, Maven publishing, Maven Central signing, source sets, platform-specific configurations...

Now, the Kotlin Toolchain converges the project entry point for Kotlin from Gradle scripts, plugin versions, and template fragments into a unified official Kotlin entry point. The goal is:

The Kotlin language is very modern, but the engineering experience is still stuck in the JVM's Qing Dynasty era. It's time for a change.

So, starting from 0.11, kotlin is the unified entry point, for example, kotlin build / kotlin run / kotlin test / kotlin publish. At the same time, the global kotlin command will not force all projects to use the same toolchain version; it will automatically find the wrapper in the project and run the matching version.

Additionally, 0.11 finally supports publishing JVM libraries to Maven repositories, including Maven Central. Publishing to Maven Central was previously very troublesome:

sources jar, javadoc jar, PGP signing, POM metadata, checksums, deployment bundles, etc. The Kotlin Toolchain will now handle these automatically. You declare the publishing configuration in module.yaml, then execute kotlin publish mavenCentral, and it will build, sign, package, upload, and wait for Maven Central verification.

However, Kotlin Multiplatform libraries cannot yet be published. KMP library publishing is still in progress and can currently only be used for product: jvm/lib:

product: jvm/lib

description: A meaningful description for this specific module

settings:
  publishing:
    enabled: true
    group: com.example # the group has to match your Maven Central namespace
    version: 1.0.0
    # artifactId is optional, and defaults to your module's name
    mavenCentral: enabled
    signArtifacts: true # automatically sign your artifacts, no external GPG binary required
    publishSources: true
    pom:
      url: https://example.com
      scm: https://github.com/my-org/example.git # the SCM connection and dev connection are automatically derived from this
      developers:
        - name: John Doe
      licenses:
        - name: MIT
          url: https://opensource.org/license/mit

Next, there are Cinterop support enhancements. The Kotlin Toolchain can now generate C library bindings based on .def files in the module's cinterop folder. The IDE sync phase will also generate bindings and provide assistance.

This is critical for KMP / Kotlin Native, because if Cinterop can be managed uniformly by the Toolchain, it can reduce a lot of manual configuration in Kotlin/Native projects.

At the same time, 0.11 also improves terminal output and IDE synchronization, for example:

• Library sources will be automatically downloaded in the background after sync, so you can start writing code immediately after syncing without waiting for the sources download to complete.
• The IDE plugin's dependency resolution has been aligned from 'project-level' to 'module-level,' consistent with CLI behavior. Previously, the IDE might resolve incorrect dependency versions for a module, or editor warnings might not match the CLI. Now each module has its own resolution scope.

The core point is CLI and IDE behavior consistency, which is also one of the core values of Amper / Kotlin Toolchain, because the Gradle ecosystem has long suffered from various pain points:

• The command line works, but the IDE shows red.
• The IDE shows no red, but CI fails.
• Slow synchronization.
• Inconsistent dependency resolution.
• Complex combinations of source sets / targets / variants.

So, if the Kotlin Toolchain can make the IDE model and the build model the same declarative structure, it will be very valuable for KMP.

Finally, 0.11 also adds several plugin development capabilities:

• checks: Plugins can register quality checks, such as lint, and then execute them via kotlin check

# my-lint-plugin/plugin.yaml
tasks:
  runLinter:
    action: !kotlinJavaLint
      sources: ${module.kotlinJavaSources}

checks:
  - name: lint
    performedBy: runLinter

• commands: Plugins can expose public commands, for example, kotlin do updateBaseline

# my-lint-plugin/plugin.yaml
tasks:
  updateBaseline:
    action: !runDetektForBaseline
      sources: ${module.kotlinJavaSources}
      outputFile: ${module.rootDir}/detekt/baseline.xml

commands:
  # shorthand when the name of the command matches that of the task
  - updateBaseline

• generated: Unified declaration of generated sources, resources, classes, cinterop definitions, replacing the old markOutputAs

tasks:
  generateStuff:
    action: !myGenerateStuffAction
      outputSources: ${taskOutputDir}/src
      outputResources: ${taskOutputDir}/res
      outputDefFiles: ${taskOutputDir}/cinterop

generated:
  sources:
    - directory: ${tasks.generateStuff.action.outputSources}
      language: kotlin
  resources:
    - directory: ${tasks.generateStuff.action.outputResources}
  cinteropDefinitions:
    - directory: ${tasks.generateStuff.action.outputDefFiles}

Regarding this, JetBrains also specifically emphasized that such generated artifacts can be more easily recognized by humans, AI agents, and other tools.

This point is very interesting, meaning the Kotlin Toolchain is clearly not just for humans to write configurations; it is also preparing for AI coding / agent scenarios. YAML declarative configuration is obviously easier for tools to understand than Gradle Kotlin DSL.

Gradle scripts are essentially executable code that can contain conditional judgments, function calls, dynamic task registrations, and plugin magic, all of which are difficult for IDEs, CI, and AI agents to statically analyze.

From the current perspective, Amper's entry into the Kotlin Toolchain also signifies that it has officially become the protagonist of the future. The unified kotlin entry point also means that commands like gradlew will gradually be marginalized.

In the short term, Gradle will still be around, but now in new Kotlin-first / KMP-first projects, Gradle's 'direct visibility' will be gradually reduced.

Think about it, when JetBrains introduced Amper in 2023, they said Amper was implemented as a Gradle plugin, using YAML for project configuration, with the goal of first validating the user experience. They also emphasized a commitment to supporting Maven and Gradle and would not change their support for these technologies.

But after 2026, Amper is no longer related to Gradle, with more emphasis on "ecosystem doesn’t just need another build tool – it needs a unified entry point into all of Kotlin," meaning JetBrains has upgraded its goal from "improving the Gradle configuration experience" to "establishing an official Kotlin toolchain entry point."

So, 0.11 is not a minor version; it is also a signal: JetBrains is telling the community:

Kotlin no longer wants to be just 'language + Gradle plugin'; it has evolved into a complete toolchain ecosystem.

Links

https://blog.jetbrains.com/amper/2026/06/kotlin-toolchain-0-11/#terminal-ui-improvements