Swift for Android: The Official SDK, SwiftUI, and Real Cross-Platform (2026)

What Actually Shipped

The Swift Android Workgroup was formed in 2025 with the goal of making Android a first-class Swift platform. In March 2026, they delivered the first piece: a nightly Swift SDK for Android hosted directly on swift.org. This is the same level of support Apple gives Linux and Windows through official Swift toolchains.

Here is what the current release includes:

• A Swift SDK bundle installable via swift sdk install that targets Android.
• Support for four Android architectures: aarch64, x86_64, armv7, and i686.
• A minimum Android API level of 28 (Android 9 and newer), which covers roughly 95 percent of active devices.
• Swift Package Manager integration so you can cross-compile any SwiftPM package to Android with a single flag.
• A curated set of core libraries, including Foundation, Dispatch, XCTest, and swift-log, validated against Android.

Swift SDK for Android at a Glance

Installing the Swift SDK for Android

If you already have a recent Swift toolchain (6.0 or newer) and the Android NDK installed, installation is one command. The SDK is distributed as an .artifactbundle.tar.gz file from swift.org.

# Install the Swift SDK for Android (nightly)
swift sdk install \
  https://download.swift.org/development/swift-sdks/swift-DEVELOPMENT-SNAPSHOT-android-0.1.artifactbundle.tar.gz

# Verify
swift sdk list
# Output: swift-DEVELOPMENT-SNAPSHOT-android-0.1

# Build a Swift package for Android (aarch64)
swift build --swift-sdk aarch64-unknown-linux-android28

That is it. The resulting binary is a shared object (.so file) that can be packaged inside an Android .apk or .aab and invoked from Kotlin or Java code through JNI.

The SwiftUI Question

Here is the part that trips up almost everyone reading the headlines: the Swift SDK for Android does not bring SwiftUI to Android. SwiftUI is tightly bound to Apple's rendering stack (Metal, Core Animation, UIKit/AppKit interop). Porting it would require rebuilding the entire platform layer on top of Android's view system, and Apple has shown zero interest in doing that.

So if you want your UI to run on Android, you have three realistic options:

Skip: The Pragmatic SwiftUI-to-Android Path

Skip.tools is the project most indie developers reach for when they hear “SwiftUI on Android.” It is a commercial transpiler built on top of SwiftPM that translates SwiftUI code into Jetpack Compose at build time. You write one SwiftUI codebase, and Skip produces an iOS app (native SwiftUI) and an Android app (Compose) from it.

Skip predates the official Swift Android SDK and is complementary to it. Skip handles the UI translation, while the Swift Android SDK covers the language runtime and standard library. The two projects are converging: Skip has signaled plans to adopt the official Swift SDK for Android as its runtime target.

What Skip does well:

• One codebase, two native apps. Not a WebView, not a custom renderer. The output is real Jetpack Compose Kotlin code.
• Platform escape hatches. Use #if SKIP blocks to write Android-specific code when needed.
• Unified package manager. Skip uses SwiftPM, so your existing Swift packages continue to work.
• Real debugging. You debug Kotlin output in Android Studio and Swift source in Xcode, not a blackbox.

What Skip does not do:

• Replace Kotlin for your team. If you have a large Android org, this is an iOS-first tool.
• Cover every SwiftUI API. Advanced layout, custom shaders, and some animations may need platform-specific forks.
• Come for free. Skip has a paid commercial license beyond the free tier.

Why This Matters for Indie iOS Developers

For a solo iOS developer, the Android market is usually ignored because the upfront cost is brutal. Learning Kotlin, Jetpack Compose, Android Studio, the Android build system, Google Play publishing, and Play Console billing can easily add six months to a launch. Most indie iOS devs simply skip Android and leave revenue on the table.

The official Swift Android SDK does not eliminate that cost, but it does shift the math:

• Your models, networking, persistence, and business logic can be shared. These are the parts you would otherwise rewrite line for line in Kotlin.
• Your tests can run on both platforms. XCTest now works on Android, which means your coverage extends to both app builds.
• Your Swift packages become portable. Any SwiftPM package that compiles on Linux likely compiles on Android with the new SDK.
• Your UI layer becomes the only Android-specific code. If you use Skip, even that can be mostly shared.

For an app built on clean MVVM architecture where ViewModels, repositories, and services are separated from Views, the shared surface can easily exceed 60 percent of the codebase.

A Practical Architecture for Shared Swift Code

Here is a project layout that works well when you want to share Swift logic between iOS and Android without adopting Skip:

