Advertise with Us | Sign Up to the Newsletter

MobilePro #220: Inside the Rise of Multi-Agent iOS Development

Setapp makes sure your app isn’t just listed, but seen. Plus, we handle the stuff you don’t like: distribution, licensing, billing, taxes, and customer support.

You build great software; we bring you revenue and valuable feedback to help your app grow. Hope is not a growth strategy.

Join Setapp.

Jun 3, 2026 

Hi there,

Today we are covering a piece from Walid SASSI, author of AI Driven Swift Architecture. This article stood out to us because it looks beyond the usual “AI will write your apps” narrative and focuses instead on how AI-assisted development workflows themselves are evolving.

In this article, originally published on Swift Tribune, Walid explores how multi-agent systems and Claude-powered workflows are beginning to reshape iOS development. Rather than treating AI as a simple autocomplete layer, he looks at how specialized agents can coordinate coding, debugging, reviews, and research in parallel, pushing development workflows toward orchestration instead of isolated assistance.

More importantly, the article raises a broader question many teams are starting to confront: if AI tools can now coordinate parts of the development process itself, how does that change the way engineers build apps?

TL;DR

Walid SASSI began his iOS journey in 2011 while teaching distributed systems at the University of Carthage in Tunisia. Discovering the iPhone SDK sparked a growing interest that quickly became a professional focus. For nearly a decade, he combined academia with hands-on development, teaching computer science while working as an independent iOS developer. He built apps, mastered Swift and UIKit, and developed strong expertise in software architecture. Today, he is particularly interested in AI-assisted development and how it enhances productivity while maintaining solid engineering practices.

This month Anthropic shipped a new iteration of multi-agent workflows inside Claude Code. The official name in the documentation is agent view, opened with the claude agents   command, I will use both “agent view” and “Claude Agents” in this article since the community has already started using the second term.

Multi-agent is not a brand new topic for CLI coding tools, Claude Code and Codex have both been experimenting with it for months, but the way Anthropic exposes it now is genuinely different, and worth a careful look from anyone who runs more than one AI session at a time on an iOS codebase.

A quick bit of history first. Back in February 2026, Anthropic shipped what I would call the per-session multi-agent model: each agent ran in its own Claude Code session, and you switched between them from the outside, typically with tmux .

That workflow works, but it puts the burden of orchestration entirely on you. We covered exactly that pattern in Chapter 8 of our book AI-Driven Swift Architecture, including how to spin up several agents in parallel tmux  panes and route attention between them manually.

Claude Agents replaces that. The agents now live inside Claude Code itself, in a dedicated view. You switch between them, monitor their state, and follow their full lifecycle without ever leaving the CLI. No more tmux  gymnastics, no more “which pane is the test agent in again?”, you just select the agent.

Before anything else, you need a recent enough Claude Code build. (If you are setting Claude Code up from scratch on Apple Silicon, the Claude Code for Xcode 26 guide walks through install, authentication, and pricing first.)

The agents view is a research preview and it requires Claude Code v2.1.139 or later. A simple claude update is usually enough to get you on the right version. If claude --version   reports something older, the new view will not appear and nothing in this article will line up with what you see on screen. Once installed, you open it with:

claude agents

Once you are on the right version and Opus 4.7 is selected as the model, agent view shows up as a first-class panel inside Claude Code.

This is the entry point. Each row in that panel will represent an agent. Submitting a prompt to it spawns a new agent that immediately enters a working state on the task you described, independently from whatever you are doing in the main session.

The reason this matters more than the older tmux   setup is the lifecycle. Claude Code now treats each agent as a real long-running unit with a state you can observe at a glance. The documentation defines six states, each with its own icon signal:

Those six states are the whole API surface of orchestration. Once you internalise them, multi-agent workflows stop feeling like a juggling act.

To put this into practice I picked a small, deliberately under-architected project: a Swift to-do list iOS app. The kind of codebase a lot of teams actually have lying around, a few view controllers, persistence wired in directly from the UI layer, no DI, no tests. It is the perfect playground because the work decomposes very naturally into two independent streams:

I want these two streams to run at the same time, with two different agents, on two different worktrees, and I want to see how Claude Code handles the synchronisation between them. That is the actual subject of this article, the agent UI is just the entry point.

One thing I have settled into over the last few months: I no longer write the prompt for an architectural agent directly. I describe what I want in plain language to ChatGPT first, let it shape a structured, intent-rich prompt, and then I paste that into Claude Agents.

ChatGPT is, in my experience, particularly strong at prompt shaping, it pushes back, asks clarifying questions, and produces prompts that age well. Claude, on the receiving end, is excellent at executing those prompts inside a real codebase. Using the two together is, frankly, the most productive workflow I have found.

So both prompts, the Clean Architecture refactor one and the unit-testing one, were authored by ChatGPT and handed to Claude Agents. Then I hit submit on both, back to back.

Within seconds the agents panel shows both of them in the working state, animated icons running side by side.

Notice that nothing about your main Claude Code session is blocked. You can keep working in the main thread, ask questions, read files, plan the next step, while the two agents grind in the background. This is the part the tmux   workflow could never give you cleanly: a shared, in-process control plane for your agents.

A few minutes in, one of the agents flips to yellow.

This is the part of the lifecycle that is the most underrated. The agent has hit a permission boundary, typically a tool call that requires explicit authorisation, or a destructive action it refuses to take on its own.

Until you select the agent (with ↑  / ↓ ), peek into it with Space  and answer, it sits there. No silent fallback, no “I’ll just do something simpler.” That sounds annoying, but in practice it is the single biggest safety improvement over the old tmux  model, where an agent could quietly take a wrong turn and you would only discover it three minutes later.

