Swift on Android Working Group

Community Showcase
1

Swift on Android has been making great strides. Especially with the release of SwiftPM’s Swift-SDK support, development for Swift on Android has been surprisingly straightforward.

So far, all efforts have come from individual ambitions and goals. This fragmented effort has been a great force churning away over time, but I believe that we are at the advent of large leaps.

To help unify these efforts and drive broader and faster adoption, we’re launching an Android Community Workgroup.

Why a community workgroup?

Forming a workgroup can be instrumental in ensuring the success of this new Swift ecosystem. By opening more direct communication channels and bundling efforts, we’ll ensure a healthy and thriving community-led ecosystem.

Our goal is to:
:white_check_mark: Improve and expand Swift’s Android support
:white_check_mark: Make more Swift libraries Android-compatible
:white_check_mark: Create new libraries tailored for Android
:white_check_mark: Facilitate knowledge sharing through regular calls

Some of our initial discussion topics and areas of interest are:

  • Better concurrency support within Android processes
  • Providing patches for existing libraries to better support for Android
  • Improving the debugging experience
  • Expanding support for platform native libraries

As time progresses, we’re all eager to become an official part of the Swift project under the up and coming Platform Steering Group. With the PSG currently not in place, we felt there needed to be an intermediary solution that helps accelerate Android support. However, as that evolves we’re looking forward to collaborating more tightly.

We’ve seen what Swift can do on non-Apple platforms for years now. There’s been a tremendously successful effort bringing Swift to Android, and think it’s poised to be a successful alternative to other Cross-Platform tools.

Communication

We’ll run bi-weekly calls to discuss progress, ideas, and contributions. The timing is still TBD. Discussion is currently happening on a private slack channel, through the forums and in Github issues.

Initial Members

We're really eager to announce the following initial group of members of this new group, with the list hopefully expanding.

We're looking forward to this exciting new collaboration in the Swift ecosystem.

51 Likes
2

Along the lines of making existing libraries more Android-compatible, people might be interested in this recent Skip blog post and new Swift cross-compilation status webpage, swift-everywhere.org.

Also, there is a new community CI for Android x86_64 and Android AArch64, replacing the one long provided by @drodriguez and his employer. We will be looking into fixing those few remaining compiler validation tests in that Android CI, and I will submit Android to the official CI in the coming months.

10 Likes
3

Hear hear! Such a community effort is long overdue. Thanks to @Joannis_Orlandos for spearheading this effort.

The Swift Android SDK has been quite stable for a while now, and we are currently shipping apps to the Google Play store with native Swift embedded using the Skip toolchain. But there remains a number of issues that need addressing and integration features that need implementing. We're very excited to be able to start coordinating the efforts of the various developers and groups with an interest in seeing Swift become a viable language for the development of truly universal apps.

6 Likes
4

I would love to see a concentrated effort to get official Android support for Swift.

This statement doesn't seem up-to-date anymore since the PSG is up and running. Have you reached out to them to discuss forming an official working group?

5

Thanks for the info, I was under the assumption (also at FOSDEM) that it was still being formed. I'll get in touch right away.

1 Like
6

Thanks @Joannis_Orlandos for bringing together this working group. This will be a huge boon to raising awareness and adoption of Swift on Android!

1 Like
7

I'm glad Swift SDKs are working for this. Let me know if there is anything you need to make this easier in Swift Package Manager. Exciting to see the community come together.

2 Likes
8

They're doing amazing! We'll let you know if anything comes up - so far my SwiftPM experience has been pretty good already.

1 Like
9

@compnerd, @drodriguez, @etcwilde, and I were discussing setting up discussion about Android SDK as the community currently has multiple efforts underway. We would love to streamline a solution to officially support it on swift.org.

@compnerd was planning to write a vision document and share it with the platform steering group and the community.

5 Likes
10

If people are available, I would like to propose a call this Friday, February 14th, at 10:30 AM PST to start a discussion about official Android support.

7 Likes
11

I've also added some initial support for targeting Android using the Android NDK in the recently open sourced Swift Build build system engine project (right now only C/C++ support is tested, no Swift).

Once Create an alternate SwiftPM build system called Swift Build by cmcgee1024 · Pull Request #8271 · swiftlang/swift-package-manager · GitHub lands, this will work towards helping Swift Package Manager to build for Android.

