Swift Stream IDE: Announcing Android Library Target

Four months ago, I announced the Swift Stream IDE extension for VSCode, which adds support for multiple Swift development targets like Web, Server, Embedded, and Pure. I also mentioned that an Android target was coming soon. For me, this was more than just a feature. It was a deeply personal goal and a long-held dream, one I'd attempted to achieve many times before.

Thanks to the new Android support in Swift 6 and @Finagolfin’s swift-android-sdk, that desired goal became very close. I began active development, pulling together all my experience from past years and designs from a dedicated Android VSCode extension I had worked on previously.

The development process, however, was a deep dive into complexity, leading me through many unforeseen pitfalls and rabbit holes. I had carefully designed a vision for a simple Swift-on-Android setup. A month in, I had a version of the foundational library, JNIKit, that I believed was ready. However, real-world testing revealed its limitations, and the following three months were spent refining its design as I absorbed the full nuances of JNI development.

Today, I'm excited to launch the Android stream, starting with support for building native Swift libraries. The initial release focuses on the Library target, with the UI target and corresponding project templates still under active development.

This focus addresses a critical pain point: while compiling Swift code for Android has become more straightforward, the real challenge often begins after the build. This gap between compilation and seamless integration is where developers encounter unexpected complexity, having to manually bridge the worlds of Swift Package Manager and Android's Gradle-based build system.

This is exactly the problem Swift Stream IDE is designed to solve. It handles the entire integration process automatically by providing:

  • A containerized development environment, carefully prepared for Android development.
  • Easy switching between toolchains and SDKs.
  • Compilation for all Android targets: arm64-v8a, armeabi-v7a, x86_64.
  • Automatic generation of Android Library Gradle projects.
  • Automatic copying of required .so files into the Gradle project.
  • Automated management of the Gradle project's dependencies.

Manually copying the compiled .so files and all their required dependencies from the SDK is a tedious and error-prone process. This task repeats every time you switch to a new Swift version, increasing the chance of mistakes as you manage the new set of files.

To avoid this issue, I created a runtime-libs repository with all these libraries in one place. This allows them to be added easily to any project via JitPack:

dependencies {
    implementation("com.github.SwifDroid.runtime-libs:compression:6.1.3")
    implementation("com.github.SwifDroid.runtime-libs:core:6.1.3")
    implementation("com.github.SwifDroid.runtime-libs:foundation:6.1.3")
    implementation("com.github.SwifDroid.runtime-libs:foundationessentials:6.1.3")
    implementation("com.github.SwifDroid.runtime-libs:i18n:6.1.3")
    implementation("com.github.SwifDroid.runtime-libs:networking:6.1.3")
    implementation("com.github.SwifDroid.runtime-libs:testing:6.1.3")
    implementation("com.github.SwifDroid.runtime-libs:xml:6.1.3")
}

This is also useful if you want to add several Swift libraries from different authors to your Android app, as they can all share the same dependencies.

After compilation, Swift Stream IDE checks which modules are required by your code using readelf and some predefined logic. It then automatically adds or removes these runtime-libs dependencies from the Gradle file. The provided library project is ready to be imported into your app locally or prepared for distribution.

I have described how to start a library project in this article The Swift Android Setup I Always Wanted.

This entire workflow is powered by JNIKit, a library I created to provide a pure Swift interface for JNI, completely hiding the complex C-style boilerplate.

For the technical details of the JNI layer itself, the fundamentals of JNIKit are available in its README on GitHub.

Swift Stream IDE is free and open source, licensed under MIT. I've built it to solve my own needs, and I truly hope it solves yours too. I’d love to hear your feedback. It’s incredibly valuable.

You can get started right now by installing Swift Stream IDE from the VSCode Marketplace.

This is just the beginning for Swift on Android, and I'm excited to see where we go from here.

9 Likes

Interesting effort, as usual though, I’d encourage folks picking up any new work on JNI libraries to collaborate on polishing up core bits of GitHub - swiftlang/swift-java: Java interopability support for Swift where we’re collaborating with the android workgroup and all kinds of swift/java interop interested folks.

We’re going to be splitting off a sub-part of the package into a JNI focused bit, without any dependencies, and you can follow the work on that here: Separate swift-jni package from swift-java by marcprux · Pull Request #384 · swiftlang/swift-java · GitHub

It’d be great to collaborate on the foundational pieces in one place, so we don’t have to reinvent type mapping many times over; while there of course remains space for folks to innovate in things built on top of those shared foundations :slight_smile:

If you have any questions or would like to get involved please let me know and I’d love to chat :slight_smile:

6 Likes

Great news! Looking forward to trying this out soon. :smiley:

Some notes:

  • Happy to hear you were able to use my SDK, but you have two very similar paragraphs saying so above, possibly a copy-paste error. You might want to merge or excise one of those.
  • Have you had a chance to try out the new Android SDK bundle snapshots for Swift 6.2 and 6.3 that the Android workgroup has been posting? If so, let us know how it is going and file any issues you encounter.
  • Did you compare your JNI approach to the official swift-java effort that Konrad brings up? It would be good to know why you chose to go your own way there.
  • Packaging like you are doing has been something the Android workgroup has been discussing working on next. If you're interested, we'd be happy to discuss ways we might collaborate.
  • We plan to work on and list multiple editors that support Swift on Android, perhaps we can add yours to that eventual list.

Great to see your work moving forward, don't hesitate to reach out to the Android workgroup here or on github or Slack.

2 Likes