Revealed on: April 17, 2026
Some time again, I posted on X about how people handle the context home windows for his or her AI brokers. In response to that submit, the one who constructed FlowDeck reached out and requested if I might give it a strive. My workflow was largely positive as-is (construct with Cursor, inform it to examine builds with xcodebuild, and go to Xcode to really construct and run) however a easy CLI that would offer higher output to my agent (much less context air pollution) and a pleasant approach to work together with my apps from the CLI sounded fascinating sufficient to provide it a strive.
I put in FlowDeck, built-in it for Maxine‘s Xcode mission, and inside a day or two it grew to become the factor my agent reaches for by default. I have not actually considered it since, which is the most effective factor I can say a few developer software. I am not the type of person who enjoys tweaking their setup endlessly so at any time when I combine one thing in my workflow, it has to slot in shortly and the software has to work reliably.
This submit is about how FlowDeck has come to suit that requirement, and why I feel it makes loads of sense in case you’re utilizing AI brokers to work in your iOS initiatives.
You may be taught why, compared with FlowDeck, utilizing uncooked xcodebuild and Xcode’s built-in MCP could be painful within the first place. We’ll go over what FlowDeck adjustments, how I set it up (together with the rule I added to my brokers.md), and the way it compares to alternate options like XcodeBuildMCP.
If you have not learn my submit on establishing a supply pipeline for agentic iOS initiatives, I like to recommend that you simply give {that a} learn too. It’s going to aid you acquire a extra full understanding of my improvement setup and my manner of working.
Understanding how xcodebuild can fall brief
With out FlowDeck, my brokers would run the xcodebuild command for builds and checks, xcrun simctl for something simulator-related, and xcrun devicectl when an actual system was concerned. As soon as it grew to become obtainable in Xcode and I arrange its MCP, my brokers would additionally attempt to use Xcode’s personal MCP bridge by way of xcrun mcpbridge at any time when they thought it was related. Primarily, I let the agent work out what to do, the right way to do it, and when to do it. This labored largely positive for locating compilation errors and operating checks, nevertheless it mainly by no means actually labored properly once I wished to run (and debug) my app.
On the core every of these instruments works. Nonetheless, utilizing them could be complicated, and until instructed correctly it is actually arduous for an agent to (effectively) work out what the precise factor to do is. This may shortly replenish your agent’s context which, in the long run, ends in an agent that burns its IQ factors quicker than it burns tokens.
Even when the agent would know precisely which instruments to name, the right way to name them, and get it proper each single time, xcodebuild output is big and unstructured. A failed construct dumps a whole lot of strains of compiler noise, and the agent has to determine what’s related. xcrun simctl has a distinct command form for each activity, and determining which UDID to focus on is its personal little facet quest. These items work, and if an agent is engaged on an extended operating activity anyway you may not care about effectivity, however the context window fills up quick and it fills up with uninteresting noise.
Once I tried the Xcode MCP bridge, I did initially hope that the context window drawback could be solved (and in a manner, it appears to be) however utilizing it may be irritating. It requires Xcode to be open, and each time a brand new agent course of connects, macOS throws up an “Permit exterior brokers to make use of Xcode instruments” alert. I am pretty certain this was alleged to be a factor of the previous in Xcode 26.4 however I am nonetheless approving connections day-after-day once I use the MCP. (I’ve some initiatives set as much as not use FlowDeck as a result of they’re being labored on by others who do not use FlowDeck but.)
For those who’ve ever used Codex with Xcode’s MCP, you may know what I imply. There is a lengthy thread on the Codex repo the place folks describe being re-prompted again and again because the app spawns new MCP subprocesses. Apple’s personal documentation on exterior brokers explains why this occurs, however explaining it would not make the dialogs any much less annoying.
None of that is damaged, precisely. It is simply loads of friction for a workflow that is alleged to be hands-off.
Exploring what FlowDeck does in another way
FlowDeck is a single CLI that wraps xcodebuild, simctl, devicectl, and the opposite instruments behind one constant, straightforward to make use of, interface. It nonetheless calls Apple’s instruments beneath the hood, it simply cleans up the components my agent (or I) need to work together with.
The very first thing that issues is output. When the agent runs flowdeck construct --json, it will get structured occasions as an alternative of a wall of textual content. A construct failure reveals up as a single error object with the file, line, column, and message. An agent can parse that and go repair it, as an alternative of grepping by way of a log that may get truncated midway by way of. This helps preserve the context window cleaner which is a extremely good factor.
The second factor is configuration. You save your mission settings as soon as:
flowdeck config set -w Maxine.xcodeproj -s Maxine -S "iPhone 16"Or, in case you’re not precisely certain what you must move to flowdeck config, simply use flowdeck -i and it will stroll you thru a few questions that construct your config. After that, it presents you with hotkeys for constructing, operating, testing, and extra.
After that, the agent simply runs flowdeck construct, flowdeck run, or flowdeck check. No flags, no vacation spot strings, no guessing which scheme to make use of; these will all be learn out of your config.
Operating your apps and exploring logs could be finished with a separate command: flowdeck run --log. This command launches the app and streams its output. You’ll be able to even connect to a operating app with flowdeck logs in case you did not begin it with --log within the first place. It captures each print() and OSLog output with none xcrun simctl spawn instructions.
My favourite factor is that I do not even have to recollect these instructions once I manually work together with FlowDeck. Once I run my app, FlowDeck lists the instructions I can execute (whereas the app is operating) to examine logs for instance.
The characteristic I didn’t anticipate to care about however completely do is flowdeck ui simulator session begin. It shops a screenshot and an accessibility tree on disk each 500 milliseconds. When my agent is testing a UI change, it might probably learn these information and see what’s on display. Earlier than this, the agent was guessing at whether or not its change truly labored. Now it simply checks. Because of this, with some observe, you can begin establishing your agent and app to validate your UI adjustments and iterate on them as wanted.
That stated, I have not discovered the right way to use this to ensure issues look good. It is an ideal performance check, however brokers simply do not know the way an excellent UX feels, or when a design seems proper. These are abilities which are, in my view, nonetheless very human, so I am not anticipating an agent to get issues 100% proper on the primary strive. I typically tweak UI and UX by hand after the agent has made issues purposeful.
There is a comparable set of instructions for macOS apps beneath flowdeck ui mac, however I largely use the iOS facet.
None of that is magic by the best way. It is all constructed on present instructions that might be a ache to chain collectively by hand. FlowDeck simply makes it straightforward.
Establishing FlowDeck as your agent’s go-to software
As soon as FlowDeck is put in and you’ve got activated your license / trial, you are capable of set up the agent talent that comes with FlowDeck. I take advantage of Cursor, so I can add the talent to my mission utilizing a command just like the one under:
flowdeck ai install-skill --agent cursor --mode missionThis drops a talent file into .cursor/abilities/flowdeck/ that teaches my agent the FlowDeck instructions and the order to run them in. By itself, that is already sufficient to make Cursor choose FlowDeck for something Xcode-related.
However I went one step additional, and that is the place it connects again to my supply pipeline submit. In that submit I talked about brokers.md being a residing doc that you simply replace at any time when your agent does one thing you do not like. That is precisely the type of factor that belongs in it.
I added a brief rule to my brokers.md that appears roughly like this:
## Apple platform tooling
- Use FlowDeck for all construct, run, check, simulator, system, and log duties
- Don't name `xcodebuild`, `xcrun simctl`, or `xcrun devicectl` straight
- Begin with `flowdeck config get --json` to examine the saved mission config
- Use `flowdeck run --log` when you might want to see runtime outputThese 4 strains, mixed with the talent pack, make it in order that my agent reaches for FlowDeck mechanically at any time when I ask it to construct, check, or run one thing. Which, in reality, is earlier than the agent is even allowed to ask me to overview code; I do not need to overview code solely to appreciate later that it would not construct or that checks fail. I by no means say “use FlowDeck” in my prompts. The talent mixed with my brokers file makes certain that brokers use FlowDeck over xcodebuild.
That is what I imply once I say I ended excited about it. Setting it up took possibly 10 minutes, and I’ve barely considered it since as a result of it is simply the default possibility now.
As wanted, you’ll be able to arrange extra particular configurations like telling FlowDeck to run in a particular CI mode, or pointing it at a particular Derived Knowledge path (which could be helpful in parallel multi-agent workflows).
The way it compares to XcodeBuildMCP
Whereas studying this, you may be considering “this sounds similar to XcodeBuildMCP“. XcodeBuildMCP is a product that is presently owned and maintained by Sentry (after being acquired), it is open supply, and it covers loads of floor. Simulator, system, macOS, SwiftPM, UI automation, even LLDB-based debugging. If you need an MCP-native free possibility, that is the one I might decide.
The place it differs from FlowDeck is not actually the characteristic record, they remedy the identical issues in a number of circumstances. The distinction is that XcodeBuildMCP is an MCP server. Which means one other course of operating alongside your editor, software schemas that your agent has to barter with, and response dimension limits to work round. There are professionals and cons for MCPs versus talent information that I will not go into on this submit. If MCP is a paradigm that you simply like, then XcodeBuildMCP may be a more sensible choice for you. If a CLI with talent information is your most popular system, then FlowDeck makes extra sense for you.
There’s one fascinating profit I’ve discovered with FlowDeck being a CLI although. I can run the identical instructions my agent runs. This is not one thing I must do typically, however the truth that there is a CLI I can work together with implies that I can check and take a look at workflows with out involving an agent which is sort of helpful, particularly once you’re exploring options.
Each instruments work. Choose what suits your setup. FlowDeck simply suits mine higher.
Abstract
On this submit, you discovered about FlowDeck and the way it’s modified the best way I run my builds outdoors of Xcode without having to have Xcode open in any respect. I defined that FlowDeck helps me save useful context window area by offering parsed, structured responses to my agent’s instructions which makes processing construct output extra environment friendly, and fewer token-heavy.
You additionally discovered that FlowDeck can straight work together with the simulator by way of the accessibility tree that the simulator exposes. That is extremely helpful as a approach to let AI brokers check their code, and to validate that issues are purposeful. It isn’t a software that magically offers your agent eyes and a way of style, however that does not make it any much less helpful.
For those who’ve been constructing out an agentic iOS workflow, FlowDeck is a software that I extremely suggest you try. If nothing else, it helps your brokers course of construct output whereas saving useful tokens with out breaking or needing tons of tinkering to arrange.
