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.