By Swift 6.3, released March 24, ships the first Android SDK maintained by Apple’s own Android Workgroup — not a community hack, not an experimental flag buried in the release notes. iOS developers can now compile Swift packages for Android, and Kotlin teams can call into Swift code via JNI without cobbling together unofficial toolchains. The caveats are real and worth knowing. But the era of Swift being an Apple-only language is over.
What “Official” Actually Means
The Swift community has had unofficial Android support for years. Passionate contributors ran builds, filed bugs, and maintained toolchain patches as a labor of love. Swift 6.3 changes the status of that work: the Android Workgroup, backed by Apple, moved Android support from nightly previews to a first-class SDK release. It ships with three components: the Host Toolchain (the Swift compiler targeting Android), the Swift SDK for Android (libraries, headers, and resources), and a dependency on the Android NDK.
That workgroup endorsement matters more than it sounds. The Swift Package Index already shows over 25% of packages successfully building for Android. Package authors are declaring Android support. That kind of ecosystem movement does not happen around experiments — it happens around things people believe will stick.
How the Swift 6.3 Android SDK Actually Works
The SDK is designed for one primary scenario: sharing Swift business logic between iOS and Android, while keeping native UIs on each platform. Think data models, networking layers, cryptographic utilities, domain logic — anything you would otherwise maintain twice.
The mechanics are straightforward. You write Swift, compile it with swift build --swift-sdk android-arm64, and get a native .so shared library. A Kotlin app loads it via System.loadLibrary(). The part that would historically require painful JNI boilerplate is handled by swift-java, a tool that reads your Swift code at build time and auto-generates the JNI bindings.
// Swift side — your shared library
public func parseConfig(_ json: String) -> Config { ... }
// Kotlin side — swift-java generated, called as normal Kotlin
System.loadLibrary("MyLib")
external fun parseConfig(json: String): ConfigThe official getting-started guide on swift.org walks through the full setup. The experience is command-line heavy; there is no Xcode for Android. Debugging with LLDB on Android is not the same as debugging in Xcode — it works, but it requires more terminal comfort than most iOS developers are used to.
What You Cannot Do Yet
There is no SwiftUI for Android. The user interface lives in Kotlin and Jetpack Compose, full stop. Swift writes the logic; Kotlin owns the screen. If you were hoping to share UI code, the answer in 6.3 is still no — though the community project Skip is attempting to address this, with mixed but improving results.
The swift-java interop library has not hit v1.0, which means API stability is not guaranteed. Treat it as production-viable for simple interop cases, but hold off on building deeply against its internals until the v1.0 release. Documentation, while improving, is community-built in real time — expect gaps.
C Interop and Embedded Swift: The Bigger Picture
The Android SDK is the headline, but Swift 6.3 also ships two features that push the same narrative — Swift as a general-purpose systems language — beyond mobile.
The new @c attribute lets you expose a Swift function or enum directly to C. Combine it with @implementation and you can write a Swift implementation for an existing C declaration, with the compiler verifying the C declaration exists. This matters for Android NDK interop (which is C-based), embedded development, and any project where Swift needs to coexist with a C codebase.
Embedded Swift officially exits experimental status in 6.3. The InfoQ analysis covers the full scope, but the highlights are better LLDB debugging for embedded targets, a svd2swift tool that generates Swift MMIO interfaces from microcontroller SVD files, and confirmed support on ARM, RISC-V, and ESP32-C6. Swift is now a serious option for firmware alongside C and Rust — not a replacement, but a legitimate choice for teams who prefer its type system.
Swift on Android vs Kotlin Multiplatform
The obvious question: if you are sharing business logic across iOS and Android, why choose Swift over Kotlin Multiplatform?
The honest answer is that they serve different starting points. KMP has been production-stable since late 2023 and is in production at Netflix, McDonald’s, and VMware. If you are an Android-first team looking to add iOS coverage, KMP is clearly more mature. Swift on Android is for the mirror-image situation: an iOS-first team with existing Swift code that needs Android coverage without a full Kotlin rewrite of the business layer.
Neither approach shares UI code. Both share logic. The choice comes down to which side of the codebase you trust more. Jacob’s Tech Tavern has a thorough comparison if you want the detailed breakdown.
Getting Started with Swift 6.3 on Android Today
Install Swift 6.3 from swift.org, install the Android NDK, and follow the official getting-started guide. Add Android as a supported platform in your Package.swift, run the build command, and drop the resulting .so into your Android project. Expect to spend time on toolchain setup — this is not a one-click install yet.
For teams with significant Swift business logic that needs to run on both platforms, 6.3 is the version worth evaluating. For everyone else, it is worth tracking: the Android Workgroup is active, the ecosystem is building, and Apple is treating this as a long-term investment — not a side project.
