Introducing Amper by JetBrains, a new experimental project configuration tool focused on usability, onboarding, and IDE support. ⭐️ The current use case is Kotlin and *Kotlin Multiplatform*; it also supports Java and Swift. ⚙️ Implemented as a Gradle plugin, Amper uses YAML for its project configuration format. ✅ Amper currently supports creating applications targeting the JVM, Android, iOS, macOS, and Linux platforms. 💻 You can try it in Fleet or in IntelliJ IDEA. Give Amper a try, and share your feedback with us!

Looks interesting! Regarding YAML, cool that you're open to reconsidering this decision 🙂 (I don't want to repeat the history with typesafegithub/github-workflows-kt)

Kotlin DSL for Amper would go crazy 👀

uses YAML for its project configuration format

Noooooo kodee sad

No thanks. It feels like returning to maven just with yaml instead of xml. I don't see any reason to use it.

This thing has existed for 20 minutes, how can you already know that it’s not the right thing for you 😂

I guess it depends on personal experience. I personally feel an aversion to YAML when it comes to more complicated use cases than defining simple data, e.g. GitHub Actions workflows. I don't know, I'm just a bit afraid it won't provide the optimal UX. YAML has been around for 20 years

But then the issue may be with the format, not with the entire Amper tool. As seen in the first link, there is room to enhance yaml backed programs with better alternatives like Kotlin DSL for example.

Day 1: All my KMP projects are going to have to Migrate to Fleet Day 2: All my KMP projects are going to have to be expressed in YAML Day 3: Hyperventilate and lay on the floor!? IDK

Yaml? No problem! I'll write gradle plugin for it generation. 🙂

@darkmoon_uk And on both days, Hadi says “Chris, it’s going to be more than fine” 🙂 And no, nothing has to migrate to Amper.

Ok, slow, steady breaths[1]... open mind... try out Amper ☺️

There's a FAQ section about YAML: https://github.com/JetBrains/amper/blob/main/docs/FAQ.md#why-dont-you-use-kotlin-for-the-manifest-files

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.

How does the Swift and Kotlin file in the same iosApp/src directory work?

@Jon Bailey there is a certain degree of language interop between Kotlin and Swift already: basically we compile Kotlin code as a framework, and than link it to the native Swift binary. We used it to demonstrate such a joint compilation. We also are investigating fuller Swift-Kotlin interop, so stay tuned

@Anton Makeev Appreciate if it's too early or uncertain to comment; but any thoughts on Combine AsyncSequence/Flows bridging out-of-the box? (I've hand-rolled Combine bridging on two projects now)

I'm already using KMP where I compile a Kotlin only framework and link it into my Swift only app, is this Kotlin/Swift sources in the same directory thing a different thing to KMP? Also good to hear that fuller Swift-Kotlin interop is coming 😃

you made yaml look cleaner than gardle/kotlin, that says a lot about the state of things. i need to test it myself before go beyond cosmetics

I'm going to check it out. However, I already have one complaint. "Amper" means "Barely" in Dutch..... 😁

this is because this build tool is supposed to be bare bones, isn't?

"you'll have barely any config"

...when you put it like that, the name still works? 🤷

I stand corrected! 😂

so, there is no 'amper' command line, it's gradlew and the amper plugin, right?

Feel good about this. Interop w. Gradle is promising.

@darkmoon_uk

Appreciate if it's too early or uncertain to comment; but any thoughts on Combine/Flows bridging out-of-the box?

Yes, it is something we would like to provide out-of-the box. Can't promise anything regarding Combine as it is effectively deprecated in favour of AsyncSequence. In the meantime, you can use either SKIE or KMP-NativeCoroutines.

> Combine as it is effectively deprecated in favour of AsyncSequence. Ah, that says more about how up-to-date I am with iOS Development... As long as the most current 'async/reactive' programming method is bridged (AsyncSequence), then that's great - good luck with the ambition 👍

I for one applaud our YAML project configuration overlords. One of the things I struggle most with is keeping up with the gradle config for KMP so kind of happy to have a specific abstraction on top of these kind of projects that'll let me just get into developing something quickly, but I'm scared of what a production style project yaml could look like (like a gradle one!)

@Leonardo Silveira fair enough, and thanks for the feedback! Right now we plan to collect various requests to see where the demand is

From reading the article, it sounds like Swift/Kotlin in the same folder isn't done yet. Am I misreading that, or can I place a Swift file with objc annotated methods in the same folder right now?

