Kotlin Multiplatform (KMP) Dominance in Shared Logic Architectures

Host: Alex Chan Guest: Marcus Thorne (Lead Mobile Architect at a major fintech firm and long-time KMP advocate) 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, honestly, a bit of a holy grail in the mobile dev world for a long time. We’ve all heard the pitch before: "Write once, run everywhere." For years, that was the dream, right? But if you’ve been in the industry for any length of time, you know that the reality often felt more like... "Write once, debug everywhere," or "Write once and hope the user doesn't notice the UI feels a little bit... off." Host: I am so excited to welcome Marcus Thorne to the show. Marcus is a Lead Mobile Architect with over a decade of experience, and he’s been at the forefront of migrating massive, mission-critical apps from traditional hybrid frameworks over to Kotlin Multiplatform. Marcus, thank you so much for joining us on Allur today! Guest: Hey Alex! Thanks for having me. It’s great to be here. I’ve been a listener for a while, so it’s fun to actually be on the other side of the mic. Host: Oh, that’s awesome to hear! So, Marcus, let's jump right in. You’ve seen the evolution of mobile from the early days. For a while, frameworks like React Native and Flutter were the "it" thing for enterprises. But you’re seeing a shift now toward KMP. Why is that "Write Once, Run Everywhere" UI dream starting to fade in the high-end space? Guest: Yeah, it’s a great question. I think we’ve reached a point of collective honesty in the industry. For a long time, we tried to ignore what I call the "Uncanny Valley" of UX. You know, you build a React Native app, and it’s 90% there, but the navigation transitions feel just a tiny bit sluggish, or the haptic feedback doesn't match the system default, or a scroll view behaves... weirdly. Host: It’s like separating the "how it looks" from "how it works," right? I love that phrase "the invisible brain." Guest: Exactly! Honestly, in a typical app, about 70 to 80 percent of the code is just... plumbing. It’s "fetch this JSON, parse it, save it to a local database, and calculate the tax." That logic shouldn't be written twice. When you write it twice, you get those "platform-specific" bugs where a price is calculated differently on iOS than on Android because someone missed a decimal point in the Swift version but got it right in the Kotlin version. Host: Oh man, I have definitely seen those Jira tickets. "Bug: Android shows $10.99, iOS shows $11.00." Those are the worst to track down! So, for the listeners who might be familiar with Kotlin but haven't touched KMP, how does it actually work under the hood without a bridge? Because React Native uses that bridge to talk to native components, which can be a performance killer. How does KMP avoid that? Guest: This is the "aha!" moment for most devs. KMP doesn't use a bridge or a virtual machine. It compiles directly to platform-specific binaries. When you’re on iOS, your Kotlin code literally becomes an Objective-C framework that Swift can just... talk to. Host: Wait, so it’s like an interface, but at the compiler level? Guest: Exactly! It’s type-safe, and it’s incredibly fast. You aren't serializing data across a bridge; you’re calling native code directly. It means if you need to access the Keychain on iOS or use Bluetooth, you don't have to wait for some third-party plugin maintainer to update a library. You just write the `actual` implementation yourself. Host: That’s huge. I’ve heard so many horror stories about teams being stuck on an old version of a framework because one specific Bluetooth plugin hasn't been updated yet. Guest: Right! It’s the "bridge maintenance tax." KMP effectively eliminates that. You’re back in control of your dependencies. And the ecosystem has matured so much. We have Ktor for networking, SQLDelight for databases—which is amazing because it generates type-safe APIs from your actual SQL—and Kotlin Coroutines for handling all the asynchronous stuff. Host: Speaking of Coroutines... how does that play with iOS? I know iOS devs are very tied to Combine or Async/Await. Does it feel clunky for them to use Kotlin code? Guest: That used to be a pain point, actually. But now, with the newer versions of KMP, a `StateFlow` in Kotlin can be consumed quite naturally in SwiftUI. To the iOS developer, it just feels like they’re importing a native library. They don't even necessarily need to know Kotlin. They just see a function that returns data and they plug it into their SwiftUI views. It keeps the specialists as specialists. Your iOS experts can stay experts in the Apple ecosystem instead of trying to be "hybrid" developers who are okay at both but masters of neither. Host: I think that’s a really important cultural point for dev teams. Nobody wants to feel like their specialized skills are being diluted. So, Marcus, you mentioned the 2026 outlook earlier. Why do you think KMP is the "strategic imperative" for the next few years? Guest: Well, as hardware gets better—foldables on Android, the Dynamic Island on iPhone—the gap between "native-feeling" and "actually native" is getting wider. Users are getting more sophisticated. At the same time, companies are under pressure to be more efficient. Host: Interesting! And what about QA? Does this actually shorten the testing cycle? Because you’re still testing two UIs. Guest: It does! Because while you still test the UI on both, you only have to unit test the "brain" once. You write your test for the `PriceCalculator` in the common module, and it validates that logic for both platforms. You’re catching the most dangerous bugs—the data bugs—before they even touch a screen. It’s a massive confidence booster for the team. Host: I can imagine. No more "it works on my Android but not on his iPhone" for the core logic. Marcus, this has been so eye-opening. Before we wrap up, for someone who’s listening and thinking, "Okay, I want to pitch this to my lead," what’s the one piece of advice you’d give them to get started? Guest: Don't try to rewrite the whole app. That’s the beauty of KMP—it’s additive. Pick one small feature, maybe a new data module or a simple calculation service, build it in KMP, and integrate it into your existing native apps. Let the team see how easy it is to share that logic without breaking the UI. Once they see it in action, the benefits become undeniable. Host: Start small, prove the value. I love it. Marcus, thank you so much for sharing your expertise with the Allur community today. Where can people find you or learn more about your work? Guest: Thanks, Alex! It was a blast. You can find me on LinkedIn or at my blog, where I dive into more technical KMP architectures. I’ll send you the links for the show notes! Host: Perfect, we will definitely include those.