Why do I care about swift-stdlib-tool?

swift-stdlib-tool is a command line tool that's packaged with Xcode toolchains distributed by Apple. A lot of the process Xcode undergoes to compile and package apps is hidden to its users, but not swift-stdlib-tool: it can be invoked on its own.

I think the existence of swift-stdlib-tool has significant benefits for app developers, so when I heard that Apple removed swift-stdlib-tool from Xcode 8.3b2, I was disappointed. Xcode 8.3b2 reportedly still performed the same functionality, but it did so internally; there was no longer a way to run just the swift-stdlib-tool portion of a build.

In response, I encouraged people to file bug reports. I've since heard that the official reply from Apple has been promising, which has encouraged me to write down why I care, as well as some hopes for the future.

What is swift-stdlib-tool?

swift-stdlib-tool scans a Swift app for its dynamic library dependencies, then copies those libraries to a location in the app bundle where the app can load them. You can read about the technical details of how it works here.

Why do I care?

The fact that swift-stdlib-tool is a standalone tool is beneficial to me in two ways:

  1. I can invoke swift-stdlib-tool on the command line in order to understand how it works. If Xcode isn't packaging the Swift runtime with my app correctly, I can invoke swift-stdlib-tool to see what's happening. This is a lot easier to debug than invoking xcodebuild, which does a lot more than just copy libraries. (This reminds me of the Unix philosophy, which advocates for many small programs with a single responsibility, as opposed to a few large programs that attempt to solve many problems at once.)
  2. Other methods of building and packaging apps, such as Google's Bazel or Facebook's Buck, can invoke swift-stdlib-tool instead of writing their own logic to copy Swift libraries. I think these tools benefit a lot of people, and I want to see them succeed in harmony with Apple's tools as much as possible.

Imagining an even better Xcode

There's another good reason to keep swift-stdlib-tool as a small command line utility, and it has to do with "modularity." Specifically, by utilizing Xcode toolchains, I think it would be possible to make it easier for Swift to be used to write apps on other platforms, including Android.

Xcode toolchains

Apple's Swift toolchain releases are a good example of what I mean by "modularity." If I want to test out whether my app compiles using the current state of Swift 3.1, I can download a toolchain and select it in Xcode. I could even build a Swift 4.0 toolchain from source and use that. This allows me to use Xcode, one of my favorite code editing environments, even when working with non-standard compiler toolchains.

By activating a Swift toolchain, Xcode uses different versions of Swift when compiling:

$ xcrun --find swiftc
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swiftc
$ xcrun --toolchain org.swift.3020170309a \
             --find swiftc
/Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2017-03-09-a.xctoolchain/usr/bin/swiftc

And since swift-stdlib-tool is a standalone executable in a toolchain, the same is true for it as well:

$ xcrun --toolchain org.swift.3020170309a \
             --find swift-stdlib-tool
/Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2017-03-09-a.xctoolchain/usr/bin/swift-stdlib-tool

Anyone, not just Apple, can package an Xcode toolchain. This means I could package an Xcode toolchain with a specialized implementation of swiftc and swift-stdlib-tool.

Custom toolchains for developing Swift apps on Android?

Since Swift's open source release, it's been extended, by engineers who aren't employed by Apple, to support Android, Windows, and other platforms.

But despite the fact that many are aware that Swift runs on Android, not many people know how to build a Swift app for Android. Could I make this easier? I imagine that I can, by creating a "Swift for Android" Xcode toolchain.

It's already possible to create an Xcode toolchain that contains the Swift runtime compiled for Android, but other parts are missing. Among them is an implementation of swift-stdlib-tool that could scan an Android executable (an ELF object, rather than the Mach-O object files that Apple's swift-stdlib-tool is capable of scanning) for its Swift dependencies, then copy them to an appropriate location. I could provide such an implementation as long as swift-stdlib-tool is a standalone executable. If it were hidden within xcodebuild, on the other hand, this would no longer be possible.

Better still would be if swift-stdlib-tool was available as open source – there's no reason to distribute a separate implementation in my own toolchain if the canonical version can also handle ELF and COFF executables. Apple wouldn't pay its engineers to implement this logic, but I'd do so happily.

Of course, there are many other reasons why Xcode could not, in its current state, be used to compile and package Swift applications to run on Android. But theoretically Xcode could one day become capable of doing so, and (aside from the other benefits I mentioned above) I think keeping things like swift-stdlib-tool as modular utilities in an Xcode toolchain is helpful to that end.