Swift can now officially target Android — a fourth cross-platform option
Swift 6.3, released in March 2026, ships an official first-class Android SDK, and the Skip framework that bridges SwiftUI to Jetpack Compose went fully open source in January — giving iOS-first teams a real option for reaching Android without Flutter, React Native or Kotlin Multiplatform.
5 July 2026
Swift 6.3 shipped in March 2026 with an Android SDK positioned alongside Static Linux and WebAssembly as a first-class, officially maintained target — not an experiment. The Swift on Android Working Group, founded in early 2025, was promoted to an official Swift Platform Steering Group workgroup as the effort moved from preview builds to production. Over 2,200 Swift packages already build for Android. Separately, Skip — the framework that compiles Swift and SwiftUI into native Jetpack Compose for Android from a single codebase — went fully open source in January 2026 after three years as a licensed product.
Why this changes the cross-platform conversation
Until now, a team building natively for iOS in Swift and SwiftUI faced a real rewrite to reach Android: a second codebase in Kotlin, or a jump to Flutter or React Native with its own learning curve and trade-offs. Skip on top of official Swift-for-Android support means an iOS-first codebase can now target Android with no separate runtime and no second language, which is a materially different proposition than Kotlin Multiplatform (which shares logic but not UI) or Flutter/React Native (which mean starting over in a different language). This sits alongside — not above — the frameworks we’ve already covered: Flutter still leads adoption at roughly 46% market share, and React Native’s new architecture is now stable in production. Swift-for-Android is younger and its ecosystem is thinner, but it closes a gap that mattered specifically for teams already committed to native Swift.
So what
For founders who started with an iOS app and are now weighing how to reach Android, this adds a genuine fourth option to the shortlist rather than forcing a binary choice between “stay native and build twice” or “go cross-platform and rewrite.” Which route makes sense still depends on the app, the team, and the timeline — that’s a conversation worth having before committing to a stack. See how we approach these trade-offs on our services page, or get in touch to talk through your specific build.