@Landry Norris, you're right, at the moment it's not implemented

@Jon Bailey

I'm already using KMP where I compile a Kotlin only framework and link it into my Swift only app, is this Kotlin/Swift sources in the same directory thing a different thing to KMP?

it's the same machinery under the hood

Why not to make YAGP wich will with minimum verbosity on defaults and can be extended for advanced usage?

@PHondogo maybe the point is to create a brand new build tool but keep some retrocompatibility, just like gradle did

@Anton Makeev cool, so will it also be possible to create a framework (rather than app) from mixing Swift and Kotlin in the same directory?

great idea but I find the choice of yaml very suprising. toml or cue would be much better fitting.

I actually don't mind yaml, as long as its full feature set isn't used. It's a superset of json, and using just objects and arrays with the cleaner yaml syntax is really nice for configuring things.

@Jon Bailey it’s technically possible, but it’s not implemented at the moment.

@Anton Makeev cool, I think then that might overlap with Touchlab's SKIE, but also be more expandable in that custom written/generated Swift can be packaged in as well. Which would be awesome for providing a solid framework to iOS devs. (maybe some of their work could reused to implement it here, if they're willing)

Why couldn't they just add utility methods for common configuration cases like compose and kotlin serialization? This doesn't even solve anything because it's built as a gradle plugin and as soon as you will need to do anything custom you will need to use Gradle anyway which means the "barrier of entry" is not lowered for non -jvm devs.

@Fudge 's comment resonates with me too. JB please consider: can the goals of Amper be achieved with a Kotlin DSL inside Gradle KTS? Besides remaining 'on message' for the ecosystem, this would make it a lot easier to diverge within Gradle if developers encounter it's limits. I'm using KMP for large projects with complex config, I doubt I'll be able to benefit from Amper in is current form, despite welcoming a solution to some of the problems it solves.

What problem does it solve? I fail to see it

I'm afraid that moving things outside of Gradle and away from Kotlin DSL is an ecosystem fragmenting move.

The main problem it solves from my perspective is for simple apps. At my last job, when we were evaluating Flutter vs KMM, many of the non-android devs saw Gradle as intimidating, and Flutter's basic config less so. Amper makes KMM's barrier to entry lower, as long as it can handle most simple configs. Not every project needs a big gradle config, but we still get that if we need it.

You hit the nail on the head. This is purely psychological and marketing-based

And yes @Fudge I was really only thinking of when spinning up smaller personal projects, but again that's not a problem I need a new configuration format to solve; a Kotlin Gradle DSL library would suffice. Hopefully there's an opportunity for Amper to adopt a 1:1 approach between YAML and Kotlin DSL. ...in this way JB can get the marketing benefit and we have the safety of knowing it's unlikely to fragment.

Part of what makes amper enticing is that it's not necessarily gradle backed. It could use a different backend in the future if there's a better option. If the jvm takes too long to start, K/N can be an option for the runner. In terms of documentation, of course docs will be lacking on the first day, but I expect that to get better over time.

How would you write a plugin for this system though

They do lay out a plan for an extension system in the docs. It's not there yet, but planned.

I guess it might be possible. The gradle api has a ton of redundancy. The question is is Jetbrains up to the task of completely replacing gradle. Given infinite resources, sure. But Gradle is constantly improving and has an immense backing. Is this economical

YAML? This means no configuration factorization, no self-explanatory, no type-safety... Feels like a regression when everyone is moving away from YAML formats to DSLs (infrastructure as code, CI/CD as code, ...). No thanks, not for me!!

This entire thread has been a great learning experience for me. You learn two things here 1. People really hate YAML 2. People refuse to read the FAQ which answers a lot of the questions, including about YAML

@Didier Villevalois Do you feel it is often that you need to refactor your build files?

Yes, all the time refactor build files when project grows: rename modules, move one modules to another, extract code to another, delete and so on But! I would say that such refactoring doesn't work with Gradle too and Kotlin DSL doesn't help, it's very painful to even rename module, not mentioning more complex cases So I would say I would love refactoring of build files, but it requires really good IDE support, and Gradle is a terrible tool for this and I don't see how it can be solve, never IDE will be able to understand structure of build files and update automatically, it's too imperative to let any tool touch it, this why we got version catalog with gradle, at least to have some standard way to declare dependencies for automatic tools

