Swift Android SDK or KMP? The Shared-Core Decision

You want to set up a shared core on the Android side, and there are two realistic paths in front of you: write the business logic in Kotlin with Kotlin Multiplatform (KMP) and compile it to both iOS and Android, or put Swift at the center and bring it to Android via the Swift Android SDK. Both promise the same philosophy (shared core + native UI), but their maturity levels, toolchains, and interop quality differ a great deal. This article is a technical-architectural decision guide between the two options — not a hiring guide, a cost table, or a five-way comparison.

💡 Pro Tip: Before deciding, ask "which side is already mature" — in KMP, a shared Kotlin core plus native Swift/Compose UI is a pattern that's years old, while the Swift Android SDK is built on an interop layer that hasn't reached 1.0 yet and offers no API stability guarantee.

Table of Contents

• The Decision Context: What a Shared Core Solves
• Maturity: Toolchain, Documentation, Community
• Kotlin Release Cadence
• Interop Quality: Swift Export or Swift-Java
• Build Time and Binary Size Expectations
• The Debuggability Gap
• UI Layer and the Impact of Team Composition
• Impact of Team Composition on the Decision
• A Clear Choice for Four Team Scenarios
• Decision Matrix
• FAQ
• Should you choose the Swift Android SDK or KMP?
• Which one is more mature for a shared core?
• If the team knows Swift, is KMP still needed?
• When will Swift export move to Beta?
• Are the Swift-Java libraries on Maven Central?
• Update (September 2026)
• Conclusion
• Sources

The Decision Context: What a Shared Core Solves

The shared-core decision is usually made to avoid writing business logic, the network layer, the data model, and validation rules twice across two platforms. The UI layer stays native (SwiftUI + Jetpack Compose); only the "platform-independent" layer is shared. The real question to ask is: which language will the shared core be written in, and how frictionlessly does that language's compiler move to the other platform?

In KMP, the answer is clear: Kotlin/Native compiles Kotlin code directly to a native iOS binary via an LLVM-based compiler, and it's been in production for years. With the Swift Android SDK, the answer flips: your Swift code is ported to Android, but Android's ecosystem (Jetpack, Kotlin libraries, Gradle) is built on Kotlin/Java — meaning Swift is a "guest." This asymmetry sits at the center of the decision: in KMP, shared code is at home wherever it goes; with the Swift Android SDK, it has to integrate into a foreign runtime.

Both sides embrace the "shared core + native UI" philosophy; the difference lies in which platform the core is "native" to and which platform it's a "guest" on. If most of your team knows Swift, the Swift Android SDK might look appealing, but as you'll see later in this article, the maturity gap largely overrides that preference.

Maturity: Toolchain, Documentation, Community

Kotlin Multiplatform sits on JetBrains's official release calendar: language versions ship every six months, and tooling versions ship roughly three months after the language version (kotlinlang.org/docs/releases.html). Kotlin 2.4.0 was released on June 3, 2026, and that date is listed on the same release page.

Android support on the Swift side is much younger: the first official Swift SDK for Android arrived with Swift 6.3 on March 24, 2026 (swift.org/blog/swift-6.3-released). So while KMP's native-iOS compiler has been maturing for years, Swift's native-Android compiler was only born in the first quarter of 2026. This isn't a "years of experience" gap so much as a "which direction got prioritized" one — JetBrains has spent years bringing Kotlin to iOS, while the Swift Android Workgroup only moved from nightly previews to a first official release on March 24, 2026.

Swift's platform support page confirms the same picture: Android is listed in the minimum deployment version table as "9 (API 28)," but in the "deployment-only" section's debugger/REPL table you'll find macOS, iOS, watchOS, tvOS, the Ubuntu family, and Windows — Android doesn't appear as its own row in that table (swift.org/platform-support). So Android support exists, but it isn't yet treated at the same level as the first-class "deployment-only" platform list.

