After my last blog post back in March about the Swift Package Manager (SPM) and some experiments I was layering on top of it, I actually continued with a bit more work, but didn’t get around to blogging about it.

The Swift Package Manager is a package manager and build system, which comes bundled along with Swift itself.

If you’re developing on a Mac, the obvious route to go down is to use Xcode, which has its own fairly capable build system.

Xcode only runs on the Mac though, so clearly you can’t rely on that if you want to be able to build on Linux. The fact that SwiftPM is present wherever Swift is - on Linux builds as well as Mac builds - is a distinct advantage, and makes it an attractive alternative for cross-platform work, minimising the amount of faffing around required when setting up on a new machine.

Unfortunately, whilst SwiftPM is a decent package manager, at the moment it is quite basic as a build system.

It has some nice clean aspects to it, relying on conventions to infer which code to build, which makes it very easy to get going with. However, it lacks some facilities from Xcode that are fairly essential for substantial products:

• specifying standard build settings in external files
• being able to hook in code generators or other pre-build steps
• being able to package up the built binary with other resources
• being able to execute other arbitrary code as build phases
• being able to code sign, archive, or post-process the final product
• being able to install the final product locally, upload, or submit it somewhere

The SwiftPM team have stated their intention to address many of these limitations, but right now the details of what, how or when are thin on the ground.

As I’ve been experimenting with Swift on Linux, and looking into Xcode-alternatives, I didn’t want to wait for jam tomorrow, so I started wondering what it would take to add the missing capabilities, and how best to attempt it.

The result of this is a tool I’ve imaginatively called builder.

I seem to spend at least half of my programming life transferring values between an object or structure and some sort of dictionary format.

Swift’s Codable support is really great for doing this when you’ve got JSON or a Plist, but not all dictionary data ultimately lives in a file.

I spent a bit of time over the last couple of days looking into the options for Swift without Xcode, aka Swift on Linux.

What it seems to boil down to is: there’s not a lot out there for free.

I expect you’re wondering what I’ve been up to. I don’t blame you, I’ve been wondering too.

In order that we can all sleep easy at night, I think I’m going to blog a bit of a developer diary.

I’m not sure I’ll manage a post every day, but I’ll try to keep a regular commentary.

In all seriousness I don’t expect it to be of great interest to anyone else, but in the past I’ve found it a useful discipline to keep a log of what I’ve been doing each day, and I may as well do it here.

Since finishing with Sketch I’ve been playing with a few very small new projects, but I’ve also spent a lot of time catching up on a large backlog of boring admin tasks.

I’ve no doubt that I’ll talk about some of my own projects in the future, but actually the thing I’ve been working on most over the last couple of weeks is the open source project Safari-FIDO-U2F.