Kristopher Baker iOS roots · Product systems · AI-assisted workflows
← Inkwell

shipped · 2026.07.14 · 2 min read

Inkwell builds on Linux now

Inkwell has only ever run on macOS for me, installed through Homebrew. I finally tried building it straight from source on a Debian 12 box (aarch64) with the Swift 6 toolchain, mostly out of curiosity about what would break. Three things did, and none of them were hypothetical. CryptoKit is Apple-only, so I moved the one place that needed it over to swift-crypto's API-compatible Crypto module, gated behind #if canImport(CryptoKit). Glibc's stderr is not annotated the way Darwin's is, so Swift 6's strict concurrency checking rejected every fputs(_, stderr) call outright, replaced now with FileHandle.standardError.write. The sneaky one was resource bundles: SwiftPM names the generated bundle directory <pkg>_<target>.resources on Linux instead of the .bundle Apple platforms use. The build succeeded either way, but on Linux the theme silently failed to load at runtime, so a working build produced a site with no styling and no way to tell why from the build log alone.

I verified the fix the honest way, swift build, then inkwell init and inkwell build on a fresh scaffold, checking that the HTML, feeds, sitemap, and assets all came out right. CI is still macOS-only, so this was a manual pass rather than something a green checkmark can vouch for going forward. That bothered me enough that the next thing I did was add a Linux build-and-test job to CI, so the next portability regression fails loudly in a pull request instead of quietly on someone's Debian box.