I'm quite eager to discuss with the community how we reconcile Swift Build's initial NDK support with Swift SDKs. It could be that we remove Swift Build's initial knowledge of the NDK and focus on a Swift SDK only path instead. On the other hand, we might also want to have a mechanism for Swift SDKs to delegate to an external SDK like the Android NDK without having to vendor all of its content (like the initial Android Swift SDK from @finagolfin does today), and that's where Swift Build's "built in" support could be useful.

One reason for this that comes to mind is that there may be platforms where use of the native C/C++ compiler is preferred (or required) over the Clang/LLVM shipped with the Swift toolchain for whatever reason. Exactly how we support Swift SDKs for cross compilation in Swift Build and how that fits into its existing model with Apple platform SDKs is something we're tracking here: Swift SDKs Cross Compilation Support · Issue #6 · swiftlang/swift-build · GitHub.

4 Likes
12

We've now updated the official compiler README to link to the new Android CI provided by @Marc_Prud_hommeaux at Skip. Thanks to @drodriguez and his employer for donating the prior community Android CI server for so many years. The good news is that thanks to all the work @drodriguez, @compnerd, and to a lesser extent myself put into fixing those tests over the years, there are only a couple dozen failing now out of almost 15k compiler validation tests run on the community Android CI, even after a year of the previous CI being broken by the compiler bootstrapping changes on linux.

Pinging long-time Android users @Geordie_J and @mstokercricut, would be good to tie your experience and input into this recent community workgroup effort too. :smiley:

6 Likes
13

This would be ideal in my opinion. There are already some unresolved differences in behavior between the old driver and new swift driver, and Swift Build is likely to introduce new ones. My preference would be that the Swift Android SDK contains only the Swift modules and necessary dependencies (curl, xml2, etc) that aren't already part of the NDK, and defer to a local NDK installation for the rest. This is possible to achieve today but requires passing some extra flags when calling swift build, and I know there has been some discussion/debate about fixing the new driver to not require those flags but it doesn't appear fully resolved yet.

2 Likes
14

@compnerd touched on this "two layer" approach in SwiftDriver: initial work to properly handle android cross-compilation by compnerd · Pull Request #1560 · swiftlang/swift-driver · GitHub as well, and might have some input.

15

Having to understand the implications of repackaging the NDK was a bit above my capacity to comfortably recommend something. There exists a similar problem on Windows, and a similar solution - a thin SDK that augments the system SDK.

This is close to what we are doing at The Browser Company. The "Android SDK" is a thin SDK containing the necessary items from the Swift standard library and core libraries. The key difference is that I don't think that the "and necessary dependencies that aren't already part of the NDK" part entirely holds true - e.g. ICU and I think SQLite are technically present but we do not use them from the NDK. The important aspect of what you are suggesting however does hold - we try to be as (mathematically) closed as possible. The one area that is slightly fuzzy is the C++ runtime which I believe we need to re-distribute (which the NDK requires).

Yes, sadly there are some flags that are currently needed :frowning:. The desire is to get to the point (at least on Windows) where you can do something along the lines of:

tcrun -sdk Android.sdk swiftc -target aarch64-unknown-linux-android28 -emit-executable -o reduced reduced.swift

There are a few problems currently holding that up. Unfortunately, my focus recently has been on trying to get the bootstrapping support on Windows working which required a number of long standing issues to be resolved. In doing so, I hope to enable the early swift driver and as a result be able to fix these issues without having to replicate the work across the C++ and Swift implementation of the driver.

I think that support for this type of SDK layout is very useful to polish as it makes it easy to enable Swift for environments where the SDK may not be redistributed and is not available without a license (i.e. not F/OSS). It also would reduce the size of the redistributable.

At least on Windows, there is an additional bit that is relevant - the idea of having support for online installers/swiftly where it would be possible to simply install a SDK on demand, as well as the ability to support first-party/third-party (depending on perspective) Swift SDK distributions.

1 Like
16

My understanding is that this already works well. I simply chose not to go that route with my Android SDK bundle to further simplify using it, as you should be using the latest Android NDK most of the time anyway.

17

Hey @mishal_shah can you send us invites?

18

We are game. Please send an invite to marc@skip.tools and abe@skip.tools.

Good to see the wheels start moving!

2 Likes
19

@Joannis_Orlandos @Marc_Prud_hommeaux, I just sent the invite. If anyone else is interested, please DM on the forums. Looking forward to the meeting.