Hi Hadi! Well, yeah. For background, let me compare this to gitlab-ci.yml and package.json files. We have lots of those at work, and I can tell you this is not scalable at all and leads to a lot of configuration duplication, maintenance nightmare. I am way more comfortable with Gradle even if, I must concede, the barrier for entry is a bit higher for new devs. But I believe this could be improved and that is where resources should be put.

And yeah, usual and repetitive comment: YAML is an absolutely terrible format, I wouldn't cry about it yet, after all those disclaimers in FAQ, But one more reminder: it's padding-based (merch idea for KotlinConf 2025: Kotlin branded ruler for monitor to align yaml paddings), zero out of the box reference/variables support, no proper format declaration language (like xmlns, which is important for custom extensions/pliugins) and as result also no type-safety Though, I'm not sure that TOML is much better (better, but too simplistic). Probably own format is not the easiest, but the only correct way to go here, I am not sure that anything that I know is perfect. Maybe HOCON is the closest to what I would like to see

I like the idea if using Kotlin for everything: code for each platform, build scripts, compiler plugin. With maximum reusability without any duplication. With yaml it will be impossible. If Jetbrains want to move from Gradle then why not to reuse Kotlin scripting for own build tool. It can be minimal (for default cases) to reach compromise between ide integration and customization.

Because it explained in FAQ, declarative format to make it work for IDE without project sync hell (at least on some level)

At Gradle, we just started a new related initiative called developer-first software definition (or Declarative Gradle for short). See https://blog.gradle.org/declarative-gradle. We are excited about it and believe it will make both software developers and build engineers using Gradle happier. We are collaborating with Google and JetBrains on this.

Okay... now this starts to make a bit more sense; I could see the speed up in analysis of the project being a 'game changer' for the way we interact with IDE's. I question at what cost that would come though; in my company we've been able to get a lot of value out of the Gradle model. For example, our in-house plugin: • Performs several environment inspection and remediation steps so we can configure all the parts effectively for local/CI. • Inspects the IDE version being synced with, to automatically select the right AGP plugin so we can more easy open the project 'up & down' the scale of new IDE versions to verify fixes. • Allows us to load App and Library projects that we develop in tandem, in either: ◦ A standalone configuration ◦ A Gradle composite combined workspace • Many more quality-of-live code-reduction functions, reused across project modules. For this to work for us there would need to be a very nuanced integration of the declarative model with Gradle's existing model, that would still enable us to configure and sequence declarative steps programmatically. Maybe that type of problem is what 'Declarative Gradle' is meant to solve; reading up...

@Piotr Jagielski how does this pair up with Amper? Will a common api be used for both Gradle and Amper? Will there be competing ways of writing "declarative builds", where Jetbrains use Amper and Gradle use "Declarative Gradle"?

@Fudge Amper is a separate experiment with similar goals. We’ll see what will be the community feedback about it. One of our goals is to use the learnings from this experiment in developing Declarative Gradle to provide a great user experience for Kotlin and Kotlin Multiplatform. We are in touch with the Amper team at JetBrains. I hope it will all converge on the Gradle-native solution.

Our primary problem with Gradle is that the current build system is missing a lot of basic functionality that we have to implement by hand: 1. sharing the same .kt files between multiple targets (e.g. adding a

nonJvmMain

or

jvmCommonMain

and other combinations) a. Instead of going with sourceSet hierarchies or

src@jvm

+

src@ios

and other single-sourceSet folder solutions why can’t I just use a folder name with a comma-separated list like

src@ios,js

to list multiple targets that should share the same files? Then I wouldn’t need any Gradle config with a custom sourceSet hierarchy or copy-pasted files for this. Or going even crazier, maybe we can put everything into a single

src

folder and then allow package folders and individual files to be marked with

...@ios,jvm,android

(default being

@common

)? 2. proper BOM modules 3. an easy to use maven-publish setup (and I’m not even talking about getting your project published on Maven Central which makes it 10x more complicated) 4. publishing XCFrameworks 5. building and publishing multiple XCFrameworks in a way that they can share code (we have multiple SDKs which need to be integrated in different client apps and proper code sharing requires really ugly solutions) 6. adding pod dependencies in a way that works half-way sanely in a multi-module setup where pod deps need to be transitive and the linkOnly flag needs to be set correctly per module; also C/C++ pods sometimes need an explicit

header

or

moduleName

param and with 1.9.20 we explicitly need to pass

-compiler-option -fmodules

