Yes, Amper is a project configuration and build tool with a focus on user experience and IDE support. Amper exists as a standalone build tool as well as a Gradle plugin for existing Gradle-based projects. Both versions offer a unified, easy-to-use, declarative configuration format.
For now, the primary target is Kotlin and Kotlin Multiplatform projects. Since Kotlin is multiplatform, Amper also supports Java on the JVM, and Swift and Objective-C on iOS. We’ll investigate other tech stacks in the future based on the demand for them.
Currently, you can create applications for the JVM, Android, iOS, macOS, and Linux. Libraries can be created for all Kotlin Multiplatform targets.
Yes, you can configure Compose for Android, iOS, and desktop.
Currently, Amper doesn't support Kotlin/JS and only supports Wasm in library modules. Please follow AMPER-221 for updates on JS support, and AMPER-258 for updates on Wasm support.
We’re working on the following functionalities: version catalogs, Swift Package Manager support, C-interop, packaging and publication, and extensibility.
Yes, Amper is already open source.
Right now, we’re focusing on getting feedback and understanding your needs. Based on that, we’ll be able to provide a more accurate estimate of a release date sometime in the future.
You’re welcome to use it in any type of project. However, please understand that Amper is still in the experimental phase, and we expect things to change.
Understanding real-world scenarios is crucial for us to provide a better experience, so from our side we’d love to hear about the challenges you may face porting existing projects. However, please understand that the project is still in the experimental phase, and we cannot guarantee that all scenarios can be supported.
Please report problems to our issue tracker. Since this project is in the experimental phase, we would also greatly appreciate feedback and suggestions regarding the configuration experience – join our Slack channel for discussion.
Currently, we use YAML as a simple and readable markup language. It allows us to experiment with the UX and the IDE support much faster. We’ll review the language choice as we proceed with the design and based on demand. The Kotlin DSL, or a limited form thereof, is one of the possible options.
Having said that, we believe that the declarative approach to project configuration has significant advantages over the imperative approach. Declarative configuration is easily toolable, recovery from errors is much easier, and interpretation is much faster. These properties are critical for a good UX.
Our final language choice will be made based on the overall UX it provides.
In the initial Amper prototype, our main focus was improving the user experience and toolability of build configuration. Gradle, as a well-tested build engine, allowed us to start experimenting with the UX of the configuration very quickly. What’s more, smooth interoperability with Gradle allows for the use of Amper in existing projects, which is important if we want to get feedback from real-world use cases.
Amper also exists as a standalone build tool, which allows us to improve the IDE support and workflows even further.
We believe there is room to improve the project configuration experience and IDE support. With Amper, we want to show you our design and get your feedback, as it will help us to decide which direction to take the design.
At the same time, we are also working with the Gradle team to improve Gradle support in our IDEs and Gradle itself.
We aim to support most of the Kotlin and Kotlin Multiplatform use cases out of the box, and offer a reasonable level of extensibility.
In addition to the standalone version, Amper is offered as a Gradle plugin.
Gradle-based Amper offers full interoperability with Gradle, including the use of Gradle plugins and writing custom
tasks.
Both projects aim to improve the developer experience and the IDE support, but from opposite directions and with different constraints. Amper's approach is to design, from the ground up, a tool that is easy to use for the developers regardless of their background, with great IDE support in mind, and focused on specific use-cases. The Declarative Gradle project approaches the same goal from the other end, simplifying and managing the complexity of an already exising powerful tool.
While both projects are still experimental, it's important that you provide your feedback to shape the future development.
To use Amper on the command line:
- The standalone version of Amper is self-contained. See the usage instructions.
- Gradle-based Amper projects require JDK 17+ and Gradle 8.6. See the usage instructions.
To use Amper in the IDE:
- The latest IntelliJ IDEA EAP is required for JVM and Android projects. See the usage instructions.
- The latest JetBrains Fleet is required for the JVM, Android, and Kotlin Multiplatform projects. See the usage instructions.
You have several options:
- Kick-start your project using one of the example standalone or Gradle-based projects.
- Read the blog post to learn how to create a project from scratch using the IDE.
- Generate a project from a template using the
amper initcommand with standalone Amper.
See the documentation on the project layout and the comparison of Amper and Gradle project layouts.
Check the tutorial on migrating your Gradle project and subprojects.
Not currently, but it's certainly something we’re looking into. See the Gradle migration tutorial and examples.
We plan to expand the list of supported use cases based on demand. Please submit your requests and suggestions in the tracker or join the Slack channel for discussions. Meanwhile, you can use Gradle plugins and tasks as usual. See the documentation on the Gradle interop.
Extensibility is not currently implemented in Amper, but we are working on it. Meanwhile, in Gradle-based Amper projects, you can use any available Gradle plugin and write custom tasks. See the documentation on Gradle interop.
If you cannot find an answer in Amper documentation or examples, you can still use Gradle interop and configure as usually in your build.gradle(.kts) files.
For now, Amper doesn't directly support C-interop. You can use Gradle interop as a workaround.