Swift on Android: Does the 6.3 SDK Actually Work?

With Swift 6.3, Android got its first official Swift SDK, and "developing with Swift on Android" stopped being theoretical. But is "there's an official SDK" the same as "a production-ready platform on Android"? This article walks through what Swift 6.3's Android support — released March 24, 2026 — actually delivers, from setup to embedding Swift code into an existing Kotlin project.

💡 Pro Tip: Before trying the Swift SDK for Android, make sure you have Android NDK LTS 27d or newer installed — the SDK's cross-compile headers and tooling depend directly on this NDK version.

Table of Contents

• What the official Android SDK brings — and what it doesn't
• The SDK is not a "Swift for Android app"
• Setup and the first build
• First build and running on a device
• Installing the NDK and pointing the SDK at it
• Connecting to an existing Kotlin project via the Swift-Java bridge
• Two bridge options: swift-java or JNI Core
• The UI layer boundary: where sharing stops
• The realistic use case: a shared business logic core
• Who it makes sense for, and who it doesn't
• What to watch for when adding it to your CI pipeline
• Its position relative to KMP
• FAQ
• Can you write an Android app with Swift?
• Is the Swift Android SDK official, and what does it support?
• How does Swift-Java interop work with existing Kotlin code?
• Are Jetpack Compose screens written in Swift with this SDK?
• What's the minimum Android version?
• Can it be used in production right now?
• Update (September 2026)
• Conclusion
• Sources

What the official Android SDK brings — and what it doesn't

Swift's official blog announced it in one clear sentence: "Swift 6.3 includes the first official release of the Swift SDK for Android." It's the result of months of work by the Android Workgroup and years of grassroots community effort, from nightly previews to an official release. Swift 6.3's broader focus went the same direction: more flexible C interop, better cross-platform build tooling, improvements for embedded environments, and an official Android SDK.

One important distinction: Android support isn't the restricted "Embedded Swift" mode — swift.org's announcement page treats it as its own "Android" subsection under "Platforms and Environments." This is a full-fledged cross-compilation target, not a microcontroller-class mode.

So what doesn't it bring? The SDK gives you compilation and a JNI bridge, but not an official Swift-side interface layer that replaces Android's own UI framework (Jetpack Compose, the View system). The official setup guide implicitly confirms this: it states the Android application Swift code gets accessed from is "typically written in Java or Kotlin" — ownership of the UI layer doesn't change.

The SDK is not a "Swift for Android app"

The announcement itself puts it this way: "With this SDK, you can start developing native Android programs in Swift." Read "native Android programs" at the right scale. The setup guide explains that Android applications aren't distributed as command-line executables — they're packaged into an .apk archive, with Swift modules included as a shared library. So yes to compiling native code with Swift; no to writing the app shell and UI layer in Swift — no official sources describe a Swift-side interface layer. In practice, it gives you a way to compile Swift code into Android's native (JNI) layer and embed it into an existing Kotlin/Java application. You'll see this with concrete code below.

Setup and the first build

Cross-compiling for Android requires three components: the Swift Toolchain, the Swift SDK for Android, and the Android NDK. Per the official guide, the easiest and recommended way to manage the host toolchain on macOS and Linux is the swiftly command-line tool.

1# 1) Install the host toolchain with swiftly (macOS/Linux)
2swiftly install latest
3swiftly use latest
4 
5# 2) Download and install the Android SDK bundle (checksum REQUIRED)
6swift sdk install https://download.swift.org/swift-6.3-release/android-sdk/swift-6.3-RELEASE/swift-6.3-RELEASE_android.artifactbundle.tar.gz \
7  --checksum 2f2942c4bcea7965a08665206212c66991dabe23725aeec7c4365fc91acad088
8 
9# 3) Verify installed SDKs -> output: swift-6.3-RELEASE_android
10swift sdk list