MyApp/
├── Packages/
│   └── MyAppCore/              # SwiftPM package, cross-platform
│       ├── Sources/
│       │   ├── Models/         # Sendable structs
│       │   ├── Services/       # Actors, networking, persistence
│       │   └── ViewModels/     # @Observable view models
│       └── Tests/
├── iOS/
│   └── MyAppiOS.xcodeproj      # SwiftUI app, depends on MyAppCore
└── Android/
    ├── app/                    # Android Studio project
    │   └── src/main/kotlin/    # Jetpack Compose UI
    └── jni/
        └── MyAppCoreBridge/    # JNI glue to MyAppCore .so

The core package builds twice: once for iOS through Xcode, and once for Android through swift build --swift-sdk. The iOS app links it directly. The Android app packages the .so binary and calls into it through JNI. You write the Kotlin UI by hand using Jetpack Compose, but everything below the UI layer is shared Swift.

What You Still Cannot Do

Let me be direct about the limitations, because the marketing copy glosses over them:

• No SwiftUI. This is the single biggest caveat. If you need SwiftUI on Android, use Skip. If you need a fully native Android UI, write Jetpack Compose.
• No Core Data, no SwiftData. These depend on Apple's Objective-C runtime, which does not exist on Android. Use GRDB, SQLite.swift, or a Swift wrapper around Room for persistence.
• No CloudKit, no Combine UI bindings, no StoreKit. Anything Apple-specific is unavailable. Use platform-neutral alternatives like Supabase for sync and RevenueCat for subscriptions.
• No Apple Push Notifications on Android. Use Firebase Cloud Messaging or a cross-platform service.
• Nightly means nightly. The SDK is not yet a tagged 1.0 release. Expect occasional breakages until the Workgroup cuts a stable version.

Who Is Actually Using This?

The early adopters fall into a few predictable buckets:

• Indie developers with SwiftUI apps shipping Android versions through Skip. This is the largest group by volume.
• Cross-platform SDK vendors who want a single Swift codebase for their client libraries on every platform. A Swift-native analytics SDK, for example, can ship to Apple, Linux, Windows, and Android with one source tree.
• Finance, health, and crypto apps with heavy, regulated business logic that they do not want to fork between iOS and Android. Keeping the logic in Swift reduces audit surface.
• Server-side Swift teams experimenting with shipping mobile binaries from the same codebase that runs their backend.

How This Compares to Other Cross-Platform Options

If you are choosing a cross-platform stack in 2026, Swift for Android is not the only option, and usually not the obvious one. Here is how it fits against the alternatives:

For a deeper cross-platform comparison, read Flutter vs React Native vs SwiftUI.

Getting Started in One Afternoon

If you want to try Swift on Android today, here is the shortest path to a running “Hello Android” in Swift:

1. Install prerequisites. Swift 6.0+, Android Studio, and the Android NDK (version 26 or newer).
2. Install the Swift SDK for Android from the swift.org nightly artifact bundle using swift sdk install.
3. Create a SwiftPM library with a single function that returns a greeting string.
4. Build for Android with swift build --swift-sdk aarch64-unknown-linux-android28.
5. Copy the resulting .so into an Android app under src/main/jniLibs/arm64-v8a/.
6. Write a small JNI binding that exposes the Swift function to Kotlin.
7. Call it from a Compose screen and render the greeting.

The full tutorial lives on swift.org. Expect to spend an afternoon on the JNI glue the first time. After that, every subsequent Swift function you expose is copy-paste.

Should You Bet on Swift for Android?

My honest read: yes for side projects, cautious yes for new apps, wait for production ports of existing apps.

The language story is solid. Swift the language is stable, fast, and memory-safe. Running it on Android gives you a serious alternative to Kotlin for shared logic, and the tooling story will only get better as the Workgroup ships stable releases. If you are an iOS developer who has always wanted to ship on Android without learning an entire new stack, this is the most promising path in years.

The UI story is still unfinished. Until Apple ships a SwiftUI port (which may be never) or until Skip reaches feature parity for every SwiftUI API, you will touch Kotlin or accept some transpilation tax. Plan for that before you promise your users an Android version.

Start Your Next App with a Clean Core

The apps best positioned to go cross-platform are the ones built with clean separation between UI and logic from day one. If you are starting a new SwiftUI app, The Swift Kit ships with that architecture by default: @MainActor view models, actor-based services, Sendable models, and SwiftPM-first modules that are ready to compile for Android when you decide to port.

Build your iOS app the right way today, and the Android version becomes a recompilation and a UI, not a rewrite.