Swift on Android in 2026: A Real Option Beside Flutter, React Native and KMP?

If your company already has an iOS app written in Swift, the Android question usually arrives as a budget line. Do we rebuild it in Kotlin, rewrite both apps in Flutter or React Native, or move the shared code to Kotlin Multiplatform? Since March 2026 there is a fourth answer with an official badge on it. Swift on Android is now supported by the Swift project itself, through the Swift SDK for Android that shipped with Swift 6.3.

The headline invites the wrong comparison. The SDK lets you compile Swift code for Android and call it from a Kotlin app. It does not put your SwiftUI screens on an Android phone. That makes it a competitor to Kotlin Multiplatform, not to Flutter or React Native.

What the Swift SDK for Android actually is

Swift 6.3, released on March 24, 2026, included what the Swift project calls "the first official release of the Swift SDK for Android". Before that it existed as nightly previews: the Android workgroup's post of December 18, 2025 announced 6.3 nightly SDKs built on the project's official CI.

Swift 6.4 followed on September 15, 2026. For Android it is a toolchain update rather than a major release. It moves to the long-term-support NDK r30, adds Android availability attributes to the Swift runtime libraries and to user packages, and lets Swift Build in SwiftPM handle Android without the post-install scripts earlier setups needed.

Swift.org: Swift 6.3 Released (March 24, 2026)

It is a cross-compilation SDK. You build on a macOS or Linux machine and produce code for Android. The official Getting Started guide, which currently targets Swift 6.4.0, has the shape of a normal Swift setup plus two downloads:

• Install the Android SDK bundle with swift sdk install. Its version must match the toolchain version exactly.
• Install the Android NDK LTS r30 and point ANDROID_NDK_HOME at it.
• Build with the SDK named on the command line (swift-6.4.0-RELEASE_android), a target triple such as aarch64-unknown-linux-android23, and --static-swift-stdlib, which bundles the Swift runtime.

swiftly install latest
swiftly use latest

# SDK and toolchain versions must match.
# Copy the URL and checksum from swift.org.
swift sdk install \
  "$SDK_URL" \
  --checksum "$SDK_CHECKSUM"

Take the URL and checksum from the guide itself, not from an article, this one included.

Swift.org: Getting Started with the Swift SDK for Android

The guide documents two architectures, aarch64 and x86_64, and its examples target API level 23 (Android 6.0). The official sample app's Gradle build also lists armeabi-v7a, so the safe summary is: at least 64-bit ARM and x86_64. Newer Android APIs are gated with the availability syntax Swift developers already know. This form is from the workgroup's post:

@available(Android 33, *)
func usesNewerPlatformAPI() {
    // Callable only on API level 33 and up.
}

Foundation is harder to pin down. The Getting Started page does not mention it, the workgroup lists improving Foundation and Dispatch on Android among its objectives, and secondary sources say the SDK bundles the open-source corelibs Foundation. Assume it is there, and confirm every API you depend on with a real build.

Apple's own frameworks are a different matter. SwiftUI, UIKit and the rest are not part of it, because the SDK is a build of open-source Swift for Android, not of Apple's platforms.

How Kotlin calls your Swift

For an app, the guide explains, Swift is built as a shared library, packaged into the app and called from Kotlin or Java. The bridge is swift-java, a swiftlang project with two tools: jextract generates bindings so Java and Kotlin can call Swift, and wrap-java goes the other way so Swift can call Java.

jextract has two modes. FFM mode uses Java's foreign function and memory API, needs a recent JDK, and offers the most flexibility and performance. JNI mode is the one that, in the README's words, "works on older JVMs as well as on Android". It needs JDK 17 or later and, by the project's own description, gives less performance and flexibility than FFM. It arrived in the summer of 2025.

The official swift-android-examples repository shows the path. Its recommended sample, hello-swift-java, is a Swift package that uses swift-crypto to compute a SHA256 hash. A Gradle build compiles that package into an Android library (.aar) holding the native code, running the jextract plugin on the way. A Kotlin app with a Jetpack Compose UI calls it from a button, with "no manual JNI code required". Read the sample rather than trusting a remembered signature: the generated API is the part most likely to change.