The Swift SDK for Android depends on Android NDK LTS 27d or newer, which provides the header files and tools cross-compiling needs. Per the official guide, the simplest install path is downloading the archive from the NDK Downloads page and unpacking it.

First build and running on a device

Once setup is done, you cross-compile by passing the target triple to swift build with --swift-sdk. The resulting binary is copied to a device or emulator with adb push and run via adb shell — you also need to ship the NDK's libc++_shared.so dependency alongside the binary:

1swift build --swift-sdk aarch64-unknown-linux-android28 --static-swift-stdlib
2 
3adb push .build/aarch64-unknown-linux-android28/debug/hello /data/local/tmp
4adb push $ANDROID_NDK_HOME/toolchains/llvm/prebuilt/*/sysroot/usr/lib/aarch64-linux-android/libc++_shared.so /data/local/tmp/
5adb shell /data/local/tmp/hello

In the swift sdk list output you'll see the installed SDK named swift-6.3-RELEASE_android; you specify the target with the triple at build time. The minimum supported Android version is API 28 (Android 9) — the triples reflect this too (aarch64-unknown-linux-android28, x86_64-unknown-linux-android28).

Installing the NDK and pointing the SDK at it

The official guide recommends unpacking the NDK directly inside the Swift SDK's install directory: move into the bundle directory, download and unpack the archive, set the ANDROID_NDK_HOME variable, and run the SDK's setup-android-sdk.sh script. If the NDK is already installed elsewhere, just point ANDROID_NDK_HOME at that location and run the same script. Once it finishes, you have a fully working cross-compilation toolchain for Android.

1# Bundle directory on macOS (on Linux: ~/.swiftpm/swift-sdks/...)
2cd ~/Library/org.swift.swiftpm/swift-sdks/swift-6.3-RELEASE_android.artifactbundle/swift-android/
3 
4curl -fSL -o ndk.zip https://dl.google.com/android/repository/android-ndk-r27d-$(uname -s).zip
5unzip -qo ndk.zip
6export ANDROID_NDK_HOME=$PWD/android-ndk-r27d
7./scripts/setup-android-sdk.sh

Connecting to an existing Kotlin project via the Swift-Java bridge

Android applications aren't distributed as command-line executables — they ship as .apk shared libraries. This is where the SDK's real practical value shows: compile Swift modules as a shared library per architecture, include them in the app archive, and access them from the Android side (typically Java or Kotlin) via swift-java — a tool that handles the Java Native Interface (JNI) details for you.

1package com.example.app
2 
3import android.os.Bundle
4import android.widget.TextView
5import androidx.appcompat.app.AppCompatActivity
6import com.example.swiftcore.SwiftCore
7 
8class MainActivity : AppCompatActivity() {
9    override fun onCreate(savedInstanceState: Bundle?) {
10        super.onCreate(savedInstanceState)
11        setContentView(R.layout.activity_main)
12        val textView = findViewById<TextView>(R.id.greeting)
13        // Result of business logic computed on the Swift side
14        textView.text = SwiftCore.buildGreeting("Android")
15    }
16}

The SwiftCore name above is a placeholder: the generated binding's exact name, package, and call shape depend on your swift-java configuration; the official guide gives no fixed class name or sample call. The Swift-side counterpart is just an ordinary public function:

1// On the Swift side: the core compiled into a shared library
2public func buildGreeting(name: String) -> String {
3    "Hello, \(name)! This line ran in Swift."
4}

For advanced use cases there's also Swift Java JNI Core, a lower-level interface. The official "Android Examples" repository hosts sample projects showing how full Android apps use this SDK; before wiring a Swift module into a Kotlin project from scratch, reviewing that repository is the fastest way to see which file/target layout to mirror.

Two bridge options: swift-java or JNI Core

The official guide separates these two layers in one sentence: swift-java handles the JNI details for you; for JNI Core it only says "For advanced uses, Swift Java JNI Core is also available as a low-level interface." It doesn't describe the concrete cases for switching to JNI Core. So within the 6.3 window, the only written direction is this: the default path is the bindings swift-java generates, while JNI Core is the low-level option the docs flag as being for "advanced uses."

The UI layer boundary: where sharing stops

Let's be clear: the Swift SDK for Android doesn't provide a UI framework. The official setup guide states the Android application is typically written in Java or Kotlin — screens, navigation, and Compose components stay on the Kotlin/Java side. Swift's role is a native executable/library layer that this Kotlin/Java layer calls into via JNI.

This creates a clear division of responsibility, summarized in the table below:

The realistic use case: a shared business logic core

Since going open source in 2015, Swift has evolved from a Darwin-focused language into a cross-platform one supporting Linux, Windows, and various embedded systems. The Android SDK is a natural continuation of that expansion. But it doesn't mean "write a whole Android app in Swift" — the realistic use case is a business logic core shared between iOS and Android: platform-independent code like validation rules, computation algorithms, data transformation, and cryptography.

This model lets your team move a domain layer already written in Swift to Android without rewriting it — but UI, platform integration, and distribution stay on the Kotlin/Java side.

Who it makes sense for, and who it doesn't

This approach makes the most sense for teams that already have a large Swift codebase (an iOS app, a server-side Swift service, or a shared framework) and don't want to rewrite that logic from scratch in Kotlin. If you don't have a Swift codebase, or your team is already comfortable in Kotlin/Java, pulling this SDK in just to be "cross-platform" adds extra toolchain complexity (toolchain + NDK + JNI bridge) and costs you the advantage of a single language.

What to watch for when adding it to your CI pipeline

Cross-compiling for Android already requires macOS/Linux + swiftly + Android SDK + NDK on your host machine; your CI environment needs all three too. A practical approach is compiling the Swift core in a separate CI step and feeding the resulting shared library into the Android build — the Swift and Gradle builds stay independent and can run sequentially or in parallel. For the cp step below to work, the shared library product needs to be defined in Package.swift as .library(name: "SwiftCore", type: .dynamic, targets: ["SwiftCore"]); without a type, SwiftPM chooses static/dynamic itself and the .so file won't appear at that path.

1# CI: first compile the Swift core for the Android target
2swift build --swift-sdk aarch64-unknown-linux-android28 \
3  -c release --static-swift-stdlib
4 
5# Copy the produced shared library into the Android module's jniLibs directory
6cp .build/aarch64-unknown-linux-android28/release/libSwiftCore.so \
7  app/src/main/jniLibs/arm64-v8a/
8 
9# Then run the normal Gradle build
10./gradlew assembleRelease

I prefer keeping these two stages as separate CI steps; it's easier to tell which toolchain failed, since if the Swift build fails, the Gradle step never runs at all.

Its position relative to KMP

Kotlin Multiplatform (KMP) is JetBrains's official cross-platform solution for writing shared code across Android, iOS, Web, Desktop, and Server targets without sacrificing performance, UX, or code quality; it has production case studies from companies like Duolingo, Google, Booking.com, McDonald's, Philo, and Workday.

Swift's Android story is framed differently from KMP's path. KMP has a "call shared code from Kotlin, with optional Compose UI" model. With the Swift SDK for Android, the direction flips: you embed an existing Swift business logic core into an existing Kotlin/Java app via JNI. So while KMP is "Kotlin-centric, multi-target," the Swift SDK for Android is currently at the "Swift core, Kotlin/Java shell" level — without an official Swift-side UI layer.

This difference largely determines which team picks which tool. For a team building a multi-platform app from scratch and adopting Kotlin as its primary language, KMP is the more natural starting point since it offers both UI sharing and a mature toolchain. For a team that already has a large, well-tested Swift business logic layer — say, the domain layer of a long-running iOS app — the Swift SDK for Android is an official, direct way to bring that layer over without rewriting it. The two tools aren't substitutes; they serve teams with different starting points.

FAQ

Can you write an Android app with Swift?

Not in the direct sense of "write an Android app in Swift." The Swift SDK for Android lets you compile Swift code as a shared library and embed it into an existing Kotlin/Java Android app via JNI; screens and navigation stay on the Kotlin/Java side.

Is the Swift Android SDK official, and what does it support?

Yes, it's official. The Swift 6.3 announcement made this clear with "the first official release of the Swift SDK for Android." The SDK supports the cross-compile tooling, a dependency on Android NDK LTS 27d or newer, and a minimum API 28 target.

How does Swift-Java interop work with existing Kotlin code?

The swift-java library automatically generates the JNI bridge needed to call Swift-compiled code from Kotlin/Java. For scenarios needing advanced control, there's also a lower-level interface called Swift Java JNI Core. In practice: you define a public (public) function or type on the Swift side, swift-java scans it and generates a Kotlin/Java binding, and you call that binding from your Android code like a normal class call — no dealing with JNI itself.

Are Jetpack Compose screens written in Swift with this SDK?

No. The official sources don't describe a Swift-side UI framework; the Android application continues to be typically written in Java or Kotlin, with Swift only providing a callable native layer.

What's the minimum Android version?

Based on the official platform support and the triples in the setup guide, the minimum supported version is API 28 (Android 9).

Can it be used in production right now?

Technically yes — you can compile it and embed it into an app — but this is the first official release that came with Swift 6.3. Before putting a new toolchain's first release into a critical production flow, it's safer to start with a small, isolated module (a single computation function, say) and expand from there.

Update (September 2026)

This article was written in the window of March 30, 2026, fresh off Swift 6.3's announcement. Here's what's been confirmed in the six months since: the Swift 6.3.3 patch release shipped at the end of June 2026 (the swift-6.3.3-RELEASE tag on GitHub points to a commit dated June 26, 2026); Swift 6.4 was then announced on September 15, 2026. The most significant Android-side change is in the NDK dependency: the Swift 6.4 announcement says "This release of the Swift SDK for Android is built with the new LTS NDK 30," noting that this NDK provides Android availability attributes both in the Swift runtime libraries and in Swift packages using the default NDK.

So the LTS 27d base described above has been replaced by LTS NDK 30. The current guide now shows the bundle name swift-6.4.0-RELEASE_android and the aarch64-unknown-linux-android23 triple; the API 28 baseline from March has been lowered. The Swift 6.4 announcement also states Swift/Java interop expanded its async and callback support; the swift-java project, in its 0.6.0 release on September 5, 2026, added Java functional-interface support (the Consumer/Predicate/BinaryOperator family) to jextract and support for importing functions with isolated parameters.

Conclusion

Swift 6.3's Android SDK isn't a promise to "write a full Android app in Swift" — it's an official way to build a shared business logic core embeddable into an existing Kotlin/Java application via JNI. For the wider Swift ecosystem, check out what changed in Swift 6.0; considering server-side Swift, take a look at the server-side Swift ecosystem. While preparing the core you'll move to Android, the Swift structured concurrency guide helps on concurrency, and the Swift Package plugins article helps with build automation. Mid cross-platform decision? Put this SDK side by side with the React Native vs. Flutter comparison and weigh it against your team's actual needs.

Sources

• Swift 6.3 Released — Swift.org Blog — the first official announcement of the Android SDK and Swift 6.3's general highlights.
• Getting Started with the Swift SDK for Android — Swift.org Documentation — setup, the three-component toolchain, and swift-java bridge details.
• Swift 6.4 Released — Swift.org Blog — the September 2026 update, LTS NDK 30, and the Swift/Java interop expansion.
• swift-java Releases — GitHub — the release history of jextract and the JNI bridge.
• Swift Platform Support — Swift.org — minimum Android API level and platform tier information.
• Kotlin Multiplatform — JetBrains — the official KMP page referenced in the comparison section.