Amper Update, October 2025 – Compose Hot Reload and UX Improvements
Amper 0.8.0 is out, with Compose Hot Reload, a customizable Kotlin compiler version, new JavaScript and Wasm platforms, and many other improvements to both the IDE and CLI experience. Read on for all of the details, and see the release notes for the full list of changes and bug fixes.
To get support for Amper’s latest features, use IntelliJ IDEA 2025.3 EAP (or newer).
Compose Hot Reload support
You can now use Compose Hot Reload to automatically load code changes without having to restart your application:
To do so, just make sure your module has a JVM (desktop) target, and enable Compose Hot Reload in the settings like this:
product: jvm/app # or lib with JVM platform settings: compose: enabled: true experimental: hotReload: enabled
In IntelliJ IDEA, you will then see the Run with Compose Hot Reload button wherever it is possible to run your application.
Read more in the documentation.
Custom Kotlin compiler version support
If you’re eager to try new Kotlin compiler versions before the next Amper release, you can now customize the Kotlin compiler version with a simple setting:
settings: kotlin: version: 2.2.20-rc
Note: only versions 2.0.0 and above are supported.
Simplified single-platform experience
If you are not using multi-platform modules, choosing between the src and src@jvm directories might be confusing.
In Amper 0.8.0, jvm/app and android/app modules have been simplified to only support src, and the @jvm qualifier is no longer permitted in their module.yaml files. We also introduced the new, dedicated product type jvm/lib for JVM-only libraries, which offers the same benefits and better conveys your intent.
JavaScript and Wasm targets support
Amper now supports the js, wasmJs, and wasmWasi target platforms. You can use them in your multiplatform library modules or via one of our new application product types: js/app, wasmJs/app, and wasmWasi/app.
These application product types are very basic for now. Amper simply produces an executable JavaScript or Wasm file, but it cannot run it with ./amper run because it doesn’t currently install any JavaScript runtime or browser.
We are eager to hear what you need in terms of tooling support for these product types – please let us know in the Kotlinlang Slack’s #amper channel.
Maven-local dependency resolution
Previously, Amper only used the Maven local repository to optimize the downloads of artifacts, but never trusted its data. We always verified the artifact’s checksums against the remote repositories to ensure their integrity. This effectively prevented using this repository for artifacts that were locally built and never published to a remote repository.
Now, you can ask Amper to consider the Maven local repository as a regular repository to resolve from so you can depend on your local artifacts. To add this repository, use the special mavenLocal URL like this:
repositories: - url: mavenLocal resolve: true
IDE improvements
Adding dependencies from unresolved code
When your code references a symbol from a library that your existing sources don’t currently depend on, you can now use a quick-fix to add the relevant dependency.
You might recall from our previous blog post that we added this quick-fix in 0.7.0, but back then it only allowed users to add dependencies on local modules. Now, this feature also works for third-party maven dependencies that are already used in another module of your project:
It even works for some dependencies that aren’t in your project at all (more to come!):
Add Spring starter dependencies from inlay hints
After enabling Spring Boot with springBoot: enabled, the dependencies section of the module file now offers a link to add the Spring Boot starters you may need:
Updated New Directory popup
When creating new directories in a new Amper module, you can now choose from several predefined options depending on your platforms:
CLI improvements
Dependency insights
A new CLI command, ./amper show dependencies, allows you to view the dependency graph of a module:
Custom working directory in ./amper run
When using ./amper run, Amper now respects your current working directory by default, even if you specify --root my/project/is/elsewhere.
You can also choose to run your applications in any working directory with the new CLI option --working-dir.
Removal of Gradle-based Amper
Amper used to be available as a Gradle plugin, where it acted as a façade that allowed configuring the project with Amper files while still running the build with Gradle.
As was announced previously, we are phasing out Gradle-based Amper. The last release of Amper as a Gradle plugin was 0.7.0, and there will be no further releases of this plugin in this form.
We are aware that Gradle-based Amper allows users to integrate with plugins or to configure their builds in ways that are not yet possible in the standalone version of Amper. This is why one of our highest priorities is to provide a prototype of Amper extensibility to enable more use cases. We’re also striving to cover the most important use cases directly out of the box. If something you need is not supported yet, feel free to share your suggestions in the Kotlinlang Slack’s #amper channel or open a YouTrack issue.
Updated default versions
We updated our default versions for toolchains and frameworks:
- Kotlin 2.2.10
- KSP 2.2.10-2.0.2
kotlinx.serialization1.9.0- Ktor 3.2.3
- Spring Boot 3.5.5
- Compose 1.8.2
- Android API level 36
Try Amper 0.8.0
To update an existing project, use the update command:
./amper update
To get started with Amper, take a look at the sample projects in the repository.
To enjoy full support for the latest Amper features, use IntelliJ IDEA 2025.3 EAP (or newer).
Share your feedback
Amper is still experimental and under active development. You can provide feedback about your experience by joining the discussion in the Kotlinlang Slack’s #amper channel or sharing your suggestions and ideas in a YouTrack issue. Your input and use cases help shape the future of Amper!
What’s next?
Extensibility prototype
We’re actively working on our prototype for Amper’s extensibility and are almost done with the first iteration. In the next release, you’ll be able to try implementing your own local plugin.
Libraries publication
We know that Maven publication is a critical missing feature for library authors, and we’ve heeded your requests. The publication of JVM libraries to Maven repositories has been unofficially supported for some time (and used to publish Amper itself!), but we are working on providing official support for this.
We will also work on streamlining Maven Central publication out of the box and plan to add support for multiplatform libraries publication.
