
TL;DR
Xcode's agents are OK. If you work on one thing at a time with the editor open, pick Xcode. It ships in the box, and Apple wired the agents into the most important parts of the toolchain.
FlowDeck is for when one agent isn't enough. Several agents, each on its own branch with its own build and its own simulator. Models you swap mid-task without losing the thread. Agents that validate their work. Skills managed in one place for every agent and something watching the PR while you sip your coffee.
Both run real agents against Apple's toolchain. Both open the Xcode project you already have. The difference is the output, and who each one thinks you are. Xcode assumes you're pair programming with one agent. FlowDeck assumes you're running a team of them and reviewing what comes back.
You don't have to pick one forever. Both can open the same Xcode projects.
Side by side
| Xcode 27.2 | |
|---|---|---|
Built for | Running several agents at once, and the work after the code | One engineer pairing with an agent inside the classic IDE |
Agents | Claude Code, Codex, OpenCode, Cursor, Grok Build | Claude Agent, Codex, Gemini, Antigravity, plus any ACP agent |
Models | Agent, model, effort and permissions per chat, changed mid-conversation | Model and mode per conversation, no effort setting for Claude |
Switching providers | Agent Handoff between all agents. FlowDeck carries a summary and the transcript to the new agent | Start a new, clean conversation |
Skills | Skills Manager: FlowDeck's Apple skills plus your own, installed for every agent from one window | Apple's own agent skills, plus custom skills installed for each agent |
Parallel work | One Git worktree per session, with its own branch, chats, build state and simulator | Several conversations at once on the project you have open |
Isolation | Agents never share a working copy unless you put them in the same session. They also don't share the same simulator | Conversations don't coordinate edits, so you split work by file, or create worktrees manually and open multiple Xcode copies |
Planning | Read-only planning agent, its own model, a Plan Library shared across sessions |
|
Validation | Build, run, test and clean through the FlowDeck CLI, scoped to the session, with typed diagnostics | Agent builds and produces a diff. You test manually |
Tests | Test Explorer by plan, target and suite, with Fix all via AI | Test navigator and the agent's own test runs |
Simulator | Live, interactive simulator in the window. Each session can get its own simulator or device | Device Hub, with simulators and physical devices |
Project editing | Schemes, launch options, xcodebuild options and Swift packages per session | The whole project editor, Interface Builder, Instruments |
Review | Diff viewer with line comments sent back to the agent, commits and PRs. No undo | Artifacts pane with diffs, inline annotations, per-turn history and undo |
After the PR | PR Autopilot sends failing checks and conflicts back to the same agent for fixing | You manage PRs on your own |
Release | Your signing and your pipeline | Xcode Cloud, TestFlight, Organizer |
Price | $79/year, CLI included | Free |
Requires | macOS 26, Apple silicon | macOS Tahoe 26.6, Apple silicon |
Flowdeck Studio
Take the job you'd do in Xcode's this week.
Split it into three sessions in Flowdeck and and go grab a coffee.
Start 14-day trial
Who's in the chair
Xcode puts the agent next to the code. The conversation is a code editor tab, you split it beside the file you're working on, and you watch it work. Apple's own framing is that you drive and the agent helps you get there faster. That's pairing, and for a lot of work it's exactly right.
FlowDeck assumes you've stopped coding by hand. You hand out multiple tasks to agents, go review the result, answer a question from the second agent and come back to the third when it says it's done. The interface is built around that: projects on a rail, sessions under each project, chats as tabs inside each session. Active Sessions lists everything running across every project.
If your day is one feature in one file with the canvas open, Xcode is built for it. If your day is four branches in flight and a review queue, that's the day FlowDeck is built for.
A quick test
I gave Claude Opus the same prompt in both.
"Create an app app that allows me to view the weather at my current location. Include forecast for the day and the next 7 days"
Xcode went straight to work, and two minutes later it had created three files, added the location permission text to Info.plist and built the project. No question, no plan, no tests. It told me the build succeeded.
Xcode has /plan, and the composer tells you so. And to be fair, I could've used it, but that's another decision I don't want to make.
FlowDeck, on the other hand, started by presenting me with a plan. It laid out what it was going to build, asked me to edit it before anything got written, then executed it in phases. It took a lot longer.
It started by writing the tests and confirmed all fourteen failed. Then it wrote the code until they passed, 14 of 14: loading weather, location denied, location unavailable, network failure, retrying after a failure, and parsing Open-Meteo's response, server errors included.
Then it ran the app in the simulator, and it hung on the loading state, exactly as it had in Xcode. The difference is that FlowDeck didn't stop there. It added temporary logging to see which Core Location callbacks fired, found the permission prompt had been there all along and just wasn't showing in its capture, removed the logging and relaunched a clean build.
A few seconds later, I had the weather on the sim. I didn't click once.
With FlowDeck, the code came back split the way you'd split it yourself: Models, Services, ViewModels and Views. MVVM all the way through. Test Explorer showed 14 of 14 tests green. This looked like a project I'd keep building on.
Then it handed me the evidence. A screenshot of the running app. The test results. What it changed from the plan: a small error type so the app can tell "permission denied" from "location unavailable". And what it didn't check by hand: the error screen with its Retry button, covered only by unit tests.
Xcode just gave me three Swift files in one flat folder: MyApp, ContentView and Weather.swift. No tests, no validation.
Two minutes seconds is fast, but a spinner that never stops is the saddest possible outcome.
What Apple gets right
It took Apple a while, but the agent lives in Xcode now. The transcript sits on one side, the artifacts on the other: files, diffs and rendered previews you review before any of it lands. You can queue messages while the agent works instead of waiting for it to finish.
The agents can also check their own work with Apple's own instruments. They can build, read the errors, run tests, render previews and drive the simulator through Device Hub. You have to ask explicitly, though.
Then there's the stuff only Apple can do. Translations run through the String Catalog with per-string context, fanned out to sub-agents. Organizer hands crash and performance data to the agent and asks it for recommendations. No outside tool sees that context today.
Xcode 27.2 is mostly polish, but three pieces matter for agents. A GetCodeCoverage MCP tool lets an agent see which lines your tests miss. RenderPreview can now target a specific device. And the new JSON project format means agents edit project files without guessing pbxproj IDs. That last one helps every agent touching an Xcode project, including the ones running in FlowDeck.
If your day is one feature at a time, one branch and the editor open, it's hard to argue with free.
Parallel work
Xcode lets you run several conversations at once, and the sidebar tells you what each one is doing. They write to the project you have open, but they don't share context and don't coordinate their edits. Two of them on the same file means conflicting changes.
The advice is to split work along file boundaries, but features don't respect file boundaries. A model change touches the view, the view model and the tests. So you end up scheduling agents in your head, deciding who's allowed to touch what. You're the merge tool now.
In FlowDeck, a session is a Git worktree on its own branch, with its own chats, its own build state and its own destination. Start four agents and each one builds and tests without touching anyone else's files or DerivedData. Start a session from main, from any local or remote branch, or move a chat that grew too big into its own session, uncommitted changes included.
Inside a session you can still run more than one chat. Background tabs keep working, each with its own draft, model and permission mode. When you're done, deleting a session removes the worktree and the local branch. It never touches the remote.
FlowDeck gets built this way. We ship 60 PRs per person every two weeks.
Skills
Both tools ship skills. The difference is who manages them.
Xcode ships Apple's own agent skills, written for this year's APIs, and loads them when a task matches. Plug-ins let you add your own skills next to them, and Xcode reads the same AGENTS.md file external agents do. Apple also lets you export its skills, so nothing stops you from using them in other agents too.
FlowDeck treats skills as something you manage, not something you hope is there. Skills Manager is one window that lists every agent on your Mac (Claude Code, Codex, OpenCode, Cursor and Grok Build) and the skills each one reads. FlowDeck's Apple Development Skills and its CLI skill come installed for every agent you connect, with a switch to turn them off and a button to update them.
You can add your own skills and decide which agent uses what from the comfort of the UI. The day you switch an agent or try a new model, your standards come with it.
Standards and validation
Xcode's agents build with Xcode's own build tool and get the errors directly. That's good, but as we saw in the experiment, they don't really validate the work. You get an app that builds, and that's it.
FlowDeck, on the other hand, builds, runs and tests on its own. Since it uses the FlowDeck CLI instead of xcodebuild, failures come back as typed diagnostics with file and line. Agents write and use actual tests to validate their changes, and willingly launch your app and test the flows by hand.
Every agent in FlowDeck will give you screenshots and proof of the work when it's done, and you can define the level of proof required, from running tests to screenshots and video recordings of your app running.
FlowDeck also includes a set of coding standards, which guide it to make solid architectural decisions and avoid all the pitfalls of Apple development. These standards are enabled by default and cover everything from SwiftUI to optionals to concurrency.
Simulators
Xcode's agents drive the simulator through Device Hub. They can tap, swipe and type, read the accessibility tree and take screenshots to work out what's on screen. Device Hub covers physical devices too, and 27.2 fixed a long list of input bugs there, including iOS 17 simulators. Solid.
FlowDeck puts a live simulator inside the window. Click, swipe, type, rotate, record, set a location, flip accessibility settings or the language, drop photos onto it. No Simulator.app.
The bigger difference is ownership. Every new session can create a dedicated simulator and keep it. That matters once more than one agent is testing. A shared device carries state: an installed build, granted permissions, data from the last agent's run.
Plans, agents and models
Xcode's /plan is good. The agent gathers context, can send sub-agents to explore and hands you a Markdown plan to edit before it writes anything. With ACP, almost any agent can plug in, and you pick the agent and model when you start the conversation. There's no effort setting for Claude.
When it comes to agents, you're stuck with one agent per conversation in Xcode. The only way to switch providers is to start a new conversation and copy/paste the entire chat contents.
FlowDeck splits planning from building on purpose. A Plan tab runs a read-only planning agent with its own model and effort. It asks clarifying questions and puts the plan in its own panel, TL;DR on top. When it's right, Execute sends it to a new chat, an open chat or a brand new session in its own worktree, with a different model if you want. Every plan lands in a Plan Library shared by all the sessions in the project.
Then there's swapping models while you work. Agent, model, effort and permissions live in the composer of every chat, and you change them mid-conversation. Start a hard refactor on the expensive model at high effort, drop to a cheaper one for the mechanical part, go back up when it gets weird. Same chat, same context.
Switch to a different provider and Agent Handoff kicks in. FlowDeck writes a snapshot of the chat, a summary plus the transcript, and the new agent starts from it instead of from zero. It can read further back through FlowDeck's handoff tool when it needs to. Claude Code hits its limit halfway through a feature, you hand the chat to Codex and keep going.
You can also bring your history with you. FlowDeck imports existing chats from all five providers.
After the pull request
The agent says it's done. Twenty minutes later CI fails, or main moved and now there's a conflict. You're back to reading logs, pasting errors into a chat and pushing another fix. Apple's answer to CI is Xcode Cloud, and it's good at running your builds.
In FlowDeck, PR Autopilot watches every open PR that belongs to a session, about once a minute. When a check fails or a conflict shows up, it sends the failure to the agent that wrote the code, with that session's context. Turn on auto-merge and a green PR merges itself: squash, merge commit or rebase.
Shipping
Xcode owns this. Xcode Cloud builds on ephemeral machines, distributes to TestFlight and runs on every commit to the branches you choose. Organizer brings the crash and performance data back, and now hands it to an agent too.
FlowDeck doesn't ship builds for you yet. Most engineers already have a release process: their signing setup, their CI, their review checklist. Signing stays where you and your team already manage it.
Price
Xcode is free. You pay your agent provider either way.
FlowDeck Studio is $79 a year, with the CLI included, on top of the agent subscription you already have. No credits, no per-message limits. If you stop using it, you have Xcode projects and Git branches. Nothing to migrate.
Which one
Use Xcode's agents if you work one task at a time, want the agent right next to your code, and lean on previews, translations, Instruments or Organizer. Nothing else gets that close to Apple's toolchain, and it costs nothing.
Use FlowDeck if you run more than one agent, want each one isolated on its own branch and simulator, swap models and providers as the work changes, and want someone watching the PR after the agent says it's done.
Or both. Open a FlowDeck session in Xcode when you need the canvas, close it when you're done.
Q&A
Is FlowDeck an alternative to Xcode's coding agents?
Can Xcode's agents run in parallel?
Can I change models in the middle of a task?
Can I use my own skills?
Can I use Claude in both?
Does FlowDeck work with my existing Xcode project?
What happens to my project if I stop using FlowDeck?
Further reading

Daniel Bernal
Daniel is a senior Apple engineer with 15+ years shipping on Apple platforms and the creator of Flowdeck. Previously led 100+ engineer teams at Globant and Endava, and has worked with companies like DuckDuckGo, Automattic, and mymind.
#ai-agents
#claude-code
#codex
#comparison
#ios-development