What stays native: the UI

The SDK has no UI story, and the workgroup says so: there is no single official GUI solution. The pattern the official samples recommend is the one we would recommend too. Business logic lives in a Swift package. The Android UI is written in Kotlin with Jetpack Compose, as any Android app's would be. Your iOS app keeps its SwiftUI or UIKit screens.

That split is usually a feature. Navigation, permissions, notifications and system controls differ between the platforms, and each platform's users expect its own. Our SwiftUI and UIKit comparison covers the Apple half of that choice.

SwiftUI vs UIKit: a comparative dive into Apple's UI frameworks

If you do want one Swift UI on both platforms, there is Skip: a separate open-source project, not part of swift.org, that takes a SwiftUI app to Android through Jetpack Compose. Skip Lite transpiles Swift to Kotlin; Skip Fuse compiles Swift natively with the official SDK and bridges to Compose. It is the Swift-side counterpart of Compose Multiplatform. We are not assessing it here.

Swift on Android vs KMP, Flutter and React Native

The four options answer different questions. Two share logic and keep the UI native. Two replace the UI as well.

Kotlin Multiplatform

KMP is the mirror image of the Swift SDK for Android. JetBrains' open-source technology shares Kotlin code across Android, iOS, desktop, web and server. You can share one isolated module, all business logic with native UI on each side, or logic plus UI through Compose Multiplatform, whose iOS support was declared stable with version 1.8.0 in May 2025. JetBrains' docs cite Google, Duolingo, McDonald's and Bolt as case studies and point to more than 1,000 libraries on klibs.io.

Who it fits: teams whose centre of gravity is Kotlin, or who are starting both apps fresh. Its advantage today is maturity: a stable UI-sharing layer and a library catalogue. Swift on Android competes for the team that already has the Swift code.

The Swift SDK for Android

Who it fits: teams with an existing Swift iOS app, or Swift packages, holding logic worth sharing, and developers who would rather write that logic once in Swift. The official status is new. The approach is not. The workgroup's December 2025 post names Spark, flowkey, MediQuo and Naturitas as apps using Swift on Android, flowkey for nearly a decade. Those teams got there on community toolchains before the official SDK existed, so they show that the approach works, not that the official SDK has a production track record.

Swift.org: Exploring the Swift SDK for Android (December 18, 2025)

Flutter

Flutter apps are written in Dart and drawn by Flutter's own rendering engine, Impeller, rather than with platform widgets. Android and iOS are both stable targets. Who it fits: teams starting from scratch who want one codebase for UI and logic and accept a non-native UI layer. For a team with a Swift iOS app it means rewriting both apps, not sharing what exists.

React Native

React Native apps are written in JavaScript with React, and its components map to native platform views. Who it fits: organisations with strong React and web skills who want those people building mobile. As with Flutter, for a Swift team it means a rewrite rather than a share.

On 10 September 2026 Shopify published the other side of that choice, for a team that had already bet on React Native. They went all-in on it in 2020. In "Native is now the future of mobile at Shopify" they say coding agents changed the bet: agents can now do enough of the implementation, translation, testing and review that building the same feature in Swift and Kotlin is no longer "the deciding factor it was in 2020". They are explicit that the cost has not disappeared. Native still means building and maintaining software on two platforms. They do not say native is cheaper. For the Shop app, the alternative they were weighing was another large React Native investment, adopting the New Architecture.

Shopify Engineering: Native is now the future of mobile at Shopify (10 September 2026)

The Shop app moved first. The migration write-up published the same day says the team went from a proof of concept to a fully rebuilt native app in the stores in 12 weeks. Cold start, from the icon tap until the home feed was visible, was 2,466 ms on native iOS against 3,200 ms on React Native (a 23% reduction) and 2,233 ms against 4,433 ms on Android (50%). Session stability moved from 99.5% or better to 99.95% or better, which they call a 10x reduction in sessions that crash. The native Android release build was 109 MB smaller (184 MB against 293 MB). The iOS build grew by 1 MB. Android release builds fell by about 75%. iOS release builds took about the same time.

