For years, Swift on Android was a hack. Community-maintained toolchains, fragile NDK integrations, and a lot of "it works on my machine" energy. That changed on March 24 when the Swift team shipped version 6.3 with the first official Swift SDK for Android.

This isn't a toy. You can build native Android applications in Swift, extend existing Swift packages to compile for Android, and use the new Swift Java interop libraries to integrate Swift code into Kotlin and Java projects. It's a real, supported cross-platform story — and it fundamentally changes the calculus for teams deciding how to ship on both platforms.

But "official support" doesn't mean "drop everything and rewrite." Let's break down what the Android SDK actually does, where it shines, where it doesn't, and how to decide if it's right for your project.

what shipped in Swift 6.3#

The headline feature is the Swift SDK for Android, but there's important context in the rest of the release that makes the Android story viable.

Swift Java and Swift Java JNI Core. These two libraries are the bridge between Swift and Android's runtime. Swift Java lets you call Java and Kotlin APIs from Swift code, and Swift Java JNI Core handles the low-level JNI (Java Native Interface) plumbing. Think of them as the equivalent of Swift's existing C and C++ interop — but for the JVM world. You can instantiate Java objects, call methods, and pass data back and forth without writing JNI boilerplate by hand.

Swift Build in Swift Package Manager. Swift 6.3 includes a preview of Swift Build integrated directly into SPM. This is a unified build engine that works across all supported platforms — macOS, Linux, Windows, and now Android. The practical impact: you can define a Swift package that builds for both iOS and Android from a single Package.swift, using platform-specific conditional compilation where needed.

Improved C and C++ interoperability. Android's NDK is C/C++ under the hood, so better C interop means Swift code can talk to Android's native layer more reliably. Virtual methods, noncopyable types, and lifetime annotations all got improvements in 6.3 that directly benefit Android builds.

what you can actually build today#

Let's be concrete. The Swift Android SDK is best suited for three scenarios right now.

Shared business logic. If your iOS app has a clean separation between UI and logic — networking, data models, algorithms, validation, caching — you can compile that logic layer for Android and call it from your Kotlin UI code via Swift Java. This is the highest-value use case. You write the logic once, test it once, and get identical behavior on both platforms. No more "the Android version calculates tax differently because someone copied the formula wrong."

Libraries and SDKs. If you ship a Swift package that other developers embed in their apps (analytics, authentication, payments, etc.), you can now offer an Android version built from the same source. This is huge for SDK vendors who previously had to maintain parallel implementations.

Experimental full apps. You can technically build a complete Android app in Swift, but the UI story is still early. There's no SwiftUI equivalent for Android — you'll be writing your UI in Kotlin or Java and calling into Swift for everything else. For hobby projects or internal tools, this is fine. For production apps with complex UIs, the hybrid approach (Swift logic + native Kotlin UI) is more realistic.

how it compares to the alternatives#

Swift on Android doesn't exist in a vacuum. Developers evaluating cross-platform strategies in 2026 have several mature options, and each makes different tradeoffs.

Kotlin Multiplatform (KMP) is the most direct competitor. KMP lets you share Kotlin code between Android and iOS, with a mature interop story for Swift on the iOS side. If your team is Kotlin-first, KMP is likely a better fit — it has a multi-year head start on tooling, IDE support, and production adoption. But if your team is Swift-first, the new Android SDK flips that equation. You no longer have to adopt Kotlin as your shared language.

Flutter gives you shared UI and logic from a single Dart codebase. It's more opinionated and more complete — you get pixel-identical UI on both platforms out of the box. The tradeoff is that you're writing Dart, not Swift or Kotlin, and deeply native integrations (ARKit, platform-specific APIs) require plugin bridges. Flutter is still the pragmatic choice for teams that want to ship fast on both platforms with a small team and don't need deep native access.

React Native occupies similar territory to Flutter but with JavaScript/TypeScript and a bridge to native modules. The new architecture (Fabric + TurboModules) has improved performance significantly, but the developer experience still involves more configuration than Flutter or native development.

The sweet spot for Swift on Android is teams that have significant Swift codebases, care deeply about type safety and performance in their shared logic layer, and are comfortable writing platform-specific UI. If that describes you, this release is a genuine game-changer.

getting started: a practical walkthrough#

Here's how to take an existing Swift package and make it build for Android.

Step 1: Install the Android SDK for Swift. The Swift.org documentation has a getting-started guide that walks you through downloading the SDK and configuring your toolchain. You'll need the Android NDK installed alongside your existing Swift toolchain.

Step 2: Add Android as a platform target. In your Package.swift, you can now use conditional compilation to include or exclude files by platform. The pattern looks familiar if you've ever targeted both macOS and Linux:

swift

#if os(Android)
// Android-specific implementation
#else
// iOS / macOS implementation
#endif

Step 3: Bridge to Kotlin/Java. Import Swift Java in your package and use it to expose your Swift types to the JVM. The library generates the JNI bindings automatically — you annotate your Swift types and functions, and the tooling handles the rest.

Step 4: Build and test. Swift Package Manager with Swift Build can cross-compile for Android from your Mac. Run your tests on an Android emulator or device using the standard swift test workflow with the Android SDK selected.

what this means for shipping to both stores#

Here's where things get interesting for indie developers and small teams. The hardest part of maintaining an iOS and Android app isn't usually the code — it's the operational overhead. Two sets of App Store screenshots. Two store listings to optimize. Two sets of compliance requirements to track. Two submission pipelines to manage. Two sets of release notes to write.

Swift on Android solves the code-sharing problem. But the submission problem remains. You still need to build, screenshot, write metadata, check compliance, and push to both the App Store and Google Play — and each store has its own rules, formats, and review quirks.

This is where tools like Stora come in. If you're now building from a shared Swift codebase and shipping to both stores, Stora handles the submission side for both platforms: generating screenshots across all device sizes, writing and localizing store listings with AI, running compliance checks against each store's current requirements, and publishing updates. The code is your problem. The store logistics don't have to be.

the bottom line#

Swift 6.3's Android SDK is the most significant expansion of Swift's platform reach since it went open-source in 2015. It's not going to replace Flutter for teams that want shared UI, and it's not going to dethrone KMP overnight. But for Swift-first teams — and there are a lot of you — this is the first time you can share production code with Android without leaving your language, your toolchain, or your mental model.

The SDK is real, it's official, and it works today. Whether it's right for your project depends on your team, your architecture, and your willingness to maintain native UI on both sides. But for the first time, "just use Swift" is a legitimate answer to the cross-platform question.