Teaching the cache to notice what it missed
Tuist's targets can now declare additional hashing inputs, so cache invalidation finally accounts for the things that quietly change a binary, from codegen templates to environment variables.
It is a quiet week on the changelog, with a single, focused change to Tuist’s caching layer. That change, though, addresses a problem that has been hiding in plain sight. A target’s output depends on more than the files you wrote and the libraries you declared. Code-generation templates, tool versions, configuration files, environment variables: each of these can quietly change the resulting binary, and until now none of them moved Tuist’s target hash. The cache would happily serve a stale artifact, and the failure mode would stay invisible until something downstream broke.
The fix lands as additionalHashingInputs, a way for a target to name the things outside its declared dependencies that should also participate in its identity. The mental model is simple: if a change to it can change the binary, then it belongs in the hash. Codegen templates are the obvious case, but the same logic applies to a pinned tool version, a config file read at build time, or any environment variable whose value reaches the build. By making those inputs explicit, Tuist turns a silent risk into a declared dependency, as described in the release note.
What I appreciate about the framing is the honesty. Cache invalidation is one of those problems where the easy answer is to recompute more often, and the harder answer is to recompute exactly when it matters. Tuist chose the second path. The platform is admitting that its previous model of what influences a build was incomplete, and it is giving developers a clean way to extend that model themselves, target by target, without opting out of caching entirely.
In practice, this shifts a small piece of responsibility from the tool to the team. Engineers who maintain targets with hidden inputs, such as a template that expands into Swift sources or a script that reads a config file, now have a direct mechanism to keep their cache honest. Teams that have not audited their targets for these inputs can do so at their own pace; the cache will simply get more correct as the surface area gets named.
There is a broader thread worth pulling. Across the ecosystem, the cost of trusting a cache has been rising, particularly as AI-assisted code generation introduces more moving pieces into a build. Any tool that wants its cache to stay trustworthy has to keep widening what it considers part of a target. Tuist’s move here is a concrete step in that direction, and additionalHashingInputs reads like an invitation for projects to define what their targets really depend on, rather than what the manifest happens to mention.
A quiet week, then, but a meaningful one for anyone who has ever wondered whether a cached artifact was really the one they wanted.
Narrated from 1 public drop.