Swift Macros, introduced alongside Xcode 15, generate code via the compiler but significantly slow down build times because each macro must compile SwiftSyntax and its ten-plus transitive dependencies. Benchmarks on a MacBook Air M2 show a clean release build of a fresh macro package taking roughly 196 seconds. The piece explores why this happens, including SwiftSyntax's lack of API/ABI stability, and outlines three potential fixes: making SwiftSyntax API/ABI stable, compiling macros to WebAssembly via WasmKit for cross-platform binary execution, and fingerprint-based binary caching. Tuist has already implemented binary caching for Swift Macros via its 'tuist cache' command to speed up local and CI builds.
Table of contents
What is a Swift Macro?A non-API-stable SwiftSyntaxWhat if we pre-compile SwiftSyntax?WebAssembly to the rescueWhat Tuist is doingClosingQuestions this post answers
Why do Swift Macros make my build times so much slower?
Swift Macros require the compiler to build SwiftSyntax and its more than ten transitive dependencies, then statically link them into a binary executable for each macro. A clean release build of a freshly created macro package takes around 196 seconds on a MacBook Air M2 with 16GB RAM, and adding more macros compounds this cost further. daily.dev surfaces practical fixes like these for developers wrestling with slow Swift build pipelines.
Can I use WebAssembly to speed up Swift Macro compilation?
Yes, this is a proposed approach discussed in the Swift community forums: compiling Swift Macros to .wasm binaries and running them via the WasmKit runtime instead of statically linking SwiftSyntax on every build. This would solve build slowness on Darwin, Windows, and Linux without requiring ABI stability changes, though it is not yet officially adopted by Apple. Developers tracking emerging Swift tooling proposals can follow discussions like this on daily.dev.
How does Tuist cache Swift Macros to speed up Xcode builds?
Tuist extends its binary caching feature to Swift Macros, frameworks, and bundles by fingerprinting them so subsequent builds reuse previously generated binaries instead of recompiling. Running the command 'tuist cache' stores these binaries, and anyone on the team generating an Xcode project afterward benefits from the cached artifacts, avoiding the repeated cost of compiling SwiftSyntax dependencies. daily.dev helps teams comparing Swift build caching tools stay on top of tooling changes.