That's alright; If you're not going to make a port, the community will. Amazing work on this by the way. SwiftUI port to Android would probably quintuple the impact and, not exaggerating, 10-100x the adoption of the toolchain.
4 Likes
That's great news! I think converting directly to Java classes instead of using Kotlin in the background would help it run more efficiently. How can we join the group?
Love this!
Is there any plan to showcase some benchmark/metrics on the performance and memory usage improvements that Swift can offer in Android, and what will be the impact to app size when using Swift on Android?
Is there any plan to have an Embedded mode similar to wasm SDK for app size related concerns?
2 Likes
Being developing a UI library both in SwiftUI and Jetpack I can only applause for this announce. I'll follow the workaround with great interest.
1 Like
我非常想让我的安卓同事感受并理解到Swift语言的安全和美好！
2 Likes
We are now posting preliminary builds of Swift 6.2 and soon 6.3 Android SDK bundles on github, if anyone missed it.
Already under way, not quite SwiftUI though.
I doubt the Android workgroup will build any UI library ourselves anytime soon, but we will probably just supply a list of such Swift GUI frameworks that we've tested as working on Android, like the aforementioned FlutterSwift, and help make those work better.
Take a look at the SDK bundles link above, we've posted a Slack invite there for the Swift OSS effort. Come talk to us in the #android channel. Alternately, you can start working with us on github or email or DM in this forum with one of the Android workgroup members.
For example, @ColemanCDA has long put out Swift packages supporting Android and is currently discussing Android Binder support in that Slack channel. He will probably join the workgroup soon.
We are looking for people willing to contribute like him, though it doesn't have to be in the same way or to the same depth. You could just help contribute to getting more OSS packages building for Android on the Swift Package Index or writing better documentation. There are many ways to pitch in and join the Android workgroup. 
Not that I know of, but it is a good idea. We expect good results from performance and memory usage, but app size will get worse, depending on which Swift features you use (see more info below), because unlike Swift on iOS or Java/Kotlin on Android, Swift isn't bundled with the Android OS.
I'll put together a post with some numbers in the coming months, remind me if I don't.
No, the embedded WASM mode is meant for bare wasm access, where you don't even use WASI. On Android, where every device ships with the Bionic C library, we gain nothing by not using it. I had this wrong, see Max's correction below. Given the minimal savings from not even using the Swift stdlib and adding a full embedded mode, we have not tried that yet.
Swift already has a model where you can greatly strip down what you package from the Swift runtime libraries, by not including import FoundationInternationalization in your code or your package dependencies.
We'll make sure that works well for Android, and are looking at ways of minimizing FoundationInternationalization also.
2 Likes
This is incorrect. Embedded Swift SDK for Wasm does rely on WASI and does include and link WASI-libc. If users don't adopt any of its APIs, those dependencies will be eliminated with optimizations, but they are there when needed.
There's no correlation between the presence of a C library and use of Embedded Swift mode. You can already enable and use Embedded Swift on Darwin, where libSystem is present and would be linked. Similarly in the future, it would make perfect sense for a Swift SDK for Musl to ship an Embedded Swift subset.
The main gain of Embedded Swift is that with forced specialization of generics and additional restrictions the dependency on major parts of Swift runtime is eliminated. In a lot of cases this allows creating binaries that only take only tens or hundreds of kilobytes. I can't speak for all Android users and developers, but I would anticipate some of them to be interested in this. Whether the trade-off is worth it is another question.
In my experience, this only reduces the final binary by a few megabytes, but not enough when there's a need for it to be much smaller.
1 Like
I have never used WASM or the new Embedded Swift mode, so only had a hazy notion of precisely what they invoked: thanks for the correction.
OK, good to know.
On which platform? On non-Darwin platforms, FoundationInternationalization ships with its own copy of ICU, including a large icudata array with info for a lot of timezones and languages. Our tests show almost 30 MB saved when not using it, surprised you're seeing anything different.
Are there any plans to support Skip on Linux and Windows? @marcprux
1 Like
Are there any plans to support Skip on Linux and Windows?
Yes! No ETA, though.
4 Likes
SwiftUI may be proprietary to Apple, but if developers realize they can write stuff for Apple and get an android product too, we’ll get more iOS products. Similar to how developers wrote Win apps to run on OS/2
1 Like
@Finagolfin Hey, I've been using your SDK successfully so far and wanted to ask you a few questions:
- Is your repo going to be the blueprint for an official repo on
github.com/swiftlang? If so, any deadline? - Is there any overlap between your work and this seemingly outdated document? I still haven't managed to build a stdlib with those instructions, but I can't exclude PEBKAC. Either way, maybe it's worth merging the document into a "single source of truth".
- For being dynamically linked, if my library doesn't use Foundation, am I 100% safe without including the heavy SDK Foundation *.so in my Android app? Could it break at runtime for whatever reason beyond me?
Thanks!
+1. I believe that promoting Swift library/freestanding development as much as app development would appeal to a lot of non-Swift programmers. Swift is insanely convenient at C interop, as the Embedded Swift initiative is showing. However, I'd rather leave this for another thread because it's a bit OT here (not completely, but mostly).
No, my Android repo only does three things: release SDK bundles, produce snapshot bundles on the CI, then test all of them with around a dozen Swift packages on the Android emulator. Work is under way to move the first two to swift.org, using a Dockerfile in the swiftlang/swift-docker repo, while the Swift Package Index is starting to build orders of magnitude more Swift packages for Android. So my work in my Android repo will now be subsumed into these larger official efforts, which I will continue to chip into.
Yes, if you look at the commits for that doc which was first submitted 9 years ago, I have been updating it for the last five years. We have gone way beyond that now, so I intend to update it on how to cross-compile a full Android SDK, including Foundation and Testing, in the coming months.
I haven't updated it since last year, it's possible some regressions have crept in. Feel free to message me any problems you're seeing and I'll take a look.
Meaning a page on swift.org or what? I'd rather just update that doc.
If you're sure you're not importing it anywhere in your packages or their dependencies, I don't see why you can't leave out the library. That said, all my experience is with building Swift command-line executables on Android, maybe @marcprux can give you better counsel on packaging Android apks.
I am enjoying your blog posts on cross-platform Swift, btw, keep writing. 
1 Like
Fair, fair. Maybe decoupling the workflow into a standalone script would already encourage others to test it locally and contribute. I find the README a bit intimidating to follow. 
My bad, that doc is on GitHub, not on the homepage. Never mind.
Oh, thank you! You don’t imagine how often I’d rather give up and switch to another language like Go, but then I choose the joy of doing something “new” in a world where everything seems to have been done. I’m positive that sticking with Swift today will feel like a greater accomplishment one year from now.
Which workflow and README are you referring to here, the old one from my repo or the new one we are submitting with the Dockerfile? Either way, as I said a couple weeks ago, my plan is to update the original github.com/swiftlang doc you linked- which I was surprised to see was one of the top three most-visited pages in that compiler repo up to a month after this announcement thread was started- to include instructions on building and using a full Android SDK, not just the stdlib as it has today.
Before doing that, I want to upstream all patches that the Dockerfile is applying: it is now down to just three lines added or modified. 
Unfortunately, one of them is a long-standing swift-driver bug that affects cross-compilation to all non-Darwin platforms, so while I have a fix for that working on linux/mac, taking me a bit longer to work it through the Windows CI, a platform I don't use.
Heh, I know exactly how you feel, as I have been working on this Android port for almost 7 years now, until recently all on my own time. The key question is whether you think Go or Swift would serve you and your app better. Don't worry about "accomplishment," but follow your nose on what you think will ultimately work better.
2 Likes
This one, I’d try to make it a standalone script outside of the action:
I’m so close to the finish line that now I know I’m sticking with Swift 100%. The thing is, if you asked me months ago, Swift was completely out of the question for the purpose. When I suddenly saw Swift as a possibility, I abandoned the idea of Go or Rust, as I’d rather use something I’m proficient with. If I have to go down that path, I’d probably go all in and use C without all the middlemen.
That is an old, unused fork of my long-running Android CI: I went ahead and disabled that fork's CI just now. You can try building an Android SDK using my script in that CI step, if you set up the Swift linux toolchain and Android NDK sysroot properly as shown in the prior steps. The advantage of that script is it can be used to build any one of Swift 6.1, 6.2, and 6.3 using the official Swift toolchain release or snapshots, though it also cross-compiles extra toolchain repos like llbuild and SwiftPM for Android, just as a test that each Android SDK is working, so you can remove those extra build-script flags.
Alternately, you can use either build-docker or build-local, if you don't want to use Docker, from the swift-docker pull I linked above to build only Swift 6.2 or 6.3 Android snapshot bundles- it won't build 6.1 or extraneous repos like SwiftPM- and if you set the BUILD_COMPILER=1 environment variable, it will run the full compiler validation suite for each Android architecture you build (minus the 5-6% of executable tests, which require an Android emulator or adb-connected device to run).
If you want to build an Android SDK bundle yourself, I suggest you try out the latter, which we've submitted to the official CI. If you run into any problems, feel free to DM me or start a new forum thread for that.
Great, file any issues you run into on github or start a forum thread if you have questions, looking forward to hearing more on your blog or elsewhere. 
Unsure what you mean, you are most familiar with C? I consider C the middleman, and would like to push it out.
Btw, you and others may be interested in this interview that Android workgroup member @marcprux just did with the Swift Package Indexing podcast, thought it went well.
2 Likes
I don’t know if I’ll have the required patience again, but I’ll let you know if so. I must say, I find the toolchain excessively complicated to build for my taste, and for my poor Internet connection. :-)
Yeah, I’ve never used Go or Rust. I can understand how you see C as the middleman for your goals, but for a cross-platform library with a fair amount of low-level code, C is still the best choice IMHO. Ubiquitous tools, fast build time, no dependencies, small footprint... Just unbeatable, until Swift strips down its runtime dramatically. :-)