only for certain modules. Kotlin really should detect most of this for us… 7. auto-creating the iPhone simulator for unit tests (configuring the CI and dev machines by hand is just too error-prone and wastes time for the whole team) 8. fixing up the generated Podfile to set the correct

IPHONEOS_DEPLOYMENT_TARGET

because some iOS deps force us 9. packaging assets and translations for KMP (e.g. in XCFrameworks and JS) a. generating custom .podspecs for local dev with those extra assets 10. various levels of R8 obfuscation for Android (we have debuggable and other configs which are important when trying to understand a bug in release builds) 11. fixing the buggy/broken JS .d.ts type definitions in a post-processing step 12. configuring js browser tests 13. publishing npm packages 14. setting up Dokka with sane defaults (like picking up README.md from modules automatically, activating multi-module docs, configuring Gfm output so that we can pipe that through mkdocs because Dokka’s HTML doesn’t work well for multi-module projects, etc.) 15. splitting the publication and build steps via env vars, so the local dev setup normally builds and publishes (to mavenLocal) everything, but the CI parallelizes and/or separates these builds, so a 2h long CI SDK build can at least finish the Android publication quickly; also for local testing our Android devs often, but not always, want to only publish the Android artifacts to mavenLocal because that’s like 10x faster than waiting for an unnecessary iOS build 16. ktlint and detekt integration (this could be a standard feature) 17. code coverage setup for all KMP sourceSets and exclusions e.g. for generated code 18. project/module versioning based on Git tags 19. dependency license tracking 20. listing outdated dependencies 21. compiler options (e.g. strict mode) and module/project wide opt-ins 22. … There is so much you have to take care of in a Gradle-based KMP project. Our project surely had to invest several weeks of effort into those build scripts, so different teams could reuse them without thinking much about Gradle. Many of these things could be default conventions instead. The current Gradle setup is optimized for the simple app use-case instead of the multi-module SDKs + multi-apps use-case. Also, the build system should try to force users much more into writing global/reusable build configs by default instead of per-module. It’s way too easy to start configuring Android settings in

android-app/build.gradle.kts

(or

module.yaml

) and then once you transition to a multi-app project this concept breaks down. Why not have a global app config in the root build script right from the start then? Most or maybe even all per-module config should live in the root build script (or multiple root scripts which include each other). Even the per-module dependencies benefit a lot if they’re reusably defined in a global build script such that dependency version numbers can’t become inconsistent and so you can group multiple dependencies for easier reuse. Per-module configs are almost always plain wrong and should not be the default. Also, regarding plugins (Gradle and compiler): I don’t like that we have to repeat the kotlinx.serialization plugin (and others) in multiple modules and whenever you forget that you get unintuitive error messages. Why can’t compiler plugins be added transitively as part of dependencies, too? We have the same problem with the webpack.config.d configs which aren’t transitive and thus result in ~50 copy-pasted files in the whole repo. Most build configs should be transitive. That’s also an important property of global build configs which are basically transitive from the root to their child modules. So, we’re missing proper defaults and conventions and transitive configs to get the build scripts down to just a few really essential lines of code. The problem with Gradle, Gulp, webpack and other programming language centered build systems is that they make it easy to just create a workable 50% solution and anyone who needs more must build on top. Gradle’s other problem is also the JVM dependency and its overhead. YAML forces you to think much harder about a 100% solution and keep it trivially simple. Still, I’d prefer some Kotlin based solution which allows much better code reuse to keep the build scripts as tiny as possible. Though who knows, maybe with the right approach there’s hardly any YAML necessary.

@Waldemar Kornewald thanks! That's a useful list, we'll take time to process it and consider how the items could be addressed.

a. Instead of going with sourceSet hierarchies or

src@jvm

+

src@ios

and other single-sourceSet folder solutions why can’t I just use a folder name with a comma-separated list like

src@ios,js

to list multiple targets that should share the same files? Then I wouldn’t need any Gradle config with a custom sourceSet hierarchy or copy-pasted files for this. Or going even crazier, maybe we can put everything into a single

src

folder and then allow package folders and individual files to be marked with

...@ios,jvm,android

(default being

@common

)?

Could you please take a look at the following section and share your thoughts? (and feel free to join the #amper channel to continue discussion) https://github.com/JetBrains/amper/blob/main/docs/Documentation.md#project-layout https://github.com/JetBrains/amper/blob/main/docs/Documentation.md#aliases

Btw @streetsofboston about the Dutch meaning: we can also just take it to mean this will require "amper" (barely) setup to get things working 😉

or "it works amper"