"works on my machine" now comes with the machine. build details show toolchain versions, cpu count, memory, gradle worker and jvm heap limits, os and ci, across xcode, gradle, bazel, mix, cargo and @buildoncedev. agents can read it over mcp too. no usernames, hostnames or ips collected
tuist.dev/changelog/2026.10.…
a team that's used tuist for a while asked in our shared slack channel who to talk to about moving their whole mac ci fleet onto our runners
we never pitched them runners. they came for the cache, stayed for the insights, and now want the machines too
that's the bet paying off: go wide across build toolchains, go deep down to compute, keep it one product. the runners are just one part of it
everyone needs compute. fewer people talk about needing less of it.
we built insights and cache to work in whatever environment you already run. no migration, no buying our runners first.
that's on purpose. it's how most teams meet us, and how they find out how obsessive we got about the details.
if compute is the only thing you sell, you're one big customer away from being their backend, and then their replacement.
fun fact: the first line of bazel's faq is literally 'bazel was designed to fit the way software is developed at google'
and to be fair, it's really good at that
but most teams we talk to don't have a google-shaped setup. no infra team, the cache needs a token someone pasted into a .bazelrc months ago, and lately there's an agent opening its fifth worktree of the morning
that's the gap we're poking at with @buildoncedev
your test suite has one job, and it's making ci wait. @buildoncedev now ships portable test plans, and tuist spreads its batches across ci workers. fresh machines run them with no warm-up ritual, and you get one report per shard on the same dashboard as xcode, gradle and cargo
github.com/tuist/tuist/pull/…
give a 3-task build 32 cores and it still takes 20 seconds. physics, not vibes.
wrote up why: task graphs, incrementality by location vs identity, sticky volumes, and why cheap storage isn't a fast cache.
what's the longest dependency chain in your build, and do you know where it is? 👇
the full article, with interactive simulators: tuist.dev/blog/2026/08/25/th…
Tuist retweeted
couple of sunday thoughts on how inspiring amp (product and company) is, and how we are building the appetite to land bring-your-own-tokens backed by mobil experiences to o build things on the go.
mobile is still our strength and our passion, and with the linux and. compute capabilities we have now on the platform, it’d be stupid not to do it.
we could complement existing agent driven workflows with deeper integration into ios, and validation optimisations that tap into our build infra
our mac minis also had an unforgettable evening in berghain. they are still recovering from the hangover 🤕
🤖 Made with AI
catching up with ci and ci runner provider capabilities, one at a time. how is your week going so far?
tuist.dev/changelog/2026.10.…
Tuist retweeted
@marekfort gave a talk about how to scale @SwiftLang Development at Swift Rockies, which captures all our learnings from working with small and large organizations, and it is finally live:
youtube.com/watch?v=f3nEV_Ux…
Repository checkouts in macOS runners are now cached, so they run instantly!
tuist.dev/changelog/2026.10.…
have we already celebrated that we can delegate figuring out apple bundle signing to agents? what a moment to be alive
