• Android
• App Development

Swift 6.3 and the Android SDK: Is it too late to the party?

Swift 6.3 landed on March 24th, and with it came something I genuinely didn't expect to see: the first official release of the Swift SDK for Android. Not a community hack or a nightly preview – a proper, stable release that lets you compile Swift code to run natively on Android devices.

As someone who works across both iOS and Android daily, and who's been using Kotlin Multiplatform for shared business logic for a while now, my reaction was less excitement and more quiet curiosity. It's an interesting development. But is it a practical one?

What it actually is

The Swift SDK for Android lets you cross-compile Swift code to native Android binaries. You need three things: the Swift toolchain, the Android SDK bundle, and Google's Android NDK. You compile on your Mac or Linux machine, and out comes a native binary for Android.

The interoperability piece is handled by swift-java and swift-java-jni-core, which deal with the JNI bridging between Swift and Java/Kotlin. There are tools that generate bindings automatically, and Swift macros like @JavaMethod for calling Java from Swift. The intent is that you take your existing Swift packages and plug them into an Android app that still uses Kotlin or Java for its UI.

SwiftUI is not part of this. Your Android UI stays as Jetpack Compose or whatever you're already using. This is about sharing logic, not sharing screens. At least for now.

How we got here

Swift has been open source since 2015 and has gradually expanded to Linux, Windows, WebAssembly, and embedded systems. Android was always the obvious gap.

People had been making it work unofficially for years with patched compilers and custom toolchains, but it was brittle and a maintenance headache. The formal effort started in June 2025 when the Android Workgroup was created on the Swift Forums, with a clear goal of making Android an officially supported platform.

By October 2025 there were nightly preview builds. The Swift Package Index started tracking Android compatibility and found that over 25% of packages already compiled without changes. Then Swift 6.3 made it official.

The KMP comparison

The overlap with Kotlin Multiplatform is obvious. Both enable sharing business logic between iOS and Android while keeping native UI on each platform. Both compile to native code. Both handle interop with the other platform's ecosystem.

The difference is direction. KMP says: write shared logic in Kotlin, consume it from Swift on iOS. The Swift SDK says: write shared logic in Swift, consume it from Kotlin on Android. Mirror images of each other.

At Brightec we're a multi-disciplinary team – our developers work across Swift, Kotlin, and React Native, and everyone has knowledge of both native platforms. We use either KMP or React Native for cross-platform work. From that perspective, KMP has a massive head start. It went stable in late 2023. Companies like Netflix, Cash App, and Duolingo are using it in production. The tooling is mature, the documentation is solid, and the ecosystem has had years to develop.

The Swift SDK, by contrast, is brand new. There's no Android Studio integration. Debugging support is limited. The developer experience reports from people who've actually tried building with it suggest it's not particularly smooth from a workflow perspective yet. One developer who did a detailed comparison described KMP as "well-documented, mature, and relatively painless" while noting the Swift SDK still needs time in the oven.

Shared logic is nice, but is it the end goal?

Here's the question that interests me more than the Swift vs KMP comparison: is "shared business logic with native UI" actually where these projects want to end up, or is it just the first step?

Because Kotlin has already moved past it. Compose Multiplatform hit stable for iOS in May 2025 with version 1.8.0, and it's now on 1.10.0. That means you can write your UI once in Compose and have it render natively on both Android and iOS. Not just the logic layer — the actual screens. Companies are shipping it in production. JetBrains reports that over 96% of teams using it on iOS have no major performance concerns. The scroll physics match native SwiftUI. It draws its own pixels via Skia and Metal rather than translating to UIKit components.

KMP went from "share your business logic" to "share everything if you want to" in a relatively short space of time. The progression felt natural – once you've got the logic layer sorted, the UI layer is the next logical step.

So where does that leave Swift? The Android Workgroup has been clear that cross-platform UI is not on their roadmap. Their vision document focuses on logic sharing, debugging improvements, IDE integration, and package compatibility. The UI story is being left to community projects like Skip, which transpiles Swift and SwiftUI into Kotlin and Jetpack Compose. Skip went fully open source in January 2026, and its creator is part of the Android Workgroup. But it's a separate effort, not an official one.

This feels like a significant gap. Kotlin's cross-platform story now covers both logic and UI through official, well-supported channels. Swift's official story covers logic only, with UI depending on third-party tools that have their own limitations and trade-offs. Skip's transpilation approach is clever, but it comes with constraints around Swift language support and the inevitable friction of converting between two different type systems.

Is Swift already too late?

KMP had roughly an eight-year head start on the logic-sharing front. Compose Multiplatform is already stable for shared UI. React Native and Flutter have been doing cross-platform for years. The Swift SDK arriving in 2026 is, by any measure, late.

The argument in its favour is that for teams with large existing Swift codebases, being able to share that code directly with Android without rewriting it in Kotlin has real value. And that's true. But most teams doing cross-platform work have already made their choice and invested in the tooling around it. Switching costs are real.

There's also the question of who this is actually for. If you're an iOS-only team looking to expand to Android, the Swift SDK gives you a path. But if you're already doing both platforms – which most teams are – you've likely already solved this problem with KMP, React Native, or Flutter. The window where this would have been transformative was probably five years ago.

Worth watching, not worth switching

For us at Brightec, this is something we're keeping an eye on rather than something we're planning to adopt. Our KMP and React Native workflows are established and working. The Swift SDK would need to mature considerably – better IDE support, smoother debugging, a more compelling answer to the UI question – before it would make sense to evaluate it seriously against what we already have.

The broader picture is more interesting than the immediate practical implications. The fact that both Kotlin and Swift are independently pursuing cross-platform strategies suggests this is where mobile development is heading generally. But Kotlin is further along that path, with a more complete story that covers both logic and UI. Whether Swift can close that gap, or whether the Android Workgroup's decision to leave UI to the community means it never will, is the thing worth watching over the next couple of years.

The mobile development landscape has another option now. That's not a bad thing. But right now, it's an option with a lot of catching up to do.

If you’re exploring Kotlin Multiplatform, how you structure your project makes a big difference in practice – we’ve broken down the main approaches here.