Introducing <https://jb.gg/crdi90|Amper by JetBrai...

# announcements

[hhariri]

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!

[Piotr Krzemiński]

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)

[Stylianos Gakis]

Kotlin DSL for Amper would go crazy 👀

[Filip Wiesner]

uses YAML for its project configuration format

Noooooo kodee sad

[amal]

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

[Stylianos Gakis]

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

[Piotr Krzemiński]

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

[Stylianos Gakis]

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.

[darkmoon_uk]

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

[PHondogo]

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

[hhariri]

@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.

[darkmoon_uk]

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

[Jacob Ras]

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.

[Jon Bailey]

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

[Anton Makeev]

@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

[darkmoon_uk]

@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)

[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? Also good to hear that fuller Swift-Kotlin interop is coming 😃

[Leonardo Silveira]

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

[streetsofboston]

I'm going to check it out.

However, I already have one complaint.
"Amper" means "Barely" in Dutch..... 😁

[Leonardo Silveira]

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

[Piotr Krzemiński]

"you'll have barely any config"

[darkmoon_uk]

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

[streetsofboston]

I stand corrected! 😂

[Leonardo Silveira]

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

[Leonardo Silveira]

would be possible to have one?

[Leonardo Silveira]

i think it's important

[Leonardo Silveira]

rename the wrapper script or something

[Oliver Eisenbarth]

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

[sergey.bogolepov]

@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.

[darkmoon_uk]

> 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 👍

[czuckie]

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!)

[Anton Makeev]

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

[Anton Makeev]

@czuckie we are looking forward to seeing, how it will be used in real-world projects. Your input would be really helpful to make the configuration as practical and convenient as possible. Please report problems you encounter, especially the UX friction - this is our focus right now.

[Landry Norris]

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?

[akapanina]

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

[Anton Makeev]

@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

[PHondogo]

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

[Leonardo Silveira]

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

[Jon Bailey]

@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?

[christophsturm]

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

[eygraber]

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.

[Anton Makeev]

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

[Jon Bailey]

@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)

[Fudge]

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.

[darkmoon_uk]

@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.

[Fudge]

What problem does it solve? I fail to see it

[Fudge]

Gradle's problems:
Poor error messages
Poor documentation
API built for a dynamic language
JVM startup times
Java version madness

[darkmoon_uk]

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

[Landry Norris]

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.

[Fudge]

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

[darkmoon_uk]

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.

[Landry Norris]

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.

[Fudge]

How would you write a plugin for this system though

[Fudge]

Jetbrains would need to have an api that somehow both covers all the use cases of a gradle plugin and works in a completely different system

[Landry Norris]

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

[Fudge]

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

[Fudge]

Considering kotlin has come to replace java, i think that's their end goal.

[Fudge]

But oh boy it better be in kotlin and not yaml

[Didier Villevalois]

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!!

[Stylianos Gakis]

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

[hhariri]

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

[gildor]

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

[gildor]

As a user of Kotlin DSL from the first day, unfortunately, I should admit, after all those years, it solved problems when you write the script, but it still do not deliver actual programming experience with Gradle even close, it still mostly manual find/replace and mv instead of IDE experiences.

Of course, it's funny that programming history of builds systems goes back and forth between imperative back to declarative. But IDE and tooling support is such a huge thing for productivity in multi-module world, that I don't see how it can be solved when your build files are not declarative.
Probably have a combination of those is the solution, but I think this middle ground is not found yet, maybe Amper is a great playground to find it, have a tool which combines declarative configs, which work properly with IDE and flexibility of Gradle (or whatever will be BE of it in future)

[Didier Villevalois]

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.

[gildor]

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

[PHondogo]

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.

[gildor]

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

[Piotr Jagielski]

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.

[darkmoon_uk]

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...

[Fudge]

@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"?

[Piotr Jagielski]

@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.

[Waldemar Kornewald]

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.

[Anton Makeev]

@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 #C062WG3A7T8 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

[Jacob Ras]

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

[Maarten]

or "it works amper"