Printed on: April 17, 2026
Some time again, I posted on X about how of us handle the context home windows for his or her AI brokers. In response to that put up, the one that constructed FlowDeck reached out and requested if I might give it a strive. My workflow was principally fantastic as-is (construct with Cursor, inform it to test builds with xcodebuild, and go to Xcode to truly construct and run) however a easy CLI that would offer higher output to my agent (much less context air pollution) and a pleasant method to work together with my apps from the CLI sounded attention-grabbing sufficient to offer it a strive.
I put in FlowDeck, built-in it for Maxine‘s Xcode venture, and inside a day or two it grew to become the factor my agent reaches for by default. I have never actually considered it since, which is the perfect factor I can say a couple of developer device. I am not the sort of person who enjoys tweaking their setup endlessly so every time I combine one thing in my workflow, it has to slot in shortly and the device has to work reliably.
This put up is about how FlowDeck has come to suit that requirement, and why I feel it makes a number of sense should you’re utilizing AI brokers to work in your iOS tasks.
You may be taught why, as compared with FlowDeck, utilizing uncooked xcodebuild and Xcode’s built-in MCP may 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 options like XcodeBuildMCP.
If you have not learn my put up on establishing a supply pipeline for agentic iOS tasks, I like to recommend that you just give {that a} learn too. It’s going to enable you achieve a extra full understanding of my growth setup and my means 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 machine was concerned. As soon as it grew to become accessible in Xcode and I arrange its MCP, my brokers would additionally attempt to use Xcode’s personal MCP bridge by way of xcrun mcpbridge every time they thought it was related. Primarily, I let the agent work out what to do, easy methods to do it, and when to do it. This labored principally fantastic for locating compilation errors and working checks, nevertheless it principally by no means actually labored nicely once I needed to run (and debug) my app.
On the core every of these instruments works. Nonetheless, utilizing them may be advanced, and except instructed correctly it is actually arduous for an agent to (effectively) work out what the correct factor to do is. This could shortly replenish your agent’s context which, ultimately, 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, easy methods 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 process, and determining which UDID to focus on is its personal little facet quest. This stuff work, and if an agent is engaged on an extended working process anyway you may not care about effectivity, however the context window fills up quick and it fills up with uninteresting noise.
After I tried the Xcode MCP bridge, I did initially hope that the context window downside can be solved (and in a means, 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 “Enable exterior brokers to make use of Xcode instruments” alert. I am pretty certain this was purported 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 tasks set as much as not use FlowDeck as a result of they’re being labored on by others who do not use FlowDeck but.)
Should you’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 individuals 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 a number of friction for a workflow that is purported 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, simple to make use of, interface. It nonetheless calls Apple’s instruments below the hood, it simply cleans up the components my agent (or I) should 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 hold the context window cleaner which is a extremely good factor.
The second factor is configuration. You save your venture settings as soon as:
flowdeck config set -w Maxine.xcodeproj -s Maxine -S "iPhone 16"
Or, should you’re not precisely certain what it is best to go 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, working, 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.
Working your apps and exploring logs may be finished with a separate command: flowdeck run --log. This command launches the app and streams its output. You possibly can even connect to a working app with flowdeck logs should 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. After I run my app, FlowDeck lists the instructions I can execute (whereas the app is working) to examine logs for instance.
The characteristic I didn’t count on 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 learn these information and see what’s on display. Earlier than this, the agent was guessing at whether or not its change really labored. Now it simply checks. Because of this, with some apply, you can begin establishing your agent and app to validate your UI adjustments and iterate on them as wanted.
That stated, I have never found out easy methods to use this to verify issues look good. It is an amazing performance check, however brokers simply do not understand how UX feels, or when a design appears proper. These are expertise which can be, for my part, 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 practical.
There is a related set of instructions for macOS apps below flowdeck ui mac, however I principally use the iOS facet.
None of that is magic by the best way. It is all constructed on present instructions that will be a ache to chain collectively by hand. FlowDeck simply makes it simple.
Organising FlowDeck as your agent’s go-to device
As soon as FlowDeck is put in and you’ve got activated your license / trial, you are in a position to set up the agent ability that comes with FlowDeck. I take advantage of Cursor, so I can add the ability to my venture utilizing a command just like the one beneath:
flowdeck ai install-skill --agent cursor --mode venture
This drops a ability file into .cursor/expertise/flowdeck/ that teaches my agent the FlowDeck instructions and the order to run them in. By itself, that is already sufficient to make Cursor favor FlowDeck for something Xcode-related.
However I went one step additional, and that is the place it connects again to my supply pipeline put up. In that put up I talked about brokers.md being a dwelling doc that you just replace every time your agent does one thing you do not like. That is precisely the sort 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, machine, and log duties
- Don't name `xcodebuild`, `xcrun simctl`, or `xcrun devicectl` immediately
- Begin with `flowdeck config get --json` to test the saved venture config
- Use `flowdeck run --log` when it's essential see runtime output
These 4 strains, mixed with the ability pack, make it in order that my agent reaches for FlowDeck routinely every time I ask it to construct, check, or run one thing. Which, in actual fact, is earlier than the agent is even allowed to ask me to evaluate code; I do not need to evaluate code solely to understand later that it would not construct or that checks fail. I by no means say “use FlowDeck” in my prompts. The ability mixed with my brokers file makes certain that brokers use FlowDeck over xcodebuild.
That is what I imply once I say I ended eager about it. Setting it up took perhaps 10 minutes, and I’ve barely considered it since as a result of it is simply the default choice now.
As wanted, you possibly can arrange extra particular configurations like telling FlowDeck to run in a particular CI mode, or pointing it at a particular Derived Information path (which may be helpful in parallel multi-agent workflows).
The way it compares to XcodeBuildMCP
Whereas studying this, you could be pondering “this sounds similar to XcodeBuildMCP“. XcodeBuildMCP is a product that is at present owned and maintained by Sentry (after being acquired), it is open supply, and it covers a number of floor. Simulator, machine, macOS, SwiftPM, UI automation, even LLDB-based debugging. If you would like an MCP-native free choice, that is the one I might choose.
The place it differs from FlowDeck is not actually the characteristic checklist, they remedy the identical issues in a number of instances. The distinction is that XcodeBuildMCP is an MCP server. Which means one other course of working alongside your editor, device schemas that your agent has to barter with, and response measurement limits to work round. There are professionals and cons for MCPs versus ability information that I will not go into on this put up. If MCP is a paradigm that you just like, then XcodeBuildMCP could be a more sensible choice for you. If a CLI with ability information is your most popular system, then FlowDeck makes extra sense for you.
There’s one attention-grabbing 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 have to 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 if you’re exploring options.
Each instruments work. Decide what suits your setup. FlowDeck simply suits mine higher.
Abstract
On this put up, you discovered about FlowDeck and the way it’s modified the best way I run my builds exterior of Xcode with no need to have Xcode open in any respect. I defined that FlowDeck helps me save helpful context window house 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 immediately work together with the simulator by way of the accessibility tree that the simulator exposes. That is extremely helpful as a method to let AI brokers check their code, and to validate that issues are practical. It isn’t a device that magically offers your agent eyes and a way of style, however that does not make it any much less helpful.
Should you’ve been constructing out an agentic iOS workflow, FlowDeck is a device that I extremely suggest you take a look at. If nothing else, it helps your brokers course of construct output whereas saving helpful tokens with out breaking or needing tons of tinkering to arrange.