Shopify Engineering: Migrating Shop app from React Native to native (10 September 2026)

That sits beside this article's argument rather than against it. Shopify's claim is that agents make a second implementation affordable enough that sharing the whole app is no longer the deciding reason. Sharing the business rules is a different saving: one implementation to review. In the same post they still pull that logic out of the UI so it can run headlessly, because an agent that can only test through a simulator is too slow. Agents that can draft the second screen do not review two copies of a pricing rule. Swift on Android, like KMP, is aimed at that second saving. It is not a claim that a shared UI is obsolete, and it is not a claim that native is the cheaper build.

Where it fits for a business

For a CTO or founder the question is less "which technology is best" than "what do we already own". Swift on Android earns a place on the shortlist when three things are true:

1. You already have an iOS app in Swift, and a meaningful part of it is domain logic rather than screens: pricing rules, validation, sync and conflict resolution, offline storage, a file-format parser, a protocol client.
2. That logic lives, or could live, in Swift packages with no dependency on UIKit or SwiftUI. Those packages are exactly what you would compile for Android.
3. You have, or will hire, Kotlin developers for the Android UI. The SDK does not remove that job.

If your iOS code is one large app target, the first step is to pull the logic into packages, shared or not.

Scaling Swift projects with modular packages

The cost is not in the Swift code. It is in the join: someone owns the Gradle build, keeps the SDK matched to the toolchain, and follows swift-java through its pre-1.0 changes. Every third-party package must also build for Android; Swift 6.3 asked package authors to update theirs.

Debugging across the boundary is the weakest part. In December 2025 the workgroup wrote that debugging support needs expansion and easier configuration, and listed debugger and sourcekit-lsp integration with VS Code and Android Studio as a high priority, which means not yet done. Swift 6.4 improved LLDB module tracking and debug builds in general, but does not claim to have solved Android debugging.

So share the logic that is expensive to get wrong twice, and leave platform integrations native. Our device comparison makes the same case from the user's side.

Comparing Apple and Android devices for business

What we don't know yet

Some questions a business case needs have no public primary answer yet.

• Binary size. The build bundles the Swift runtime (--static-swift-stdlib), so a Swift library adds more than your own code. We found no primary figure for how much.
• Performance. No published benchmark of startup time, runtime speed or the cost of a call from Kotlin into Swift. The only guidance is swift-java's own statement that JNI mode trades performance against FFM.
• The official SDK's production record. The production apps swift.org names predate it.
• Android Studio debugging after Swift 6.4. The latest statement we can source is the workgroup's, from December 2025.
• Adoption. We found no figure comparing Swift on Android with KMP or Flutter that we would quote.

If one of these decides your case, a small spike with one of your own packages answers it for your code.

A practical checklist

1. List the logic your iOS app would need on Android, and mark what has no dependency on UIKit, SwiftUI or other Apple frameworks.
2. Check that every Swift package dependency builds for Android, and that each Foundation API you use works there.
3. Pick one self-contained package and build it with the official SDK, starting from the hello-swift-java sample.
4. Call it from a Kotlin app with a Compose UI, and have your Android developer own that side from day one.
5. Measure what this article cannot give you: app size before and after, and the cost of the calls you make most often.
6. Pin the SDK, toolchain and swift-java versions, and budget time for upgrades while swift-java is below 1.0.
7. Compare the result with the same package written in Kotlin, or shared the other way through KMP, before committing.

Swift beyond Apple platforms is not new on the server, where the question is the same: what is mature, and what is still moving.

Vapor vs Hummingbird in 2026: choosing a server-side Swift framework

Swift on Android is real now, in the sense a planning meeting cares about: the Swift project ships it, documents it and maintains it. It is a way to share Swift logic with a Kotlin app, not a way to ship one app to two platforms. For a team with a Swift iOS app and logic worth keeping in one place, it deserves a spike beside KMP. For a team starting fresh, or one that wants a single UI, the older options still have the head start.