Swift 6.3 on Android: the end of the wall between iOS and Android?
Alexandre
··
Reading time: 8 min
Swift can now build Android apps. Officially. With an SDK maintained by the Swift community and endorsed by Apple. If someone had told me that last year, when I chose native Swift for Livate and explicitly refused cross-platform tools, I would have laughed.
Swift 6.3 dropped this week with a hefty list of new features, but it's the Android SDK that's making all the noise. First official SDK, Java/Kotlin interop tools built-in, unified cross-platform build engine. All of it carried by an Android Workgroup that's been working on this since WWDC 2025. The Hacker News post hit 201 points and 116 comments within hours. On X, it's the number one topic in the iOS community.
As a solo iOS dev who built two apps in pure Swift, Livate and Waku, this announcement hits close to home. One language, two stores. Sounds like the dream. But is it actually usable today? And more importantly, is Apple playing fair?
Let's break it down.
Swift 6.3 lands on Android: what actually changes
Swift 6.3, released on March 28, 2026, includes the first official SDK for Android, allowing Swift developers to compile native ARM code for Android, share packages between iOS and Android, and integrate Swift into existing Kotlin/Java apps using Swift Java and Swift Java JNI Core tools. It's the most ambitious release since Swift 6.0 in September 2024.
The SDK is the result of months of work by the Android Workgroup, created at WWDC 2025. Pioneers like Readdle (Documents, Spark, Scanner Pro) and flowkey (piano learning app) had been using Swift on Android unofficially for years. The difference is that now it's officially supported.
In practice: 5 commands to compile Swift for Android
# 1. Set up the Android NDK
export ANDROID_NDK_HOME=/path/to/android-ndk-r27d
# 2. Install the Swift SDK for Android
./setup-android-sdk.sh
# 3. Verify the Android target is available
swift sdk list
# swift-6.3-RELEASE_android-arm64
# 4. Create a standard Swift package
swift package init --type executable
# 5. Build for Android
swift build --swift-sdk android-arm64
# Produces a .so in .build/android-arm64/
The result: a .so file (shared object, a native library) that goes into the jniLibs folder of a standard Android Studio project. On the Kotlin side, you declare native methods and call Swift code directly.
What you can share (and what you CAN'T)
This is where honesty matters. Here's an example of Swift code that compiles for both iOS and Android without modification:
// UserGoal.swift — shareable business logic iOS/Android
import Foundation
struct UserGoal: Codable, Sendable {
let id: UUID
let title: String
let targetDate: Date
var completedActions: Int
var totalActions: Int
var progressPercentage: Double {
guard totalActions > 0 else { return 0 }
return Double(completedActions) / Double(totalActions) * 100
}
var isOnTrack: Bool {
let elapsed = Date().timeIntervalSince(targetDate)
let expectedProgress = min(elapsed / totalDuration, 1.0)
return progressPercentage >= expectedProgress * 100
}
}
This kind of code (models, calculations, business rules, networking, async/await, local persistence) compiles on both sides. It's exactly what I have in Livate: goal tracking logic, progress calculations, network services.
What you cannot share: the UI. SwiftUI does not run on Android. Period. No plans announced by Apple to change that. On the Android side, it's Jetpack Compose or XML. Two separate UI layers, one language for everything else.
And SwiftUI is 80% of Livate's code. My pure Swift business logic represents maybe 20% of the codebase. That 20% could be shared. It's useful, but it's not "one code, two apps."
What I think
What strikes me is the gap between the ambition and the reality of the tooling. The idea is powerful: a Swift dev can now target Android without learning Kotlin. In theory. In practice, the Hacker News community says it clearly: "the experience of using Swift for anything other than apps for Apple platforms is very painful." Three toolchains to install, sparse documentation, onboarding that takes several weeks.
But I remember SwiftUI at its launch in 2019. Buggy, incomplete, barely usable in production. Today it's the standard. Swift on Android is at the same stage: the foundations are there, the rest will follow.
Click to enlarge
Swift vs Kotlin Multiplatform: the match nobody expected
Swift 6.3 offers the best raw performance on Android (native compilation, no managed runtime) but the least mature tooling among current cross-platform solutions, facing a Kotlin Multiplatform that has 3 years of production head start and native Android Studio integration. That's the takeaway from every comparison published this week.
Criteria
Swift 6.3
Kotlin Multiplatform
Flutter
Performance
Native (no runtime)
Native (Kotlin)
Near-native (Skia)
Shared UI
No (SwiftUI iOS only)
No (native UI)
Yes (Dart widgets)
Hot reload
No
No
Yes
Tooling maturity
Low
Good
High
Language
Swift
Kotlin
Dart
Advantage
Native iOS language
Android Studio integration
Hot reload, community
The direct competitor is Kotlin Multiplatform. Same philosophy: shared code for business logic, native UI on each platform. Jacob's Tech Tavern published a detailed analysis: KMP has the advantage of native Android Studio integration, a larger community, and several years of production head start. Swift has the advantage of raw performance and the fact that it's THE native language for iOS.
Flutter, on its side, remains unbeatable for iteration speed with hot reload. But you leave the native ecosystem on both sides, and binaries are heavier (IJIES comparative study, March 2026). For an iOS dev who wants to stay "native," it's a tough compromise.
The missing link: Skip.dev
Skip.dev released Skip 1.8 right after Swift 6.3 (announcement). Skip transpiles SwiftUI into native Jetpack Compose. It's the missing link: you write SwiftUI, you get Compose on the Android side. Still young, but it's the only tool that promises complete "write once" in Swift.
My take
As a Swift dev, KMP is the rival I'm watching most closely. Same approach (shared code, native UI) but with 3 years of production head start.
What Swift 6.3 brings is an argument nobody else has: it's the native language of iOS. If you're already an iOS dev, you have nothing to learn. Your Swift, your packages, your habits, everything carries over to Android. KMP asks you to learn Kotlin. Flutter asks you to learn Dart.
Swift 6.3 is the only one that says: stay where you are, we're coming to you.
Honestly, for Livate and Waku, I'm not porting to Android tomorrow. The tooling isn't there. But the direction is clear. And for a solo dev who builds everything with Claude Code, adding an Android build target to an existing Swift project could become as simple as a flag in the Package.swift.
Click to enlarge
What is Apple's game? (and why SwiftUI will never run on Android)
Apple has never officially positioned Swift as a cross-platform language, but the creation of the Android Workgroup and SDK support in Swift 6.3 constitute an implicit strategy shift aimed at countering Kotlin Multiplatform and anchoring developers in the Swift ecosystem. That's the unspoken truth of this release.
Kotlin Multiplatform had been gaining ground for 2 years. iOS teams were starting to migrate their business logic to Kotlin to share it with Android. That's exactly Apple's nightmare scenario: iOS devs learning Kotlin and thinking "wait, why don't I just do everything in Kotlin?" Swift on Android is the answer: stay in Swift, we'll give you Android.
No SwiftUI on Android = deliberate choice
SwiftUI doesn't run on Android, and Apple hasn't announced anything to change that. It's a choice, not a technical limitation. Apple wants the UI experience to remain superior on iOS. They want iOS apps to have something Android apps don't. Shared code, yes. Identical user experience, no.
Peter Bisljak, iOS dev, puts it well on X: "The only thing holding multiplatform Swift/SwiftUI back is the fact that there's no official endorsement by Apple, and we're all relying on third-party tools." And on Hacker News, a popular comment goes further: "There is also the question of trust." Will Apple maintain this effort? Or is this a retention play that will be abandoned in 2 years?
WWDC 2026 in June: the missing piece?
WWDC 2026 is 10 weeks away. If Apple announces official SwiftUI support on Android, or even a cross-platform SwiftUI subset, everything changes. If Apple says nothing, the message will be clear: cross-platform Swift means shared code, not shared UI. And the community will have to decide if that's enough.
My take: Apple opens the door but keeps the key
Honestly, I understand the strategy. If SwiftUI ran on Android with the same quality, why would a user buy an iPhone over an Android? The app experience is part of the equation. Apple knows it. And they're not going to give it away.
But for us devs, it means we're in a gray zone. We can share code. We can't share the experience. And it's up to each dev to decide if this half-promise is enough.
Swift 6.3 comes with an advantage nobody else has: it's the native language of iOS. But it also comes with a limitation the others don't have: no shared UI. That's the tension of this release. And it won't be resolved before WWDC.
In the meantime, here are 3 concrete things to do:
Your Swift code is worth more than before. Every line you write for iOS could compile for Android tomorrow. Your Swift investment is no longer limited to a single ecosystem.
Wait before porting, but architect for it. Separate your business logic from your UI. Use protocols rather than direct SwiftUI dependencies in your services. When the tooling is ready, you'll be ready too.
Watch Skip.dev and WWDC 2026. These are the two events that will decide whether cross-platform Swift stays a promise or becomes reality.
Conclusion: an open door, not a bridge
Swift 6.3 doesn't solve cross-platform. It opens a door. The Android SDK is official, the build system is unified, Java/Kotlin interop is there. It's real, it's usable, it's supported.
For me, a solo iOS dev building Livate and Waku in pure Swift, it's the best news of the year. Not because I'm porting my apps tomorrow. But because for the first time in 10 years of Swift, "what if we went to Android?" is no longer an absurd question. It's a question of timing.
If you're an iOS dev, does Swift 6.3 make you want to look at the Android side? Hit me up on Twitter/X or in the comments.
Alex
Key takeaways
Swift 6.3 ships the first official Android SDK: native Swift code on both platforms
SwiftUI does NOT run on Android: only business logic is shareable, not the UI
KMP is the real competitor: same approach, 3 years of production head start
Skip.dev and WWDC 2026 are the two events to watch for the future of cross-platform Swift
