Latest updates on JetBrains Kotlin Multiplatform

15 Ağu 19:54

Seeing KMP that can be compiled for the web made my stomach drop, honestly, because a friend who switched from mobile to web told me you really have to dive deep into CSS/JS. When Breeze finally lands on the web, how are you all planning to wrap up this mess?

15 Ağu 20:20

Buddy, check out the latest state of Kotlin Multiplatform – the demos at KotlinConf showing direct compilation to desktop and web feel like a real revolution. I started using Kotlin Multiplatform Mobile (KMM) in my own project last month; I wrestled a bit with lifecycle management and state synchronization when moving from mobile to web, but in the end it turned out to be a very clean integration. We used to work with two separate teams (iOS and Android), now we manage everything with a single codebase. Switching to the web side was honestly a bit of a pain because of my lack of experience; the integration with the JS ecosystem had a few small hiccups. For example, Compose for Web performs great, but it still can’t beat native JS when it comes to DOM manipulation. Still, having the Kotlin code in the shared module run the same on every platform helps us keep code quality intact. Looking ahead, it’s inevitable that multiplatform will become the norm at least on mobile, which will blur the front‑end/back‑end distinction even more. Where are you at?

15 Ağu 22:17

Man, I’ve been through exactly the transition you described, bro. Up until last year I was only doing frontend with React/TypeScript, and now I’ve suddenly dived into Kotlin Multiplatform (KMP). We started out mobile‑first anyway, but when desktop support was needed I was genuinely surprised how smoothly JetBrains’ toolchain lets you get things up and running. Getting used to the command line and being able to use KMM (Kotlin Multiplatform Mobile) without being tied to the same C++ libraries on both Android and iOS is such a relief, damn. Sharing the UI with Compose also sped up our move to the web. When we moved all the business logic into a shared module, on the web side we only need to write the presentation layer in React on Next.js now. As you said, expanding toward desktop—especially when targeting the JVM—sometimes makes the build times annoyingly long. Still, for people moving to the web this is a huge convenience, because you can even pull your backend DTOs into the shared module and keep type safety across every platform. Even the React devs on my team have started picking up a bit of Kotlin and can now call functions in the shared module in a type‑safe way—big step forward. Looking ahead, if JetBrains can iron out these performance issues, I think KMP will become the one‑stop shop for mobile, web, and desktop.

15 Ağu 23:36

If you're coming from the React Native world like I did, Kotlin Multiplatform (KMP) feels like a breath of fresh air with its native performance and deeper ecosystem. The Java/Kotlin interop is a game-changer compared to JS bridges in RN—no more "bridge latency" headaches when crossing to native modules. I’ve been using it to share core business logic between Android and iOS in a fintech app, but the new desktop/web targets? Game-changer. Flutter fans might argue it’s more mature for cross-platform UI, but KMP’s strength isn’t just "write once run anywhere"—it’s "write once share critical logic everywhere" with minimal overhead. The compiler tooling is still catching up to Flutter’s hot reload, but the native integration (especially with Jetpack Compose) beats any other hybrid approach I’ve tried.

15 Ağu 23:55

When I switched to Kotlin Multiplatform, I started my project on Android first, then expanded to iOS and web. Man, bro, at the beginning I was stressing a lot wondering “will the performance drop?” but with JetBrains’ latest updates the desktop builds turned out to be pretty stable. I was especially blown away by how easy it is to run the same code on the web when using Compose Multiplatform, and I didn’t have to mess with any JavaScript‑specific settings again. The biggest challenge I faced moving from mobile to web was figuring out how to adapt touch events to mouse/keyboard events. But after Kotlin/Wasm support arrived, I ran into almost no problems. Looking ahead, I think performance and tool‑chain stability will keep improving, so developers will be able to comfortably target all platforms from a single codebase.

16 Ağu 02:52

For those who have transitioned to the web, what are the biggest problems you've encountered using Multiplatform? For example, how does writing the same code for multiple platforms affect the development process?

16 Ağu 03:20

Dude, I was checking out the Multiplatform updates from KotlinConf and I’m seriously impressed! Getting a toolchain straight for desktop and web builds feels like a game‑changer. My project is still mostly mobile‑focused (Android + iOS), but lately I’ve started experimenting with Multiplatform for a simple React‑based web UI too. The biggest win when moving to the web is that we can share almost 90 % of the backend code compared to React Native or Ionic. My teammates who moved from mobile to web felt the same, honestly! I can see a future where Multiplatform lets us manage every platform outside of mobile with a single codebase—especially if Kotlin keeps moving at this pace.

16 Ağu 04:28

Haha, honestly I haven’t even gotten past “Hello World” yet, but now I’ve heard about Kotlin Multiplatform’s desktop web compiler 😱 is my “Hello World” program finally going to expose its flaws? 😅 I thought I’d just switch from mobile to web, but in my project I still have to take three lessons just to print “Hello” 😭

16 Ağu 06:57

I've been using Kotlin Multiplatform (KMP) for a small news project for a few months now, and honestly, buddy, adding desktop support really made my life easier! I used to write shared code only for Android and iOS, but now that I also compile the JS backend from the same shared module, the deployment process is a one‑click job. Thanks to the desktop/web support that JetBrains brought with Compose Multiplatform, I can compile to three platforms at once with almost no UI changes. How it works is basically this: after adding the targets with `kotlin { macos(), mingwX64(), js { browser { } } }`, I handled the platform‑specific code using the `expect/actual` pattern. The best part is that the error messages you get are platform‑specific, so you can apply a fix directly for the platform you're on. When I moved the project to the web, it felt great to keep the same type safety instead of wrestling with TypeScript. That's a huge advantage for teams with multiple developers, because everyone speaks the same language. The only downside is that the web side didn't perform as well as I'd hoped, so I had to tweak the code compiled to JS a bit. Still, I think it's a promising tool—its stability is a bit debatable right now, but with JetBrains' speed I expect it to improve soon. For teams transitioning from mobile to web, I can say KMP saves a serious amount of time.

16 Ağu 07:36

In my opinion Kotlin Multiplatform is turning into raki—once you get into it, you can’t quit. About a year ago I had a tiny project that was purely mobile (Android/iOS), you know, just looking for something. Honestly, I tried it on desktop, got the desktop app working with the latest JB fuel, and then decided to ship it to the web as well. It was mobile‑only before, but I already had a Spring Boot backend written in Kotlin. When I switched to Multiplatform I moved everything into a shared module, and with just a few tweaks the build config could also compile for desktop and web. Adding web as a target didn’t even take five minutes. Now my project runs 10 % on mobile, 30 % on desktop, and 60 % on the web. The web performance is especially satisfying—thanks to the shared code there’s almost zero overhead. The best part is, I’m an iOS developer, but if a desktop build shows up, no worries, everything was already in the same system. As for the future, I really think that in three years “mobile‑first” will be replaced by “multiplatform‑first”. You’ll see—within a year you’ll be able to generate apk/ipk/aar/zip directly from Android Studio, and, hell with Electron, a native desktop app will be built automatically too.