Announcing the Swift SDK for Android

Announcements
,
1

Swift has matured significantly over the past decade — extending from cloud services to Windows applications, browser apps, and microcontrollers. Swift powers apps and services of all kinds, and thanks to its great interoperability, you can share code across platforms.

The Android workgroup is an open group, free for anyone to join, that aims to expand Swift to Android. Today, we are pleased to announce nightly preview releases of the Swift SDK for Android.

This milestone reflects months of effort by the Android workgroup, building on many years of grassroots community effort. With the SDK, developers can begin developing Android applications in Swift, opening new avenues for cross-platform development and accelerating innovation across the mobile ecosystem.

The Swift SDK for Android is available today, bundled with the Windows installer or downloadable separately for use on Linux or macOS.

Getting Started

We've published a Getting Started guide to help you set up your first native Swift code on an Android device. The Swift for Android Examples help demonstrate end‑to‑end application workflows on Android.

With the Swift SDK for Android, you can now start porting your Swift packages to Android. Over 25% of packages in the Swift Package Index already build for Android, and the Community Showcase now indicates Android compatibility.

The swift-java project enables you to interoperate between Java and Swift. It is both a library and a code generator, enabling you to integrate Swift and Java in both directions by automatically generating safe and performant bindings. To learn about generating bindings to bring your business logic to Android, check out the recent Swift Server Side meetup talk by Mads Odgaard.

Next Steps

This preview release opens many new opportunities to continue improving these tools. We encourage you to discuss your experiences, ideas, tools and apps on the Swift Forums in the Android Category.

The Android workgroup is drafting a vision document, currently under review, for directing future work regarding Swift on Android. This vision will outline priority areas and guide community efforts to maximize impact across the ecosystem. In addition, we maintain a project board that tracks the status of major efforts, as well as official CI for the Swift SDK for Android.

If you're as excited as we are, join us and help make this ecosystem even better!

59 Likes
2

I was excited to see the official announcement for Swift on Android examples, though I was a bit sad not to have been included.

For context, the Android team previously reached out to me about using my examples. I was happy to assist, providing all my code, additional information, and an offer for further help. While it was disappointing to learn of their final decision through the public announcement without a direct response, I want to continue channeling my efforts positively into the community.

If your goal is to build a full Swift or hybrid Swift+Java Android application - packaged into an APK without using the standard Kotlin/Java/Gradle/Android Studio - my repositories may be useful. This approach is particularly helpful for iOS developers or those new to Android, as it doesn't require learning new knowledge about new development tools.

To complement the official announcement, you are welcome to explore my repositories if you wish to build a full Swift or Swift+Java Android application packed into an APK.

I believe I currently offer the only solution for direct SwiftPM to APK packaging. Furthermore, my examples are the only ones that provide full Swift Concurrency support with a working @MainActor or DispatchQueue.main, which can significantly help in adapting libraries that rely heavily on regular main-thread switching context code syntax.

Here are my most relevant example:

  • android-example - My most complete and complex minimal application. It demonstrates a Swift or Swift+Java application with touch, mouse, gamepad, keyboard or system events and painting window buffer with colors. For a 100% Swift application, you can simply comment out the JAVA and ACTIVITY variables in the Makefile. To use Foundation libraries uncomment FOUNDATION variable.

I have also developed these standalone Swift libraries to make development smoother:

  • ndk - Simplifies importing Android C headers, eliminating the need to write "CTarget" wrappers.
  • native-activity - Provides Swift-friendly structs and enums for working with Android's NativeActivity.
  • android-assets - For loading assets and documents directly from the APK bundle.
  • java - A stable, working alternative to the currently crashing on Android official swift-java tool.

For reference, here are the legacy examples I previously provided on the forum, which have now been replaced by the android-example above:

  • android-example-c - Uses google's native-app-glue C code similar to official example. It was rewritten in android-example above to 100% Swift code with @MainActor entry point and isolation to application lifecycle.
  • android-example-java - Just regular Android Java app with Swift functions import to Java and Java to Swift.

