Android package compatibility now showing on swiftpackageindex.com

Development Android
,
1

I was excited to read today that SPI is now publishing the Android build status for all the packages they index! To quote directly from their blog post:

Swift on Android is also receiving plenty of community effort, including a recent announcement of a community working group. The swift-everywhere.org site has also been tracking Android compatibility for several months.

Plenty of work went into making Swift work on these platforms, and it seemed like a great time to add them to our compatibility testing. So we did! For the past week, the Swift Package Index build system has processed 35,000 builds to test compatibility. As of today, all builds are complete, and you can see Wasm and Android compatibility on every package page.

Results

Of ~9,000 indexed packages […] 27.9% build for Android. We find that remarkable, given that reliance on Apple-specific frameworks automatically makes many packages incompatible.

It’s safe to say that Swift is expanding beyond its Apple-focused roots. Windows and Linux have been officially supported for years, and Wasm and Android are starting to make their way down that path. It’s great to see.

Kudos to @daveverwer and @finestructure for getting this up and running (along with the WASM build status). This will be a great boon for developers who are assessing the level of effort needed to get their Swift projects working on Android.

26 Likes
2

Yes, this is an excellent step for the community.

Doug

6 Likes
3

Thank you Marc. We only took the final step. It wouldn't have been possible without all the contributions to get the project to the stage where this was possible.

7 Likes
4

Thank you Marc! It turned out to be a much simpler task than anticipated thanks to all the work you all have put into the SDK and the cross-compilation process :heart: It's wild that compiling for Android and Wasm is almost the same thing!

4 Likes
5

27.9% build for Android

What are the numbers for linux and Windows, for comparison? Is there anything we can do right away to get Android closer to the linux number, or is it simply adding yet another import Android in a bunch of packages?

6

What are the numbers for linux and Windows, for comparison?

I expect Dave or Sven can answer more definitively, but based on swift-everywhere.org, 3,659 were building successfully for Linux, which is around 40% of their ~9k packages.

Is there anything we can do right away to get Android closer to the linux number, or is it simply adding yet another import Android in a bunch of packages?

In my experience, adding #if canImport(Android) import Android is the single most common way to get a package that was already building for Linux to build for Android. The nice thing about the SPI interface is that they link to the build failure logs, so for example you can see why the marmelroy/Zip package fails:

/host/spi-builder-workspace/Zip/Zip.swift:209:51: error: cannot find type 'FILE' in scope
207 |
208 |             var writeBytes: UInt64 = 0
209 |             var filePointer: UnsafeMutablePointer<FILE>?
    |                                                   `- error: cannot find type 'FILE' in scope

I wrote a porting guide in the Skip blog post Bringing Swift Packages to Android, which expands on your own guidance. It could be interesting to trawl through the build failure logs and scan for common errors to see if there are any easy fixes.

4 Likes
7

That's correct, it's pretty much exactly 40% (3,581 out of 9,008 packages).

1 Like
8

I'm so excited to see this for Android (and Wasm, too)!

I took a look at some of my own packages. Some are successful, and others... well, aren't. :sweat_smile:

I hope to resolve them all soon.

2 Likes
9

This one is a textbook case of just needing an extra #if os(Android) check in a dependency. I've filed a PR.

3 Likes
10

I'll also take this opportunity to remind people about the Swift Android Action, which enables you to build and run all your test cases against an Android emulator as part of your GitHub CI workflow.