Documentation and community also show a clear gap: KMP's official kotlinlang.org documentation, sample project templates (the Kotlin Multiplatform Wizard), and IDE integration (IntelliJ IDEA, Android Studio) have been mature for years.

On the Swift Android SDK side, official samples are collected in the swift-java repository's Samples/ directory, but the repo's own README describes the project as "under active development" and offers no API stability guarantee until 1.0 (github.com/swiftlang/swift-java). That doesn't mean "it doesn't work" — it means your first integration builds on an API surface that isn't yet fixed.

Kotlin Release Cadence

Kotlin's own releases page defines the cadence like this: language versions (x.x.0) ship every six months, and tooling versions (x.x.20) ship roughly three months after the language version. At the time this article was published (June 26, 2026), the most current version was Kotlin 2.4.0, released June 3, 2026 — the version in which Swift export moved to Alpha. This cadence shows there's a predictable, regular release rhythm behind KMP; the Swift Android SDK side hasn't yet published a calendar with this level of clarity.

Interop Quality: Swift Export or Swift-Java

Each side has its own interop mechanism, but their statuses differ: as of this article's publication date (June 26, 2026), Swift export is officially Alpha, while Swift-Java is pre-1.0, in active development with no API stability guarantee. On the KMP side, Kotlin is developing a feature called Swift export: it makes the code produced by the Kotlin/Native compiler directly callable from Swift. Kotlin's 2.4.0 release notes describe it verbatim: "Swift export goes Alpha with improved concurrency support."

The known limitations are also clearly stated in the documentation: types deriving from List, Set, or Map are ignored during export (KT-80416), and types that derive from them can't be instantiated on the Swift side (KT-80417). In addition, Swift export currently only works in projects that link the iOS framework to the Xcode project via "direct integration" — this isn't an exceptional mode, it's the standard configuration for KMP projects created through the Kotlin Multiplatform plugin in IntelliJ IDEA or the web wizard. Kotlin's own native-swift-export documentation lists the status as "Alpha" (kotlinlang.org/docs/native-swift-export.html).

On the Swift Android SDK side, the interop burden runs through the Swift-Java and Swift-Java JNI Core libraries. These arrived with Swift 6.3, but as of June 26, 2026, the support libraries swift-java depends on hadn't been published to Maven Central — meaning you had to self-publish them locally to use them in an Android project. That's the opposite of KMP's one-line Gradle dependency: on the Swift Android SDK side, the interop layer itself isn't yet a "packaged dependency" — it's infrastructure you have to build.

1// KMP: shared core, distributed to both platforms with a single Gradle dependency
2// ktorVersion is pinned in gradle.properties; no open range is used
3val ktorVersion: String by project
4 
5kotlin {
6    androidTarget()
7    iosArm64()
8    sourceSets {
9        commonMain.dependencies {
10            implementation("io.ktor:ktor-client-core:$ktorVersion")
11        }
12    }
13}

Build Time and Binary Size Expectations

There's no official, methodologically documented benchmark comparing the two on this axis — neither JetBrains nor Apple has published a "KMP vs. Swift Android SDK build time" report. So instead of a concrete number, it's more honest to explain what the architectural difference means: in KMP, the Kotlin/Native compiler produces a single native binary via LLVM that links directly into the iOS app; no extra runtime bridge. With the Swift Android SDK, Swift code talks to Android's JVM-based runtime through the Swift-Java/JNI layer — an extra serialization/bridging step.

The practical upshot: KMP's build pipeline is optimized for years and predictable in CI; the Swift Android SDK's still sits on a pre-1.0 interop layer, so measure CI time and binary size on your own project — a third-party number isn't reliable yet.

1# KMP: shared framework build for iOS (predictable, optimized for years)
2./gradlew :shared:assembleSharedXCFramework

The Debuggability Gap

