Compose has a marketing name problem. Maybe it’s n...

# compose

[Dumitru Preguza]

Compose has a marketing name problem. Maybe it’s not a real issue. I just can’t keep this idea locked in my head;

The name is shadowed by Docker Compose — a case in marketing of brand shadowing that hurts discoverability.
On top of that, the ecosystem feels fragmented:
• Jetpack Compose (Android)
• Compose Multiplatform (desktop, iOS, web)
• Acronyms CMP, KMP (yes KMP is not about Compose but anyway looks like Alphabet Soup and the brand’s equity is weakened again)
• and the now-retired KMM
It doesn’t speak the language of the broader dev community, mobile library authors, CEOs, or marketers. Meanwhile, Flutter communicates clearly with one name, multiple targets.
As a developer, I constantly have to switch terms depending on the platform: “Jetpack Compose animation” for Android, “Compose Multiplatform/CMP iOS animation” (too much typing) for iOS so that I get to the information I'm looking for.
I think Compose should be positioned as one framework, with platform-specific targets:
• Compose for Android
• Compose for iOS
• Compose for Desktop
• Compose Shared
I get that this is complicated — Jetpack Compose is by Google, Compose Multiplatform by JetBrains — so aligning them isn’t trivial.
I wouldn’t be afraid to say that a name change is required to fully exit the shadowing, I like Skiko v 2.0 😅 thanks for reading it until here :)

[Frank Bouwens]

Name idea: 💡
Clutter (Like Flutter, but the C from Compose)

[Frank Bouwens]

( This was a joke, don’t take it seriously ^ )

[Alex Styl]

pretty sure everyone in the community agrees w u @Dumitru Preguza

i personally dont think it's a problem at this moment as the tech is not mature yet

[Dumitru Preguza]

@Frank Bouwens well, I have now more ideas, since the the build tool for CMP/KMP is named Amper, why not take something from electricity field: Circuit, Condukt, Voltix, Fluxel, Phaser, Indux etc

[Frank Bouwens]

Those names sound good!
Let’s hope those names don’t have the same problem.

[Frank Bouwens]

Phaser is already taken:
https://phaser.io/

[Frank Bouwens]

Wouldn’t pick Circuit…
https://circuitpython.org/

[Frank Bouwens]

Oof… Condukt
https://condukt.co/

[Frank Bouwens]

Voltix.. Like the AI
https://x.com/voltixai

[Frank Bouwens]

Fluxel, like the crypto exchange…
https://www.linkedin.com/company/fluxel-inc/

[Frank Bouwens]

Indux, like the EU-funded XR headset
https://indux-r.eu/

[Frank Bouwens]

Maybe it’s better to just keep Compose for now 😉

[Dumitru Preguza]

I mean it’s a job of entire marketing team to think about it, not developers in a chat

[Anthony Mamode]

I totally agree, it would be a game changer to have a distinctive name

[jw]

Don't forget that Compose != Compose UI. If you're going to "fix" the naming, we should also fix the original naming sin.

[Dumitru Preguza]

@jw
Indeed, it’s another thing to keep in mind—thanks for bringing it up. But overall, would you agree that the name and marketing strategy for this product are quite poor?
When I want to look something up, should I just google Compose and expect to find information about the framework as a whole—or something more specific, like its rendering engine? It’s like searching for React and getting mostly results about the virtual DOM instead of the broader framework syntax and ecosystem.
I don’t like the name Compose because it’s too generic and uninformative on its own. You always have to pair it with other terms like Jetpack, Multiplatform, or Multiplatform Shared/iOS/Desktop Code to provide enough context.
The name gets completely lost in search results. In contrast, names like Android or Flutter are distinctive—they stand out, they’re memorable, and they clearly refer to a specific product.
That said, there’s also something clever behind it. The separation in naming allows Google to focus on Jetpack Compose while JetBrains can work on the Multiplatform side independently—yet when you bring them together, they work as a unified composition. I get the intention: 'Let’s be different, not just another framework.'
Still, I’m a bit disappointed to see how every mobile development SDK/Library stack (for example Maps etc) has fallen into the same pattern:
Native Android, Native iOS, Flutter.
It’s always this triplet.
To compete with that kind of clarity and positioning, the name should be sharp—like the tip of a needle—not spread across so many loosely connected terms. This is a marketing issue that could have been addressed early on.

[Zach Klippenstein (he/him) [MOD]]

…have you met Google? Managing a coherent product portfolio in general (and especially naming) is not their strong suit.

[Dumitru Preguza]

@Zach Klippenstein (he/him) [MOD], No I did not met Google

