Swift on Android, part 1: what the official SDK does and how it differs from KMP

I ship an app on Kotlin Multiplatform, and when I counted the lines, the shared Kotlin code turned out to be just 14% of the codebase. So here's the question I keep asking myself as an iOS developer: what if the shared code had been Swift running on Android, instead of Kotlin running on iPhone? Since Swift 6.3 that's an officially supported option.

This is part 1 of a three-part series. Here I cover what actually shipped, how it works, what's in the Swift SDK for Android and what isn't, and how it compares to KMP feature by feature. Part 2 is hands-on, and part 3 is an honest side-by-side on a real app.

Why I care

MyCarCode, my car maintenance log, is built with Kotlin Multiplatform: shared logic in Kotlin, native UI on both sides (SwiftUI and Jetpack Compose, each with its own Flux stores). At build 8 I counted:

• shared Kotlin code (commonMain): 1,574 lines
• iOS UI and stores: ~9.8k lines of Swift
• Android UI and stores: ~9.6k lines of Kotlin

That's roughly 14% shared code. For that 14% I paid with a second language on the iOS side, Gradle running inside the Xcode build, and a long fight with Firebase linking. If I mentally write the logic in Swift anyway, maybe Swift should be the one traveling.

What shipped and when

• June 2025. The Swift project announced the Android Workgroup.
• October 24, 2025. First nightly previews of the Swift SDK for Android on swift.org.
• March 24, 2026. Swift 6.3: the "first official release of the Swift SDK for Android."
• September 15, 2026. Swift 6.4, a day after Xcode 27. The getting-started guide currently targets SDK 6.4.1.

Important: this isn't Apple shipping Swift for Android. It's the open-source Swift project and its workgroup. SwiftUI, UIKit and Apple frameworks don't come along.

How it works

The SDK is a cross-compilation kit. You write a regular Swift package on macOS or Linux, and swift build targets Android instead of macOS. It relies on the Android NDK (the guide asks for LTS r30). The examples use aarch64 (devices) and x86_64 (emulator) with API level 23.

# 1. Swift toolchain matching the SDK version
swiftly install latest

# 2. The Android SDK itself
swift sdk install <archive-url> --checksum <sha256>
swift sdk list   # swift-6.4.1-RELEASE_android

# 3. Android NDK r30
export ANDROID_NDK_HOME=$PWD/android-ndk-r30

The output is a native .so per architecture. It isn't an app on its own: the app stays a regular Kotlin/Java Android project, the library ships inside the APK, and Kotlin calls into Swift through swift-java, the official bridge and code generator that produces Java wrappers over JNI.

It's a mirror image of KMP. In KMP, Android is home and Kotlin travels to iPhone as a native framework talking to Swift through Objective-C headers. With the Swift SDK, iOS is home and Swift travels to Android, talking to Kotlin through JNI.

What's in the box

• The whole language. Same Swift 6.4 compiler, strict concurrency, async/await, actors, macros. No "lite dialect."
• Standard library and Foundation. Dates, strings, Codable, JSON. Networking (URLSession) lives in FoundationNetworking off Apple platforms and is imported explicitly.
• Swift packages. Anything that already builds on Linux and doesn't pull in Apple frameworks has a good chance of building for Android.
• A two-way bridge. swift-java can call Swift from Kotlin and Java classes from Swift. Async Swift functions surface in Java as CompletableFuture.
• Real-world proof. Skip Fuse builds whole SwiftUI apps for Android on top of this same official SDK.

What's missing

• UI. No SwiftUI or UIKit on Android. Screens are Jetpack Compose; Swift stays under the hood (unless you adopt Skip and its rules).
• Apple frameworks. SwiftData, Core Data, StoreKit, HealthKit, Combine stay on iPhone.
• Service SDKs in Swift. Firebase, Google Sign-In, payments have Kotlin libraries for Android and Swift libraries for iOS, but no Swift build for Android. From shared Swift code you reach them through the Java bridge or Skip's wrappers. For MyCarCode, whose whole data layer sits on Firestore, this is the big one.
• Comfortable debugging. It's a stated workgroup goal, but "set a breakpoint in Android Studio and step into Swift" isn't there yet. From the Android side the debugger sees generated Java wrappers.
• A mature bridge. Early adopters report that every Swift error reaches Kotlin as a plain java.lang.Exception, and swift-java has open issues around async functions with generic results.

Swift SDK vs. KMP, feature by feature

This is based on documentation and other people's experience, not my measurements. My numbers come in part 3.

	Swift SDK for Android	Kotlin Multiplatform
Shared language	Swift	Kotlin
Status	Official since Swift 6.3 (March 2026)	Stable since November 2023
Home platform	iOS (Android is the guest)	Android (iOS is the guest)
Guest artifact	Native .so per ABI inside the APK	Native .framework via Kotlin/Native
Language bridge	swift-java over JNI, generated Java wrappers	Objective-C headers, SKIE, experimental Swift export
Async	async → CompletableFuture in Java	suspend → async/await in Swift (via SKIE)
Errors	Arrive in Kotlin as java.lang.Exception	Without @Throws, an exception crashes the iOS app
Shared UI	None (only via third-party Skip)	Compose Multiplatform, stable on iOS since 2025
Libraries	Swift packages that build off Apple platforms	Own ecosystem: Ktor, kotlinx, Koin, SQLDelight
Firebase in shared code	No native build; bridge or Skip	Yes: GitLive Firebase SDK (unofficial)
Debugging shared code	Good from iOS, weak from Android	Good from Android, weaker from iOS
Fits best	iOS-first teams	Android-first teams

In one sentence: both solve the same problem from opposite shores. Both share logic, not screens (Compose Multiplatform and Skip aside). Both make one platform live with a foreign language and a bridge. The difference is which team feels the bridge, and that KMP has two and a half more years of scars and libraries.

Who should try it now

My preliminary take, before installing anything myself:

• Yes, if you have an iOS app with heavy logic that doesn't depend on services: calculations, parsers, validation, file formats, an offline engine. That code can go to Android nearly as is.
• Yes, if your team is all-Swift and the Android version just needs to exist. Skip on top of the official SDK is the shortest path.
• Not yet, if your shared layer is built on Firebase and other service SDKs. You'll be bridging to their Android versions, and the savings end there. KMP with ready-made wrappers is ahead.
• Not yet, if your team is mostly Android developers who'd have to debug Swift through generated Java wrappers. KMP will feel like home to them.

What's next in the series

Docs tell half the story. They won't tell you how much a Swift library actually weighs inside an APK, how long the first setup takes, or where the bridge breaks on real code rather than "Hello, Android."

In part 2 I install the SDK on my Mac and try to build real logic from one of my apps for Android: actual models and calculations that live on iPhone today. What compiles on the first try, what needs rewriting, how big the result is, and whether I can call it from Compose at all.

In part 3: an honest comparison with KMP on MyCarCode. I kept a full log of what broke when Kotlin moved to iPhone: hand-unpacking Firebase into frameworks, duplicate symbols at link time, a crash caused by one forgotten annotation, and a bug where a screen wouldn't close itself after saving because the Kotlin code resumed on the wrong thread. I'll go through which of those the Swift SDK removes and which it just moves to the other shore.

A spoiler I'm not sure about yet: some of those rakes will turn out to be mirror images. We'll see.

Originally published at klukyanov.ru.

Shorter weekly write-ups (in Russian) — on Telegram.