Beyond build time, what actually shapes day-to-day development experience is debuggability. In KMP, the Kotlin/Native binary can be debugged directly with Xcode's LLDB because the output is a native binary; you can set breakpoints and step into code. On the Swift Android SDK side, because Swift code runs on Android through the Swift-Java/JNI bridge, telling whether a bug originates on the Swift side or in the bridging layer requires an extra step.

This gap shows up most in the time you spend day-to-day answering "why is this breaking here." In KMP, Kotlin code inside commonMain shows the same runtime behavior on both platforms (same exception types, same coroutine cancellation semantics) — your mental model doesn't change while debugging. On the Swift Android SDK, a bridging layer sits between Swift's error model (throws/Result) and Android's JVM exceptions; since it's still pre-1.0, how readable errors and stack traces stay hasn't been documented at kotlinlang.org's level yet.

For a production-critical core, that uncertainty means you can't know in advance where the risk accumulates — a far more concrete reflection of the maturity gap than build time.

UI Layer and the Impact of Team Composition

The standard recommendation is the same for both options: share the business logic, keep the UI native. In KMP this works smoothly with SwiftUI + Jetpack Compose because the shared Kotlin module looks like a "local library" to both sides. With the Swift Android SDK, the UI decision is more complex: you can keep SwiftUI on the Swift side, but on Android you still write the UI in Jetpack Compose, because Swift has no native UI framework on Android — only the business-logic layer stays in Swift.

This raises a question: if your team already writes Kotlin/Compose, what the Swift Android SDK gains you is just "keeping business logic in Swift" — you still need Kotlin for the UI side. In KMP, the shared layer is already Kotlin, so Kotlin/Compose for the UI is a natural extension.

1// KMP: shared ViewModel, consumed by both SwiftUI and Compose
2class ProductListViewModel(private val repository: ProductRepository) {
3    private val _state = MutableStateFlow(ProductListState())
4    val state: StateFlow<ProductListState> = _state.asStateFlow()
5 
6    suspend fun loadProducts() {
7        _state.update { it.copy(isLoading = true) }
8        val products = repository.fetchProducts()
9        _state.update { it.copy(isLoading = false, products = products) }
10    }
11}

Impact of Team Composition on the Decision

This article isn't a hiring-market or cost comparison — that's a separate piece's scope. What matters here: what depth does your team have in which language, and which technology meets that depth with less friction? An iOS-heavy team might find the Swift Android SDK appealing as "porting the language I know to Android," but as the previous section showed, the Android UI still stays in Compose/Kotlin — so the team needs some Kotlin knowledge either way.

Conversely, for an Android-heavy or full-stack Kotlin team, KMP is a natural extension: the language they already write ports natively to iOS. The decision turns less on "which language do we know" and more on "which platform is the core native to" — and today that answer clearly favors KMP.

A Clear Choice for Four Team Scenarios

• Android-heavy team extending to iOS: KMP. The shared core is already on its native platform; the iOS side is new.
• iOS-heavy team extending to Android: KMP is still recommended — the Swift Android SDK's interop layer is pre-1.0 maturity, which carries risk for a production-critical core; the team should learn Kotlin and keep the shared layer in Kotlin.
• New team starting from scratch: KMP. Building on a layer with a stability guarantee means not taking on risk in your first product.
• Experimental/side project where you can afford the risk: The Swift Android SDK can be worth trying — Swift export is moving fast in Alpha, but it's still early for a production-critical core.

In three of the four scenarios, the clear answer is KMP, because the maturity gap outweighs language familiarity. Even in the fourth scenario, the warning "try it, but don't put it into production yet" still applies.

Decision Matrix

FAQ

Should you choose the Swift Android SDK or KMP?

KMP is recommended for a production-critical shared core, because Kotlin/Native's iOS compiler has been mature for years and the Swift export interop layer was still in Alpha status as of June 26, 2026.

Which one is more mature for a shared core?

KMP is more mature. Kotlin/Native's iOS compiler has been used in production for years; Swift's official Android SDK only arrived for the first time with Swift 6.3 on March 24, 2026 — making it a much younger technology compared to KMP.