I am also currently working on a cross-platform macOS-iOS-Android example with a UI (using OpenGL on Android and OpenGL/Metal on Apple platforms). I hope to share it with the community soon and eventually adapt it for Linux.

If anyone encounters issues with these projects or needs help getting started, please don't hesitate to reach out. I will do my best to provide support, as I am truly amazed by the freedom Android offers and am keen to help popularize Swift on this platform.

22 Likes
3

After one day, the associated blog post is the seventh-most upvoted HN submission ever related to Swift, will probably end up in the top five. It is doing well on reddit and lobste.rs too, plus articles are starting to be written.

Thank you to all Android contributors who got us to this milestone a decade after the initial Android patch to Swift, to all the Swift devs over the years who reviewed our Android pulls, to the core team and Mishal for shepherding this port into the official CI and website, and to the website workgroup for their extensive supportive feedback on this blog post. :grinning_face:

Sorry, I reached out to you privately on behalf of the Android workgroup a couple weeks ago while the new swift-android-examples repo was still private, but then forgot to get back to you once you graciously offered your examples and help, as we would then need to get special permission to get you access to the private repo. No "final decision" was ever made.

Now that the repo is public and all it takes is a pull request from you, we are ready to review and include your examples, :smiley: if you are still interested.

12 Likes
4

One nice aspect of this new Android SDK: I believe it is the first to ship with a full 32-bit native Swift SDK on swift.org, because it provides Android armv7 too. Or at least it may be a close second, as the Windows toolchain CI builds and tests both Android armv7 and i686 also. I'm not counting 32-bit wasm as it isn't native but more of a cross-platform encoding, 32-bit watchOS because it's not in the OSS toolchain, :wink: and the 32-bit embedded targets don't include the Swift stdlib and corelibs, ie not a full SDK.

I have not run the corelibs tests or tested packages for Android armv7 in a while, but last I checked a year ago, most of the NIO tests still passed.

Of course, that also means new tests in the compiler validation suite will have to be adjusted to support 32-bit, but I believe people are already doing that for the 32-bit watchOS CI. Thanks to those unsung sticklers, as the Android armv7 support is mostly drafting off of their work. :sailboat:

1 Like
5

The Windows toolchain targets 32-bit Windows as well, for what it's worth. (Although for how much longer, I couldn't tell you. Is there a 32-bit Windows 11 I don't know about?)

6

:laughing: Thanks for the correction. I have never used the Windows toolchain, or the mac one for that matter, really need to remedy that one of these days. :wink:

1 Like
7

Also the 32bit embedded targets (e.g. armv7m-apple-none-macho etc) do contain the stdlib, nearly nothing would build otherwise.

1 Like
8

How many bits is avr-none-none-elf? :slight_smile:

All that aside, I’m excited to work with the community to find SwiftPM’s place in the Android ecosystem. I have a lot of requests to support external build systems like CMake and am working through some ideas there for SwiftPM plug-ins to generalize the concepts. I am assuming (without looking hard yet) that gradle integration would help here.

2 Likes
9

Windows 11 dropped support for booting on 32-bit, but still very much supports 32-bit applications.

10

@compnerd Perhaps that's an argument in favour of dropping 32-bit Windows support. Is the subset of Windows applications that a) use Swift and b) are 32-bit particularly large?

11

My intuition is that that is still very far away.

As a related example, armv7 was introduced in 2012 with Windows RT and was quite short lived yet is only just now being removed in early previews of Visual Studio 2026. Windows 11 does not run armv7 apps anymore, that was dropped in 11 24H2 (end of last year).

12

The OS has been 64-bit for a very long time. The user space however remains heavily 32-bit. Part of this is due to the fact that you are still limited in addressability limitations of 4GB. It is beneficial to stick with 32-bit applications, and as an example - vim still recommends 32-bit.

1 Like