Why Tuist Is the Missing Piece for Agentic iOS Development

I’ve been using Tuist for my side project since day one. You might think that’s overkill for a personal project — after all, Tuist’s biggest selling points are around modularization and team scalability. But after two years of using it professionally, going back to SPM-based modularization or manually managing targets through Xcode feels like returning to the dark ages. Both are a mess, but that’s a story for another article.

Today I want to talk about something more interesting: how Tuist can supercharge your workflow if you’re getting into agentic development with tools like Claude Code.

The Git Worktrees Workflow

There’s been a lot of excitement recently around agentic development and git worktrees. The idea is simple: instead of working on one feature at a time, you create multiple worktrees from your repo — each one a fully independent working directory on its own branch — and have AI agents work on different features in parallel. You review, provide feedback, and merge. Rinse and repeat.

I decided to try it. And I have to say, I really liked it. The context switching is tough at first, but the feedback loop is dramatically faster. You’re no longer blocked waiting for one feature to be “done” before starting the next. You become more of a technical lead orchestrating multiple streams of work.

There are limitations though, especially when it comes to iOS development. And this is where Tuist turns out to be unexpectedly perfect for the job.

The Cold Build Problem

The biggest pain point with worktrees in iOS development is build times. Every new worktree is essentially a fresh checkout — no derived data, no build artifacts, nothing. On a non-trivial project, that first build can take a while.

Tuist has a built-in solution: binary caching. By running tuist cache, Tuist builds every target in your project — including all third-party dependencies — and stores them as precompiled binaries. The key insight is that all your worktrees share this cache. So when you spin up a new worktree and run tuist generate, it pulls the cached binaries instead of compiling everything from source.

What would normally be a 5-10 minute clean build becomes nearly instant project generation. This alone makes the worktrees workflow viable for iOS in a way it simply isn’t with vanilla Xcode projects.

SPM Alone Doesn’t Cut It

With CocoaPods largely a thing of the past, SPM is the default for managing third-party dependencies in most modern iOS projects. And for simple setups, it works fine. But in a worktrees workflow, SPM’s limitations start compounding quickly.

First, there’s the resolution overhead. Each worktree needs to resolve its own package graph. If you’ve ever stared at Xcode’s “Resolving Package Graph” spinner wondering if it’s actually doing anything, you know this isn’t instant — and it gets worse as your dependency tree grows. Multiply that by however many worktrees you’re running and it adds up.

Then there’s the caching problem. SPM doesn’t offer binary caching out of the box. Every worktree rebuilds every dependency from source. Your app might only take a minute to compile, but if you’re pulling in a handful of non-trivial packages, those fresh builds in each worktree become a real bottleneck.

There’s also a subtler issue: SPM’s integration with Xcode is fragile. Package resolution can fail silently, get stuck, or produce different results depending on timing. These are the kinds of issues a human developer learns to work around — reset package caches, close and reopen Xcode, clean the build folder. But an AI agent hitting a package resolution failure has no good recovery path. It just gets stuck.

Tuist sidesteps all of this. It manages SPM dependencies through its own manifest system, resolves them once, and caches the resulting binaries. Every worktree gets the same pre-built artifacts without re-resolving or re-compiling anything. You keep full access to the SPM ecosystem without inheriting its workflow friction.

Your Project Structure Is Code, Not XML

Here’s the thing about standard Xcode project files: they’re opaque, conflict-prone, and nearly impossible for an AI agent to reason about reliably. The .xcodeproj format was designed for a GUI, not for programmatic manipulation.

With Tuist, your entire project structure — targets, dependencies, build settings, schemes — lives in Swift manifest files. These are just code. An agent can read a Project.swift file and immediately understand the module boundaries, the dependency graph, and how to add a new feature module that follows the existing conventions.

This is a subtle but powerful shift. When an agent can understand your architecture, it can build features with modularization in mind rather than dumping everything into a single target and leaving you to clean up.

No More Xcode Project Merge Conflicts

If you’ve ever worked on an iOS project with more than one person, you know the pain of .xcodeproj merge conflicts. Now imagine multiple agents working in parallel worktrees, all modifying the project file simultaneously. It would be chaos.

With Tuist, the .xcodeproj is a generated artifact — you gitignore it entirely. Each worktree generates its own local project file from the manifests. Two agents working in parallel can each add files, create targets, and modify dependencies without ever stepping on each other’s toes. Conflicts, if they happen, are in readable Swift files where standard merge strategies actually work.

Selective Generation Keeps Worktrees Lightweight

When you’re running multiple worktrees, you don’t necessarily need the entire project generated in each one. Tuist lets you selectively generate only the modules relevant to your current task with tuist generate MyFeature. This keeps each worktree focused and fast — the agent working on your networking layer doesn’t need to care about your onboarding flow.

Dependency Visualization for Agent Context

Tuist’s tuist graph command generates a visual map of your project’s dependency tree. This might seem like a nice-to-have for human developers, but it becomes genuinely useful as context for agents. Before making changes, an agent can inspect the graph to understand which modules depend on what, where a new feature should live, and what the impact of a change might be across the project.

Deterministic, Two-Command Setup

One of the underrated benefits for agentic workflows is how reproducible the setup is. Any worktree can go from a fresh checkout to a fully configured project with just two commands:

tuist install
tuist generate

There’s no ambiguity, no “make sure you open the right .xcworkspace”, no manual CocoaPods dance. This makes it trivial to automate worktree setup, and it means agents can bootstrap themselves without hand-holding.

CLAUDE.md Per Worktree

This one is specific to Claude Code but worth mentioning. Since each worktree is its own directory, you can maintain a separate CLAUDE.md file in each one. This lets you give different instructions and context per feature branch. The agent working on your analytics module gets context about your event taxonomy, while the agent working on your UI gets context about your design system. Each agent operates with precisely the information it needs.

Task Isolation by Design

Each worktree is a fully isolated working directory with its own build artifacts and generated project. This means one agent’s work can’t break another agent’s compilation. If an agent makes a mess in one worktree, you can throw it away without affecting anything else. This kind of isolation is exactly what you want when running parallel experiments.

Wrapping Up

The combination of Tuist and git worktrees removes most of the friction that makes parallel agentic iOS development impractical. Binary caching eliminates cold build penalties. Code-based manifests make your project structure agent-readable. Generated project files eliminate merge conflicts. And the deterministic setup makes each worktree trivially reproducible.

If you’re already using Tuist, adding worktrees to your workflow is nearly free. And if you’re not using Tuist yet, this might be the reason to start — not because you have a large team, but because you’re about to work like one.