Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

Introduction — "Official SDK" and "Officially Supported Platform" Are Not the Same Thing
Timeline — From Nightly to General Release
How Swift Actually Runs on Android
Installing Three Pieces — Toolchain, SDK, NDK
- The Size Story — Read It Honestly
The Non-Goals the Vision Document States — No UI Is Provided
What's Still Unfinished
That Said, It's Not a Lab Toy
So, Should You Use It
Closing
References

Introduction — "Official SDK" and "Officially Supported Platform" Are Not the Same Thing

Swift 6.3 was released on March 24, 2026. The release notes highlight four items — more flexible C interop (the @c attribute), improved cross-platform build tooling (a preview of Swift Build integration in SwiftPM), improvements to embedded environments, and the first official release of the Swift SDK for Android.

That last item is this post's subject. But it's an easy sentence to misread. This blog's own Modern Swift 2026 roundup wrote that "an experimental toolchain has shipped and hello-world-level things run fine," and that "by around 2027 it could become an option that competes with Kotlin Multiplatform" — yet that post went up in May, by which point the official SDK had already shipped. The opposite misreading is just as common — "so now I can just write Android apps in Swift."

The accurate state sits somewhere in between. And once you pin down that position from primary sources, a fairly clear picture emerges.

Timeline — From Nightly to General Release

Laid out as dated facts, it looks like this.