Agent view is entirely keyboard-driven. You move between rows with ↑  and ↓ , press Space  to open the peek panel (a quick read on the agent’s most recent output, or the question it is waiting on).

Press Enter  or →   to attach, that is, to take over the agent’s full conversation in your terminal, exactly as if you had run claude  against that session. Pressing ←  on an empty prompt detaches you back to the list.

This is where the UX win compared to tmux  becomes obvious. Switching between agents used to mean Ctrl-B  + a pane number and rebuilding context in your head every time.

Now it is two keystrokes, ↓  then Space , and you are reading the agent’s state. The “where was I again?” cost essentially goes to zero.

Eventually the architecture agent finishes its first checkpoint, the domain protocols are in place, the legacy view models redirected, the build is green on its branch. The icon turns green.

A completed agent has handed you a summary you can act on. This is also where review discipline matters: a green agent is not a merged PR. It is a proposal sitting on a branch, waiting for human review and integration.

Here is the part that quietly does most of the heavy lifting. Before any background session edits files, Claude Code moves it into an isolated Git worktree under .claude/worktrees/  . Each agent gets its own worktree (and its own branch) automatically, you never type git worktree add  yourself.

The agent does its writing in that worktree only and never touches your main checkout while it is running. (Two caveats from the docs: this isolation is skipped if the working directory is not a Git repository, or if the session is already running under .claude/worktrees/ .)

For this experiment that means two worktrees and two branches were created automatically. In my screenshot the branches are named after the prompts I dispatched, Claude Code auto-names a session from its prompt, and that name flows into the branch:

Those exact names are just what came out of my prompts; yours will look different. What is guaranteed is that each agent gets a separate worktree and branch, not that the branches follow any particular naming convention.

This is what makes parallel agents safe on a real iOS project. They share a  .git  object database, so they see the same history and can pull from each other’s branches at well-defined checkpoints, but they cannot accidentally overwrite the same Package.swift  or .xcodeproj , they are not even on the same filesystem view.

A word of caution here, and it is the one operational rule I would beg you not to skip: 

the worktree workflow only pays off if your prompt explicitly tells the agent to push its work to review, and then to merge once review passes.

If you forget that line in your prompt, you end up with two beautiful green agents and a stack of orphan worktrees that nobody integrates.

The review and merge workflow, including how we wire it into SonarQube as a quality gate before merge, is exactly what we walk through end-to-end in Chapter 8 of AI-Driven Swift Architecture. If you want the full pipeline, that is the place to go.

Occasionally an agent goes off-script, usually because the prompt was too vague or because it picked a path that is going to be expensive to undo. In that case, select it with ↑  / ↓  and hit Ctrl + X . The state flips to stopped and the icon turns grey.

The worktree is still there, the partial work is still there, nothing is destroyed. You just regain control.

From there, you can either resume with a tighter prompt, or remove the worktree and start over. This is significantly less stressful than killing a tmux  pane and hoping you committed recently enough.

Eventually both agents settle. The refactor agent has carved out a domain layer; the testing agent has produced a Swift Testing suite against it.

At that point my job as the human starts: review the two branches, merge them onto an integration branch in the right order (architecture first, tests on top), let SonarQube run, and only then open a pull request against main  . Again, that pipeline is the subject of Chapter 8 of the book; the article you are reading is intentionally focused on the agent runtime itself.

If I had to summarise, three things change compared to the February 2026 tmux  workflow:

What does not change is the engineering discipline around it. The agents still produce branches you have to review. The synchronisation between two agents working on the same domain still requires you to tell them, in their prompts, where the contract lives and when to rebase.

Multi-agent AI does not remove the need for an architect, it just lets one architect direct three or four streams of work at once.

Claude Agents is, to me, the first time the multi-agent story inside a CLI coding tool feels operationally honest. The tmux  era worked for early adopters who did not mind being the human router; this new version works for teams.

The fact that it is still flagged as a research preview should not stop you from trying it, but it should remind you that the surrounding workflow (review, merge, quality gates, CI integration) is still very much your responsibility.

If you want to go deeper into how we run that surrounding workflow on a real Swift codebase, including the review process, the SonarQube hookup, and the way we structure prompts so that two agents can synchronise without stepping on each other, that is the entire subject of Chapter 8 of AI Driven Swift Architecture. The book picks up exactly where this article stops.

In the meantime: claude update, open the agents view, and try spawning two agents on a small project. Pick something boring, a to-do list, a notes app, a weather screen, and watch how the lifecycle plays out. Half an hour with the new view is worth more than any blog post about it, including this one.

If you’re exploring how AI-assisted workflows are reshaping real-world software engineering, AI-Driven Swift Architecture by Walid SASSI and Dave Poirier offers a practical look at building modern iOS systems with AI-assisted development, architecture patterns, concurrency, and production-ready engineering practices.

🧑‍💻 Master Clean Architecture, TDD, and modernization with Claude Code support

🛠️ Build SwiftUI apps powered by Apple Foundation Models and on-device intelligence

📱 Apply MCP workflows to create AI-driven feature agents in real projects

How often do you actually update your paywall after shipping it?
Reply and let me know — curious how teams approach iteration.

Interested in sponsoring this newsletter and reaching a highly engaged audience of tech professionals? Simply reply to this email and our team will get in touch with next steps.

Cheers,

Runcil Rebello,

Editor-in-Chief, MobilePro

Copyright (C) 2025 Packt Publishing. All rights reserved. 

 Our mailing address is: 

Packt Publishing, Grosvenor House, 

11 St Paul's Square, Birmingham, 

West Midlands, B3 1RB, United Kingdom 

Want to change how you receive these emails? 

You can update your preferences or unsubscribe