The Maturity of Compose Multiplatform: Achieving Stable iOS Support

Guest

Thanks so much for having me, Alex! I’ve been listening to the show for a while, so it’s actually really cool to be on this side of the mic.

Host

Oh, that’s awesome to hear! So, Maya, let’s jump right in. The word "Stable" gets thrown around a lot in tech. Sometimes it just means "we’re tired of calling it beta." But for Compose Multiplatform on iOS, this feels… different. What does "Stable" actually look like on the ground for a developer?

Guest

You’re totally right. In this case, "Stable" is a huge relief. It’s less about being "bug-free"—because, let's be honest, what software is?—and more about API longevity. For the last year or so, those of us playing with the experimental version were always a little bit on edge. You’d update a version and suddenly your layout logic would just… pop.

Host

Right, because no one wants to explain to their CTO why they have to rewrite the entire UI layer because a library changed its mind, right?

Guest

Exactly! And it’s not just the APIs. The performance side of "stable" is where I think people are going to be most surprised.

Host

Let’s talk about that. Because performance is usually where cross-platform tools hit a wall. People complain about that "uncanny valley" feeling—where a button doesn't quite click right or the scrolling feels… heavy? How does Compose Multiplatform dodge that?

Guest

It’s actually really interesting how they do it. So, unlike React Native, which uses a bridge to talk to native components, or a WebView which is basically a browser in a box, Compose Multiplatform uses a rendering engine called Skia—specifically via Skiko. On iOS, it hooks directly into Metal, which is Apple’s hardware acceleration API.

Host

Oh, so it’s drawing directly to the screen?

Guest

Exactly. It’s bypassing the traditional UIKit overhead for the drawing part, which allows it to hit that buttery smooth 60 or even 120 FPS on ProMotion displays. But—and this is the "aha moment" for me—they’ve spent a ton of time on the "feel." Early on, the scrolling didn't have that classic iOS "rubber-banding" effect. You know, when you hit the bottom of a list and it bounces?

Host

Yes! If that’s missing, the app just feels "off" immediately.

Guest

Right! It feels like a web app. But the stable release has baked in those physics. The text selection, the gestures, the scrolling—they’ve mapped them to match Apple’s Human Interface Guidelines. I’ve shown apps to iOS-only users, and they honestly can't tell it's not a native SwiftUI app. It’s that good.

Host

That’s impressive. Now, I saw some news recently about the Kotlin Foundation expanding. Meta and Block—which was Square—joined as silver members. That feels like a massive vote of confidence. Does that actually change anything for the individual developer, or is that just corporate posturing?

Guest

Honestly, I think it’s huge for the ecosystem. When companies like Meta and Block invest, they aren't doing it for charity. They’re doing it because they are using this stuff at a massive scale. They’re dealing with huge build speeds and complex dependency graphs.

Host

It’s funny you mention the libraries. I remember when KMP was first pitched, it was very much "share your logic, but build your UI twice." Use Compose for Android, SwiftUI for iOS. But now we’re looking at "Compose Once." Is that actually a viable workflow now?

Guest

It really is. I call it the "unified workflow." You can define your UI state and your layout in one Kotlin file, and it just works. I’ll give you a real-world example from a project I just finished. We had a complex "Settings" screen with tons of toggles, nested menus, and validation. In the old days, I’d write the logic once, then spend three days making the Android XML or Compose look right, and another three days in SwiftUI. Now? I do it once in a shared module.

Host

Oh, wait, so it’s not an "all or nothing" thing? You can mix and match?

Guest

Absolutely. You can wrap a UIKit component in Compose, or—if you’re working on an existing iOS app—you can export a Compose view as a `ComposeUIViewController` and just drop it into your Swift code. It’s incredibly flexible. You can start small, maybe just one shared screen, and grow from there.

Host

That sounds like a game-changer for teams that are maybe a little hesitant to jump into the deep end. But I have to ask… the elephant in the room is Flutter. Flutter’s been doing the "draw your own UI" thing for years. Why would a team choose Compose Multiplatform over something like Flutter or React Native at this point?

Guest

It really comes down to the language and the ecosystem. If you’re an Android dev, you already know Kotlin. You don't have to learn Dart. But more than that, Kotlin is just a very "safe" language. It’s concise, it’s modern, and the interoperability with Java and Swift is much more seamless than what you get with a JavaScript bridge or Dart’s FFI.

Host

That makes so much sense. It’s about reducing that friction.

Guest

Exactly. And because it’s Kotlin, you’re not just limited to mobile. The same UI logic you’re using for that iPhone app can, in theory, be brought over to a Desktop app or even the Web via WebAssembly. iOS was the hardest nut to crack, and now that it’s stable, the sky’s the limit.

Host

It’s such an exciting time to be in this space. I mean, we’ve been waiting for this level of maturity for a long time.

Guest

We really have. It feels like the "experimental" phase of our careers is finally paying off!

Guest

Thanks for having me, Alex! It was a blast.

Host

If you’re listening and want to dive deeper, I’ll have links in the show notes to the official JetBrains announcement, some great starter templates for Compose Multiplatform, and where you can follow Maya’s work.