2025-06-02 — Swift Package Index adds Android/Wasm compatibility testing. By its measurement at the time, of roughly 9,000 indexed packages, 27.9% built for Android and 18.9% for Wasm (SPI blog). That's a figure from ten months before the official SDK, and it should be read as a community-toolchain-era number — no updated figures have been published since.
2025-08-27 — The Android vision document PR (swift-evolution #2946) is opened.
2025-10-24 — swift.org announces the nightly preview of the Swift SDK for Android.
2025-12-18 — The workgroup posts a follow-up post explaining the SDK, and nightly CI for the Swift 6.3 SDK goes live.
2026-01-06 — A CI workflow that runs tests on an Android emulator is merged (swiftlang/github-workflows #215).
2026-03-24 — Swift 6.3 releases, including the first official release of the Swift SDK for Android. (GitHub's swift-6.3-RELEASE tag was posted March 27.)

The acknowledgments paragraph in the release notes sums up this arc — months of work by the Android workgroup moved the SDK "from nightly preview to an official release in Swift 6.3." Underneath that sits ten years of community work that started right after the 2015 source release.

How Swift Actually Runs on Android

This is the point people misunderstand most often, so I'll carry over the workgroup's own explanation as-is.

On Android too, Swift compiles directly to native machine code, just like on most other platforms. The workgroup's description is that it delivers performance comparable to C/C++ code built with the NDK, while striking a better balance among performance, safety, and usability. To make that work, Swift apps on Android bundle the native runtime alongside themselves — that includes the standard library and core libraries like Dispatch and Foundation.

But most Android APIs are exposed only in Java and Kotlin. So Swift has to call into the Android runtime (ART), and JNI is the channel for that. What keeps people from having to write that by hand are the jextract and wrap-java tools from the swift-java project. They auto-generate bidirectional bindings, and if you need something lower-level you use Swift Java JNI Core directly.

Put together, the picture looks like this.

Swift source
  --(swiftc + Swift SDK for Android + NDK)--> per-architecture native .so
                                              (bundles Swift runtime/stdlib/Foundation)
  shipped in APK's lib/<arch>/
       ^
       | JNI (swift-java: jextract / wrap-java generate the bindings)
       v
Kotlin/Java app code  --(Android SDK)--> Activity, View, Compose ...

In other words, on Android, Swift is closer to a replacement for the NDK's spot, not a replacement for Kotlin. You write in Swift the logic layer you'd otherwise have written in C++, and Kotlin/Java still handles the rest.

Installing Three Pieces — Toolchain, SDK, NDK

The official getting-started guide asks for three pieces of cross-compilation setup, because the structure is: build on a host (macOS/Linux), run on the target (Android).

Swift toolchain — the compiler for the host. The swift bundled with Xcode won't do; it has to be the open-source toolchain, and it has to match the SDK version exactly. Managing it with swiftly is recommended.
Swift SDK for Android — the artifact bundle installed with swift sdk install <URL> --checksum <checksum>.
Android NDK — LTS r27d or later. Wire it up by running ./scripts/setup-android-sdk.sh from the SDK bundle directory.

Builds are done by specifying the SDK triple.

$ swift build --swift-sdk aarch64-unknown-linux-android28 --static-swift-stdlib
$ swift build --swift-sdk x86_64-unknown-linux-android28 --static-swift-stdlib

The 28 at the end of the triple matters. The minimum-deployment-version table on the platform support page also lists Android as 9 (API 28). In other words, anything below Android 9 is out of scope. API-level branching uses the same syntax as on Apple platforms.

@available(Android 33, *)
func backtrace() { /* ... */ }

if #available(Android 33, *) {
    // runs only on Android 33+
    backtrace()
}

Once you've built an executable, you push it over with adb push and run it. But Android apps aren't normally shipped as executables, so in practice you build the Swift module as a per-architecture shared library, drop it into the APK's lib/<arch>, and call it via JNI.

The Size Story — Read It Honestly

The guide's hello-world example output has one number printed in it. The binary size adb push reported was 69,559,568 bytes (about 66.3 MiB). On top of that, you also have to push the NDK's libc++_shared.so (1,794,776 bytes, about 1.71 MiB).

Don't misread this number. It comes with every qualifier attached — a debug build, --static-swift-stdlib, and, as the guide's own file output notes, with debug_info, not stripped. Strip a release build and the order of magnitude changes. swift.org hasn't published a stripped-release figure or the actual APK-size delta, so I won't invent one here.

Still, this output makes one fact clear — the Swift runtime isn't borrowed, the app packs it in and carries it along. That's fundamentally different from Kotlin, which already sits on top of ART, and it's something teams with a tight APK-size budget need to measure for themselves.

The Non-Goals the Vision Document States — No UI Is Provided

The Android workgroup's draft vision document has a separate "Non-goals" section. In documents like this, that section is usually the most honest part.

A full SwiftUI/UIKit port — not a goal. In the document's own words, the official Swift-on-Android effort "focuses on language and core library support, and does not build our own cross-platform UI framework."
Compiling to JVM bytecode — not a near-term goal. The explanation is that Swift's compilation model targets native machine code, and the choice made was to connect directly to Android's native layer through the NDK.

The UI section's sentence is just as clear — the official initiative does not provide a single UI framework, it only acknowledges and supports multiple approaches. As actual options, the document lists Jetpack Compose (via a bridging layer), the existing XML-based Android View, third parties like Flutter, and bridging solutions like Skip.tools, which converts SwiftUI-like code into Compose. There are also community projects like SwiftCrossUI that use native UI components on each platform. The workgroup explicitly notes it has not verified individual projects' claims.

So the flagship use case the workgroup is pushing is clear — sharing core business logic, algorithms, and data models across apps. The vision document doesn't rule out "a fully native app" entirely, but even there it attaches the caveat "though it requires significant UI effort."

One more thing worth noting about the vision document. This PR was opened on 2025-08-27, and as of now (2026-07-16) it is still an unmerged draft. Its last update was 2026-02-24. That means the document defining the direction is still a draft even after the SDK shipped in a general release.

What's Still Unfinished

This is where hype and reality part ways. Everything here is a verifiable fact.

Debugging. In the December 2025 post, the workgroup wrote that easy debugging is "now a high priority for us," noting that while "it may work for small examples," it needs to scale better and become easier to test and set up. The issue linked as evidence is swiftlang/llvm-project #10831, "Get this lldb working for Android debugging", opened 2025-06-12 and still open as of today. The platform support page's debugger/REPL support table has no row for Android either.

swift-java is still at 0.x. It's the interop layer you have to go through to call Android APIs on Android, and its latest release is 0.4.2 (2026-06-26). Being pre-1.0 means there's no API stability promise yet.

IDE. The April 2026 announcement of expanded IDE support announces the VS Code extension's Open VSX registration and speaks of "smooth cross-platform development on macOS, Linux, and Windows." Android Studio integration only appears on the vision document's list of goals — nothing has been announced yet.

The tier of "officially supported platform." This is the most subtle part. The Android workgroup charter's primary goal is still to "add and maintain Android as an officially supported platform for the Swift language," and its detailed items include "define platform support levels generally, together with the Platform Steering Group, and then work to achieve a specific level of official support for Android." In other words, that is a goal, not yet an achieved state. "Defining" the supported API levels and architecture scope is also still on the charter's to-do list. The Platform Owner table on the platform support page lists only Apple platforms, Linux, and Windows — no Android.

One caveat is needed to be fair — the workgroup charter page was last updated 2025-09-24, and the platform support page 2025-10-31. Both predate the 6.3 release. So Android's absence from the table shouldn't be over-read as "deliberate exclusion by policy"; it could just be that the docs haven't caught up yet. Still, the direction is clear — having an officially built-and-shipped SDK and becoming a supported platform at the same tier as Linux and Windows are still two different statements.

That Said, It's Not a Lab Toy

There's a counterweight worth balancing this against. Swift on Android was already running in production before the official SDK existed. The cases the workgroup itself lists are these — Readdle's email client Spark (sharing code between iOS/Android mobile and macOS/Windows desktop), the piano-learning app flowkey (using Swift for Android for close to ten years), the healthcare app MediQuo, and the organic grocer Naturitas. All of them pulled it off with their own homegrown Java interop, and in swift.org's words the combined total was "millions of downloads." (That's swift.org's own phrasing; no per-app figures are given.)

That's exactly where the official SDK's significance lies. The stage of proving whether it's even possible is already past, and we've moved into the stage where you no longer have to maintain your own fork and custom toolchain just to do it. As the vision document puts it, historically Swift for Android had to rely on unofficial forks, custom toolchains, and third-party solutions.

So, Should You Use It

When it earns its keep

Your iOS app is already in Swift, and you want to share model, networking, and domain logic with Android. This is precisely the use case the workgroup has targeted.
You want to write performance-critical modules — image or audio processing, say — in Swift instead of NDK C++. This is the second use case the vision document names, and it's exactly where Swift is taking over.
You're building a library or SDK that ships the same API surface across multiple platforms.

When it's overkill, or just not there yet

You're writing a new Android app from scratch. The vision document itself states that "Kotlin remains the recommended language for Android development." There is no official path for writing the UI in Swift.
Your team has no existing Swift assets. Adopting Swift on Android when you have no Swift code to share just saddles you with the runtime bundle and the JNI boundary, with no upside.
Debugging convenience is non-negotiable for you. With the lldb issue still open, the experience of debugging Swift code on the Android side is not yet on par with iOS.
Your APK size budget is tight. Measure the fact that you're carrying the runtime along before you commit.

You'll probably want a comparison against Kotlin Multiplatform, and being honest here means saying this: KMP has been solving the same problem (logic sharing) for several more years and has JetBrains' backing. I found no credible published benchmark or migration-case comparison that puts the two camps side by side within what I could verify, so I won't declare a winner here. The practical decision criterion is usually not a benchmark but which language your existing assets are already written in. If your iOS logic is already Swift, the Swift SDK is the path that reuses that code as-is; if not, KMP is the shorter path.

Closing

To sum up: Swift 6.3 (2026-03-24) shipped the first official release of the Swift SDK for Android, and that's a genuine milestone — ten years of community work landing on an official distribution path. The model is clear — compile to native machine code, bundle the runtime, call Android APIs over JNI. It's the NDK's spot, not Kotlin's.

At the same time, what's missing is just as clear. UI is a non-goal, JVM bytecode is a non-goal, the vision document is still a draft, the lldb issue is still open, swift-java is at 0.4.x, and the "officially supported platform" the workgroup charter talks about is still written in the future tense of a goal.

So the accurate way to read this release isn't "now you can write Android apps in Swift" — it's "getting Swift logic running on Android is now possible with officially supported tooling." Whether that distinction matters for your project is what decides whether you should reach for this now.