Polymarket's Swift-on-Android Success: A New Era for iOS-First Teams with the 'Skip' Toolchain

Host: Alex Chan Guest: Marcus Thorne Host: Hey everyone, welcome back to Allur! I’m your host, Alex Chan, and I am so glad you’re joining us today. If you’ve spent any time in the mobile development world, you know the eternal struggle: the "two-platform" problem. You build this beautiful, complex app in Swift for iOS, and then you look at the mountain you have to climb all over again to get it onto Android. Do you hire a whole new team? Do you rewrite everything in Kotlin? Or do you go "cross-platform" with something like Flutter and maybe lose some of that native magic? Guest: Hey Alex, thanks for having me! It’s a really exciting time to be talking about this. I feel like we’ve been waiting for a "bridge" like this for a long time that doesn't... well, that doesn't feel like a compromise. Host: Exactly! So, let’s jump right in. When I first heard "Swift on Android," my brain immediately went to, "Okay, so it’s like a web view or a wrapper?" But that’s not what’s happening here with Polymarket and Skip, right? What is actually going on under the hood? Guest: Right, it’s definitely not a web view. That’s the first thing people assume. Actually, the way Skip works is fascinating because it’s a source-to-source toolchain. Instead of running a virtual machine or some heavy runtime layer on top of Android, Skip actually *transpiles* your Swift code into Kotlin. Host: Oh! So it’s almost like having a super-advanced universal translator for code? Guest: (Laughs) Honestly, yeah! And the "aha" moment for me was realizing that it’s not trying to do *everything*. It focuses on the logic. Polymarket didn’t try to "transpile" their iOS UI into an Android UI. They kept the UI native. On Android, they used Jetpack Compose, which is the modern way to build Android interfaces, but all the "brains" of the app—the trading logic, the API calls, the state management—all of that is the exact same Swift code they used for the iPhone version. Host: That is so interesting because usually, when we talk about cross-platform, the pitch is "Write Once, Run Everywhere," including the buttons and the sliders. But Skip is saying, "Write the logic once, but keep the buttons native." Why is that a better strategy for a team like Polymarket? Guest: Well, think about the user experience. We’ve all used those apps that feel "off," right? Maybe the scrolling feels a bit heavy, or the buttons don't react quite the way an Android user expects. That usually happens when you use a framework that draws its own UI. Host: I can imagine! I mean, dealing with financial logic and then having to keep two separate codebases in sync sounds like a recipe for a nightmare. But Marcus, there has to be a catch, right? Does it actually perform as well as pure Kotlin? Guest: That’s the question everyone asks! And actually... yeah, it does. Because there’s no "middleman" at runtime. Once the code is transpiled and compiled, it’s just running as native bytecode on the Android device. There’s no performance penalty like you might see with JavaScript-based frameworks where there’s a "bridge" that data has to travel across. Host: That makes so much sense. I was reading a bit about Polymarket’s experience, and they mentioned that their team was very "iOS-centric." It sounds like this toolchain let them scale to Android without having to double their headcount overnight. Guest: Exactly. And that’s a massive business advantage. Hiring specialized talent is expensive and slow. If you have three amazing Swift developers, Skip basically turns them into "Mobile Developers" rather than just "iOS Developers." Host: It really feels like Swift is growing up and leaving the "Apple house." We see it on the server-side with things like Vapor, and now it's making a serious play for Android. Do you think this is going to become the standard for startups? Guest: I think for any team that starts on iOS—which, let’s be real, is most startups—this is going to be a very tempting path. It avoids the "uncanny valley" of cross-platform UI but gives you the efficiency of a single codebase. Host: "From experiment to solution"—I love that. It’s like the "Skip" toolchain finally gave Swift the passport it needed to travel. Guest: (Laughs) Exactly! It’s Swift with a passport. And honestly, the more languages become "portable" like this, the better it is for us as developers. We get to focus on the product and the user experience rather than fighting with syntax differences between `Optional` in Swift and `Nullable` in Kotlin. Host: Such a good point. Well, Marcus, this has been incredibly enlightening. I think a lot of our listeners are going to be headed straight to the Skip documentation after this. Guest: I’d say start small. Take a small logic module—maybe a validation library or some data parsing—and try "skipping" it over to a sample Android project. Seeing your Swift code actually run inside Android Studio for the first time is a bit of a "magic" moment. Oh! And definitely check out the Polymarket engineering blog. They go into some great detail about how they structured their shared logic. Host: Great advice. Marcus, thank you so much for joining us on Allur today! Guest: Thanks for having me, Alex! This was fun. Host: Wow, what a shift in the landscape. I love stories like this because they remind us that tech isn’t static—the tools we use today are constantly evolving to break down the walls between platforms. If you’re an iOS developer feeling the pressure to launch on Android, maybe "Skip" is the bridge you’ve been looking for.