But If I would work on this product I would:
• Make marketing discoverability better.
• Cooperate with Libraries, Frameworks, SDKs.. authors, to adopt CMP to extend the ecosystem (Something similar to what Jetbrains started to do with Kotlin and Spring cooperation recently).
• Not having too much experimental things, and fluctuations, for example today we say "We want a single IDE for multi-platform Fleet", and tomorrow the idea is dropped. If there is an idea is should be implemented quietly, and announced at the correct timing (happiness loves silence). Of course the user feedback is important too.

[Alex Styl]

we got compose due to constant experimentation over the years and dropping things though. you can't get things that work without trying out a tons of things.

cool that they are doing what you mentioned with kotlin and spring. if that worked/s well there is a chance they will do it for compose as well

[Zach Klippenstein (he/him) [MOD]]

I think if you joined google and tried to do all that, you would burn out and quit very soon 😛 but yes that would be ideal

[Dumitru Preguza]

Another thought on this..

I noticed people are starting to create acronyms for this Kotlin-based technology stack. For example, in this article, the author suggests the acronym CKMP — short for Compose Kotlin Multiplatform.

I think this is a smart direction for the Kotlin ecosystem. It gives the stack a clear identity without requiring any renaming of the actual tools — just a memorable label that developers can rally around. It's similar to how stacks like LAMP, MEAN, or company groups like FAANG became shorthand for something larger than the sum of their parts.
We could even explore more pronounceable alternatives to CKMP, like CAMP or KOMP, to make it easier to talk about in presentations, docs, and community discussions. It's a small branding layer, but it helps a lot with recognition and adoption.

🏷️ Title Idea with Acronym:

"Add Firebase to CAMP: Compose and Kotlin Multiplatform"

or

"Using KOMP to Build Cross-Platform UIs with Firebase"

[jw]

Compose multiplatform already implies Kotlin multiplatform so that seems redundant.

[Dumitru Preguza]

Yes but people know about LAMP but don't know about CM / CMP yet, just want something more memorable and easier to pronounce.
Just some food for thoughts.

[jw]

More people know about the CIA and FBI than LAMP, and those are no easier or harder to pronounce than CMP

[Dumitru Preguza]

But people still find other names than CMP, for example in this medium article that I provided, the guy is not comfortable with the status quo, he wants to use CKMP.

[jw]

Sure, but CMP already implies KMP so why are we entertaining their suggestion? I'm not complaining that the L in LAMP for Linux should actually be GNU Linux and the A for Apache should actually be Apache Httpd so it's actually GLAHMP or something

[Dumitru Preguza]

Simply put, I’ve been following this product for more than 5 years now and really want it to have more presence. I was thinking of building something using CMP, but seeing that major mobile Lib/SDK/Framework providers are going with Flutter, it just makes me frustrated. Maybe I have to give it more time.

[Alex Styl]

that's odd. if you want it to have more presence why not build something great with it?

people will naturally ask your stack which produces the best kind of marketing for the framework that you think is lacking.

[Dumitru Preguza]

Because the libs that other parties provide like Map SDKs etc are the building blocks of an app, when the ecosystem is bigger then it’s easier to build something

[jw]

But that's the fundamental catch-22 of platforms. Those libraries won't exist unless the ecosystem is large enough, but the ecosystem won't get large enough unless those libraries exist.

If you are an SDK provider and you want to make CMP more successful then build your SDK for it.

If you are an app developer and you want to make CMP more successful then build your app with it.

Whichever side you're on, you will tip the scales in one direction and if you do it enough the other side will hopefully wake up and help rebalance by rewarding your effort.

Your only other recourse is to throw lots and lots of money at people to try and change the trajectory of the growth curve. And even that isn't a guarantee of anything.

[Zach Klippenstein (he/him) [MOD]]

Also Flutter's been around longer than Compose, so the ecosystem flywheel got started sooner.

[jw]

And they threw stupid amounts of money at it

[Zach Klippenstein (he/him) [MOD]]

I do wish Google would at least pick one of their own multiplatform UI frameworks to support and market going forward.

[Alex Styl]

i am writing 100% in kotlin and compose multiplatform for all my startups now.

yes the ecosystem is not as rich as the other platforms, but it doesn't really matter because kotlin

for backend i use kotlin/js and i use all of nodejs ecosystem which is huge.

for compose if a library doesn't exist, i use the 3rd party lib for the underlying platform and move on with my life. it's not really a big deal

[Dumitru Preguza]

I see. I’m a Backend developer mostly, and the idea to share the business logic, DTOs, etc, across different platforms and at the same time being able to easily communicate between servers and clients with Kotlin libs like kRPC is a selling point for me, it doesn’t make any sense to learn Dart and Flutter for example.