We are excited to announce the creation of the Android Workgroup!
The primary goal of the Android workgroup is to establish and maintain Android as an officially supported platform for Swift.
To learn more and get involved with the Android Workgroup:
I was gonna write congratulations Swift. But actually more like: congratulations Android developers! Today Android devs can develop in the great language Kotlin, soon they can develop in the AMAZING language Swift!
This is really cool to see! Well done everyone who has worked on this so far!
Off topic:
I am happy to join with you today in what must be recognized as the growing chorus of developers—dreamers, creators, tinkerers—who believe in a brighter, more unified future for app development.
I have a dream.
I have a dream that one day, we shall no longer be bound by the invisible walls of platform segregation. That the beautiful, expressive power of SwiftUI shall not be confined to the Apple walled garden—but shall run freely on Android, blossom on Windows, and shimmer across the Web with WebAssembly.
I have a dream today.
I have a dream that I, a humble developer, can write code once—with clarity and elegance—and see it come alive on every screen, in every hand, on every system. That my app, written in SwiftUI, shall run with native grace on Android phones, flow fluidly on Windows desktops, and sparkle within the browser through the magic of WASM.
I have a dream that the syntax I love—where views are functions of state—will no longer be siloed, but shared. That the power of declarative UI, of Combine and Swift Concurrency, will speak fluently across ecosystems, uniting Kotlin and C#, Flutter and React, in a new common tongue of elegance.
I have a dream today.
I dream of a future where onboarding new users means building for humans, not platforms. Where I do not fear Android fragments or wrestle with Windows APIs. Where I no longer port apps—I launch experiences. Simultaneously. Seamlessly. Swiftly.
I have a dream that the engineers of tomorrow will learn Swift not for iOS alone, but because it speaks the universal language of software—because it is the poetry of platforms united.
Let us not wallow in the valley of vendor lock-in. Let us not dwell in the despair of duplicate codebases. Let us not fear the native versus cross-platform debate, for we know there is another way.
This is our hope.
This is the faith that I return to the keyboard with: that one day, SwiftUI will rise beyond Mac and iPhone. That its canvas will stretch wide to include every device. That its promise will be for all developers—regardless of their operating system.
And if this is to be true—if SwiftUI shall indeed set us free—then we must rise up now.
We must support open-source efforts. We must rally behind community-driven ports, experiment with compilers, embrace SwiftWasm, applaud Kotlin interoperability, and believe that the impossible is merely the undone.
We cannot wait for permission. We must build it.
Let us code, then, not in despair but in defiance. Not in silence but in celebration. Let every line we write echo this dream.
From the servers of Cupertino to the smartphones of Seoul.
From the cloud datacenters of Seattle to the classrooms of SĂŁo Paulo.
From the laptops in Lagos to the browsers in Berlin.
Let SwiftUI ring.
Let it ring across all screens.
Let it ring across all people.
Let it ring with the joy of simplicity and the power of unity.
I have a dream today.
It's a great day to be a Swift user! Man, I'm really loving all the progress happening in the Swift ecosystem!
This post has garnered a lot of views, so let me point people at how you can learn more. All this is publicly available info on github or the Android forum linked above, just gathering some of the most important to make it easier for those coming in new.
The best place to keep track of the status of the Android workgroup's effort is the github roadmap. You can see the concrete issues that remain, what we are working on, and pick areas you'd like to contribute to.
As listed there, we are currently working on official CI jobs that will build Swift 6.2 and 6.3 Android SDK bundles for the AArch64, x86_64, and armv7 architectures and run them through most of the compiler validation suite. Once that is ready, we will distribute 6.2 and 6.3 snapshot Android SDK bundles that can be used with the official 6.2 and 6.3 snapshot toolchains.
In the meantime, take a look at those github issues, slap an emoji on whatever interests you, and reach out to any workgroup member, whether here or on github, about anything you'd like to contribute to.
If you can't wait for the official SDK bundle snapshots, there are third-party SDK bundles you can try for now: my open source bundle, the Skip toolchain, or the open source Readdle toolchain. All three are developed by workgroup members who are contributing towards the upcoming official Android SDK bundle.
Is it going in the direction of KMP?
Not necessarily: Swift is just a really nice, efficient, and memory-safe language that works at all levels of the stack, from embedded devices and servers, to desktop and mobile applications. Swift is at home in environments where garbage collection isn't viable or desired, and can potentially run with a very minimal runtime library dependency.
That being said, a very obvious use case here is to be able to share code between your Android and iOS apps. I've written about this on the Skip blog: Native Swift on Android, Part 3: Sharing a Swift Model Layer | Skip. In this sense, Swift would be taking the place of KMP as a shared business logic layer for the application.
Swift could also be used to build the entire application, which I've written about at Fully Native Cross-Platform Swift Apps | Skip. This scenario would be more comparable to Compose Multiplatform (CMP), since the entire app stack is created using Swift, but with platform-native user interfaces (i.e., SwiftUI and Jetpack Compose) for each device.
How much or how little you use Swift in your Android application will vary based on your project's needs. You could also simply use it as a "better C++" for portable low-level logic. Since the Swift Android SDK is based on Android's NDK, it fits together with any other native code you may be using in your Android app.
The Browser Company also bundles Android SDKs into their toolchain distributions which are at GitHub - thebrowsercompany/swift-build: Swift toolchain builds by The Browser Company.
I won’t harp about it again, but we also use Swift with Flutter so that the business logic can be written in Swift across Android, iOS and embedded Linux. You can Google for FlutterSwift.
Hello,
I’m an Android developer and have never worked with Swift before. However, the announcement of Swift for Android caught my attention. I value diversity and having options. I’m curious—will it be possible to use Jetpack Compose with Swift in the future? Or is there any plan to bring SwiftUI to Android?
I am sorry to ask this, but like in a lay man term how we are going to use it, i mean we write code in swift but how we are going to build it for android? what about the UI design do we design for both iOS and android and business logic in swift?
How is the Android Workgroup addressing seamless interoperability between Swift and existing Kotlin/Java codebases on Android? What are the best practices for integrating Swift into a hybrid Android app?
So, which IDE/code editor we will be able to use for Android development with Swift?
Will it all be in Xcode only or we can use Windows with Visual Studio code too?
I want to part of this project & group. Please add me.
Its a great idea and will solve most of the issues for native developers.
which IDE/code editor we will be able to use for Android development with Swift?
Swift Stream IDE extension for VSCode is on its way to support Android development, including both libraries and apps. It works anywhere VSCode and Docker are available, so you'll be able to use it on Windows too. The library target is actually already ready, I just haven’t published the update yet, as I was hoping to release it together with the app (UI) target, which is taking a bit more time than expected.
The same as KMP.
According to the project needs, you can write an specific class in Kotlin, or programming the data and domain layer in Kotlin which is shared for both platforms and maintain the UI Layer for each platform , or developing the whole project in Kotlin including the UI module thanks to Compose multiplatform.
At the end, both approaches look like similar.
That's a good news. excited.
Will we be able to develop full native Android apps with this? For example, native accessibility services, and other apps who rely on System APIs rather than just cross platform stuff?
I would be happy if I can use it for developing my native Android apps thereby keeping Kotlin and Android studio aside.
Yes, absolutely — that’s the goal! I also dream of the day when I can just use Swift to build native Android apps and not worry about Android Studio or Kotlin. And honestly… we’re really close! It almost feels like a forgotten memory from 2020, when we already had that magical experience up and running! :)
Of course, a lot is happening behind the scenes to make that possible.
First, it’s about compilation. Back in the day, it was quite a journey – I remember using special toolchains from Readdle and later from vgorloff. Compiling vgorloff’s toolchain for M1 by myself was a whole adventure on its own. But today, thanks to the amazing work by @finagolfin, we now have a well-maintained Android Swift SDK that works with the official Swift toolchain. It is that strong foundation that we needed.
Second, there’s the whole world of JNI. Since 2016, there have been tons of wrappers (including mine) trying to make this easier. Now with the new swiftlang/swift-java bindings generator added to the mix… what to choose? :)
Third, it’s about how to actually write the code. I’ve been playing with this since Swift 5 back in 2020, sharing thoughts and experiments in Swift Stream Discord. Native threads, main loop hopping… it wasn’t easy, but it was super exciting because it opened up a lot of new horizons. Now with Swift 6 and structured concurrency, things are so much better. Like, really much-much simpler. Yaaay!
Fourth, it’s all about tooling. Back in 2021, I built a VSCode extension and a CLI tool called droidy as part of the SwifDroid project. It was maybe a bit ahead of its time – the community didn’t get super excited back then (only a few fellow nerds joined in), and unfortunately the toolchain it was based on stopped updating in 2022, so I never did a full release. Still, huge thanks to finagolfin again – his consistent effort gave us a working path to compile Swift code for Android in a smooth way today.
The most important thing for tooling now is generating the Gradle project and making sure all the required .so files for Swift are included. I’ve taken everything I learned from those early experiments and built it into the Swift Stream IDE. In fact, that whole IDE idea actually came out of my original VSCode extension. It was a fun and kind of breathtaking project where you could write a pure Swift Android app, select a device, hit Run, and see it on screen. Magic 
This is how native slider works via JNI with handler passed into Swift (on pretty old android phone, vid from ~2021)
P.S. [offtop] I feel like the lack of feedback and engagement back then was a big reason why this didn’t take off earlier. The hype we’ve seen in the last couple of days proves something important: the community responds when it sees official announcements. But still, "is it ready yet?" sounds kind of funny when we’re an open-source community, where we’re all working on enthusiasm, and that enthusiasm powers itself only through consistent community feedback. I think maybe Swift still feels like a vendor creation rather than a true open-source project, and that’s why folks are always looking to the next WWDC to get new things… idk [\offtop]
The workgroup has made no decisions on UI frameworks yet. What you want is possible, but not at the top of our work stack right now.
SwiftUI is a proprietary UI for Apple platforms, there is no indication it is being ported anywhere else.
Take a look at this nice example with the Skip toolchain, which is available on macOS right now. We hope to have something similar at swift.org, without the UI integration initially that they also include.
Initially, yes, we are focused on cross-compiling business logic right now, and will look at UI options next.
Apple is currently working on such swift-java interop, we hope to tie into that.
See Marc's answer above and we have workgroup members who have been doing this for many years, so we will have some more detailed answers on that eventually.
As listed in the roadmap, we're looking at VS Code now, which already has a Swift extension, and will look at more IDEs in time.