Introducing the Swift Fundraising Cooperative

[Geordie_J (ephemer)]

Hi @Finagolfin, I am unfortunately spread too thin to be focussed on Swift on Android in anything more than a cursory glance once in a while. The work here is fascinating for me and I place a high value on it - but it’s about 1% or less of what I do.

I didn’t mean to ignore your requests - I just don’t have remotely enough time to invest in joining workgroups and discussions, or anything very useful to add for that matter. I also don’t mean to come across as annoyed about not being able to fund work in the past - at the time I understood the answer was „no“ and had to focus on solving the problems at hand myself.

That all said, I would be very happy to support the work you and others are putting into it. What you’re doing with the SDKs is fantastic and I’d be very happy to support that ongoing work.

If I have any requests it would be to continue to clean up the SDKs - potentially by working to upstream patches etc. If I look at the Android SDK GitHub page today I see a significant chunk of instructions describing things that need manual effort to either get the SDKs working and/or built. I know it’s a different ecosystem entirely but I find it very impressive that the Swift Wasm project seems to have ironed out all of those kinds of issues (manual paths, patches, etc).

The last time I checked Swift Android there were different SDKs per CPU arch, and it seemed that a significant chunk of the NDK was bundled in each. I’m not sure if that’s still the case but those are usability / DX issues that could be considered. It seems that Swift SDKs have the ability to support multiple targets each (not sure if there are still open issues with that?), and maybe there’s a way of using a pre-installed NDK? Again these are just ideas - I’d be happy to be a sponsor even if it didn’t mean work on those things specifically.

The easiest way for us to sponsor would be through github (it’s one click) but I didn’t see that possibility on your profile. Is that an option for you? Would it make sense to use the SwiftAndroid organisation instead?

——

Edit:

The „only“ thing we need is up-to-date and well tested cross-compilation toolchains for (preferably static) library compilation on Android (arm64 is most important for us right now). From macOS mainly but also from Linux for CI etc. Cross compilation with SwiftPM would make the most sense. But CMake is also a valid use-case for the broader ecosystem - right now we are calling SwiftPM from CMake so it integrates with Android Studio, which is not that great.

We worked hard to remove Foundation from our stack but seeing that continue to be tracked and working on Android (ideally even for old taget platform versions - eg. from Android 7 or 8) would be a big win for the ecosystem on the whole.

Another thing that comes to mind is seamless debugging of compiled Swift code using tools like Android Studio. We never got that working and it’d be another huge win to get this in a place where it „just works“.

Hope that gives an idea of our priorities at least. Thank you for your continuing efforts!

[Finagolfin]

@Geordie_J

I am unfortunately spread too thin to be focussed on Swift on Android in anything more than a cursory glance once in a while. The work here is fascinating for me and I place a high value on it - but it’s about 1% or less of what I do.

Yes, I figured you were too busy, and given that there wasn't much I could do about those legacy bugs, that you'd moved on to other matters.

@Geordie_J

I would be very happy to support the work you and others are putting into it. What you’re doing with the SDKs is fantastic and I’d be very happy to support that ongoing work.

Great, I'll reach out to you privately and we can discuss.

@Geordie_J

The last time I checked Swift Android there were different SDKs per CPU arch, and it seemed that a significant chunk of the NDK was bundled in each. I’m not sure if that’s still the case but those are usability / DX issues that could be considered.

That hasn't been the case in years: I suggest you try out the latest Swift 6 SDK bundles, it is a pretty easy experience.

@Geordie_J

The „only“ thing we need is up-to-date and well tested cross-compilation toolchains for (preferably static) library compilation on Android (arm64 is most important for us right now). From macOS mainly but also from Linux for CI etc. Cross compilation with SwiftPM would make the most sense. But CMake is also a valid use-case for the broader ecosystem - right now we are calling SwiftPM from CMake so it integrates with Android Studio, which is not that great.

We worked hard to remove Foundation from our stack but seeing that continue to be tracked and working on Android (ideally even for old taget platform versions - eg. from Android 7 or 8) would be a big win for the ecosystem on the whole.

A lot of this works today. Anything that doesn't, please file issues on my Android SDK repo, like the --static-stdlib issue you filed late last year.

@Geordie_J

Another thing that comes to mind is seamless debugging of compiled Swift code using tools like Android Studio. We never got that working and it’d be another huge win to get this in a place where it „just works“.

Take a look at some of the work that community Android workgroup members have started on. I intend to work with them in the coming months to polish that up more.

@Geordie_J

Hope that gives an idea of our priorities at least. Thank you for your continuing efforts!

Thanks for this feedback and your sporadic comments/likes over the years, as we were an isolated few using Swift on Android. With the upcoming work to make it official and improve the developer experience, the Android workgroup hopes to change that in the coming years.