Kotlin Multiplatform (KMP) Solidifies as the Enterprise 'Middle Ground' Standard

Host: Alex Chan Guest: Marco Rossi (Senior Mobile Architect and Lead Engineer at a global fintech firm) Host: Hey everyone, welcome back to Allur. I’m your host, Alex Chan, and today we are diving deep into a topic that has been the cause of many, many long nights for engineering leads: the mobile development dilemma. For basically a decade, if you were building a high-stakes enterprise app, you had two choices. You could go "Full Native"—which meant hiring two separate teams for Swift and Kotlin, which is expensive—or you could go "Cross-Platform" with something like React Native or Flutter. But, as many of us know, those often came with performance trade-offs or that "not-quite-right" feel that users hate. Host: Joining me today is someone who has lived through the trenches of both native and hybrid development. He’s currently leading the mobile architecture at one of the biggest fintech platforms in Europe and has been migrating their legacy systems to KMP over the last year. Please welcome Marco Rossi to Allur! Marco, it is so great to have you here. Guest: Thanks, Alex! It’s a pleasure. Honestly, I’ve been waiting for us to have this specific conversation because the "vibe shift" in the industry regarding KMP over the last twelve months has been just... incredible to watch. Host: Right? It feels like we’ve finally stopped arguing about "write once, run anywhere" and started talking about "share what’s smart." But before we get into the weeds, Marco, you’ve been in this game a long time. You saw the PhoneGap era, the React Native boom... why does KMP feel different to you as an architect? Guest: (Laughs) Oh man, don't remind me about PhoneGap. Look, the difference is the philosophy. Previous frameworks tried to hide the platform from the developer. They said, "Hey, don't worry about iOS or Android, just write this JavaScript or Dart and we'll handle the rest." But the "rest" is where the bugs live. KMP does the opposite. It says, "Keep your native UI, keep your platform-specific features, but let’s stop writing the same JSON parser and the same encryption logic twice." It’s decoupling the *brain* of the app from the *face* of the app. Host: I love that—the brain versus the face. And it seems like the industry is finally taking it seriously. I was reading that the "experimental" tag is officially gone. Is it actually ready for the big leagues? Like, if I’m a CTO of a Fortune 500 company, can I trust this for 2026? Guest: Absolutely. And that’s not just my opinion. Look at the ecosystem. JetBrains is all-in, and Google—this is the big one—is actually integrating KMP into the Android Jetpack libraries. When Google starts making their core libraries multiplatform-compatible, the "insurance" problem is solved. You’re not betting on a fringe library anymore; you’re betting on the future of the Android ecosystem itself, which just happens to run beautifully on iOS too. Host: Let’s talk about that "running on iOS" part. One of the biggest criticisms of cross-platform tools has always been the "bridge." You know, that slight lag when JavaScript has to talk to the native side. How does KMP dodge that? Guest: This is the "aha!" moment for most engineers. KMP doesn't use a bridge. When you compile Kotlin for iOS, it uses the LLVM compiler backend to turn that code into a native binary. It’s the same type of binary that Swift produces. So, there’s no virtual machine, no JavaScript engine running in the background. The performance is, for all intents and purposes, indistinguishable from pure native code. Host: Wait, so if I’m an iOS user, I literally can’t tell if the networking logic was written in Swift or Kotlin? Guest: Precisely. You get the execution speed of native but the maintenance efficiency of a shared codebase. In our latest project, we’re seeing about 70% code reuse. We share the data persistence—using SQLDelight—and the networking—using Ktor. But when the user swipes a list on their iPhone, they’re interacting with a 100% native SwiftUI component. It’s the best of both worlds. Host: That sounds like a dream for QA teams too. I mean, if you fix a bug in the "brain," it’s fixed for everyone? Guest: Exactly! Um, actually, that’s been the biggest ROI for us. In the old days, we’d find a bug in the way we calculated currency conversion on Android, fix it, and then... three weeks later, we’d realize the iOS team never got the memo, or they implemented the fix slightly differently. With KMP, there’s a Single Source of Truth. If the business logic is right in the shared module, it’s right everywhere. It takes so much pressure off the QA lifecycle. Host: I want to touch on "Compose Multiplatform." For a while, KMP was strictly for logic. But now we’re seeing UI sharing too. How does that fit into this "middle ground" strategy? Guest: It’s all about flexibility now. This is the "2026 Standard" part of the conversation. Before, it was "all or nothing." Now, an enterprise team can choose their level of abstraction. If you’re building a high-end consumer app, you might use Shared Logic with Native UI. But what if you’re building an internal tool for your sales force? You don't need two custom UIs for that. You can use Compose Multiplatform to share the UI across iOS and Android and save a massive amount of time. Host: It’s like a slider. You can slide between "Maximum Performance" and "Maximum Speed" depending on the feature. Guest: Exactly. And it’s great for "brownfield" projects. Most big companies aren't starting from scratch. They have these massive legacy apps. You can’t just tell a stakeholder, "Hey, we need six months to rewrite this in Flutter." They’ll laugh at you. But with KMP, you can say, "We’re going to migrate just this one new feature, or just the authentication module, to KMP." You can move incrementally. It’s low-risk, high-reward. Host: I’ve heard some pushback, though, regarding the "silo" issue. Does this mean the end of the "iOS Developer" as a career? Guest: (Laughs) No, not at all! In fact, I think it makes the role better. Instead of the iOS team spending 40% of their time writing boilerplate API calls and data models—which, let's be honest, is boring—they can focus on the stuff that actually matters to Apple users. They can focus on ARKit, or Live Activities, or making the UI animations feel buttery smooth. It turns "platform specialists" into "experience specialists." Host: That’s a really positive way to look at it. It’s less about losing your identity as a Swift dev and more about delegating the "plumbing" to the shared layer. Guest: Right. And let’s talk talent. Kotlin is already the standard for Android. Most backend devs know a bit of Java or Kotlin too. So you’re tapping into this massive talent pool. You’re not hunting for someone who knows a niche language that might be gone in five years. Kotlin is here to stay. Host: Marco, this has been so eye-opening. Before we wrap up, if there’s a lead developer listening who is currently struggling with feature parity between their two native teams, what’s the first step they should take with KMP? Guest: Start small. Don’t try to rewrite your whole app. Pick a standalone piece of logic—maybe your validation rules or a new API service—and write it in a KMP module. Hook it up to your existing Swift and Kotlin apps. Once the team sees that "aha!" moment where the code just works on both sides without a performance hit, the momentum will build itself. Host: Start with the plumbing, then move to the brain! Marco, thank you so much for sharing your expertise. This has been a fantastic look into the future of mobile. Guest: Thanks for having me, Alex. It’s an exciting time to be building! Host: It really is. Key takeaways for today: KMP isn't just a trend; it's a strategic move to resolve that age-old native vs. cross-platform conflict. By sharing the logic and keeping the UI native, companies are hitting that 2026 standard of efficiency without sacrificing the user experience.