If the team knows Swift, is KMP still needed?

Yes, because the UI on Android still stays in Jetpack Compose — the Swift Android SDK only lets you keep business logic in Swift; the interface side still needs Kotlin. If the team is learning some Kotlin anyway, keeping the shared core directly in Kotlin creates less friction.

When will Swift export move to Beta?

As of June 26, 2026, Kotlin's own documentation lists the status as "Alpha," and there's no official Beta date commitment. What you do have is Kotlin's predictable release cadence: language versions every six months, tooling versions roughly three months after the language version.

Are the Swift-Java libraries on Maven Central?

As of June 26, 2026, no — the support libraries swift-java depends on hadn't been published to Maven Central, so you had to self-publish them locally to include them in your project, an extra burden compared to KMP's single-line Gradle dependency.

Update (September 2026)

The body of this article is based on version information current as of June 26, 2026. Nothing happened between June 26 and September 23, 2026 that would shift the decision balance, but there's concrete progress on the Kotlin side:

Kotlin 2.4.20 was released on September 7, 2026, adding three new features to Swift export (kotlinlang.org/docs/whatsnew2420.html): sealed class/interface hierarchies now map to Swift enums and support exhaustive switch + autocompletion in Xcode; "cross-language inheritance" became official — letting you define a contract in Kotlin and write a platform-specific implementation on the Swift side; assembleSharedXCFramework now auto-generates Package.swift for SwiftPM dependencies.

Even so, as of September 23, 2026, Swift export is still officially "Alpha" per kotlinlang.org's own documentation (native-swift-export.html) — so this article's warning against putting it on a production-critical path still holds. There's tooling progress on the Swift side too: the Swift 6.4 (September 15, 2026) release notes give Android its own section, noting the Swift SDK for Android now builds against the new LTS NDK 30 (providing Android availability attributes in both the runtime libraries and default-NDK packages), and that Swift Build now supports Android in SwiftPM, removing the need for a post-install script (swift.org/blog/swift-6.4-released) — exactly the kind of item this article tracks on the tooling-maturity axis. Kotlin 2.5.0-Beta1 (September 23, 2026, EAP) adds nothing new for Swift export. Bottom line: the decision doesn't change, since both interop layers' status stayed the same, but the Swift side isn't standing still.

Conclusion

The decision between the Swift Android SDK and KMP rests less on language familiarity and more on a maturity gap: the platform KMP is native to (iOS) has been in production for years, while Swift's Android support was born in early 2026 and its interop layer is still pre-1.0. In three of the four team scenarios, the clear answer is KMP; even in the fourth, "try it, but don't ship it yet" still applies.

If you want to see your architectural choices in a broader context before finalizing your decision, take a look at our Flutter vs. SwiftUI production comparison or the production experience of Compose Multiplatform on Android+iOS. To see how we use KMP in production through a concrete case, you can read the KMP 1.1 production case study. If you're also wrestling with the SwiftUI vs. UIKit question on the UI layer, our 2026 decision guide and, for solidifying your concurrency foundation on the Swift side, the Swift 6 strict concurrency deep-dive guide will be useful.

Sources

• Kotlin Releases Overview — Kotlin's language and tooling release calendar and the 2.4 release line dates.
• Kotlin 2.4.20 release notes — sealed class/interface Swift export support, cross-language inheritance, and automatic Package.swift generation.
• Swift Export interop documentation — the official Kotlin document that directly defines Swift export's Alpha status and its List/Set/Map limitations.
• Swift 6.3 Released — the announcement of the first official Swift SDK for Android, March 24, 2026.
• Swift 6.4 Released — September 15, 2026 release notes; the Android section covering LTS NDK 30 and Swift Build support in SwiftPM.
• swift-java — the Swift-Java interop repository's project status, its Samples/ directory, and the Maven Central status of its support libraries.
• Swift Platform Support — Android's minimum deployment version and its position in the deployment-only platform table.