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.
3 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.
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
Are there any plans to support Skip on Linux and Windows?
Yes! No ETA, though.
2 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