Chris Wood
Founder, qckfx
Cursor is one of the most popular AI-powered code editors available. It can write SwiftUI views, refactor data models, wire up navigation, and work through complex Swift compiler errors. For iOS developers, the editing experience is genuinely impressive.
But editing Swift files is only part of building an iOS app. You also need to build the Xcode project, run it in the simulator, and verify that the UI actually works. Out of the box, Cursor can't do any of that. It operates on text files. It has no connection to Xcode, no access to the simulator, and no way to confirm that the code it wrote produces the right result.
The good news is that MCP (Model Context Protocol) tools can bridge this gap. With the right set of MCP servers, Cursor can build your project, interact with the simulator, and verify its own work. This post walks through the setup and the workflow.
Why Cursor Alone Isn't Enough for iOS
Cursor excels at code generation and editing. It understands Swift syntax, can generate SwiftUI views from descriptions, and handles refactoring tasks well. If your entire workflow were editing text files and reading compiler output, Cursor would be sufficient on its own.
iOS development requires more than that. After editing code, you need to build the project through Xcode's build system, install the app on a simulator, and launch it to see the result. When something goes wrong, you need build logs and runtime errors to diagnose the problem. Cursor has no access to any of this by default.
This creates a fragmented workflow. Cursor makes a change, then you switch to Xcode to build, switch to the simulator to check the result, switch back to Cursor to describe what went wrong, and repeat. The agent is doing the editing, but you're doing all the verification. That defeats much of the productivity gain.
MCP tools solve this by giving Cursor access to the build system, the simulator, and a testing framework. With these tools configured, Cursor can build the project, see errors, interact with the running app, and verify that changes work, all without you leaving the editor.
The MCP Tools You Need
Three MCP servers cover the full iOS development workflow in Cursor. Each handles a distinct part of the cycle: building, interacting, and verifying.
XcodeBuildMCP
XcodeBuildMCP by Cameron Cooke connects Cursor to Xcode's build system. It can build projects for the simulator, read build errors and warnings, manage simulators (boot, install, launch), and run tests. When Cursor makes a code change and needs to compile it, XcodeBuildMCP handles that. If the build fails, Cursor gets the errors directly and can fix them without you copying and pasting compiler output.
Install it with npx:
npx @anthropic-ai/xcodebuildmcp@latestios-simulator-mcp
ios-simulator-mcp by Joshua Yoes gives Cursor fine-grained control over the iOS Simulator. It can tap, swipe, and type text. It can take screenshots, record video, and describe accessibility elements on screen. Where XcodeBuildMCP handles the build pipeline, ios-simulator-mcp handles direct interaction with the running app. Together they let Cursor build and then interact with the result.
Install it with npm:
npm install -g ios-simulator-mcpqckfx
qckfx handles the verification step. You record test flows by using your app in the simulator. qckfx captures every tap, scroll, and network response. After recording, Cursor (or any AI agent) can replay those tests at any time. qckfx replays the session deterministically, stubbing network responses with the recorded data, and diffs the screens visually against the baseline. Cursor gets back a pass/fail result with screenshots showing exactly what changed.
This is the piece that closes the loop. XcodeBuildMCP lets Cursor build. ios-simulator-mcp lets Cursor interact. qckfx lets Cursor verify that everything still works after a change.
Install it via Homebrew:
brew install qckfx/tap/qckfxSetting Up Your Project
Cursor stores MCP server configuration in its settings. Open Cursor Settings, navigate to the MCP section, and add your servers there. Each MCP server needs a command and arguments that tell Cursor how to launch it.
For qckfx, the setup is even simpler. Launch qckfx, click the menu bar icon, and select Install MCP Server. Pick Cursor from the list, and the MCP server is configured automatically. This writes the correct configuration alongside any other MCP servers you already have set up.
Once all three servers are configured, you need baseline test flows for qckfx to replay. Open the simulator, launch your app, and use it normally. Navigate through your onboarding flow, tap through the main screens, open settings. qckfx records everything: touch events, network responses, scroll positions, and simulator state. Each recorded session becomes a test that can be replayed later. The recording process takes exactly as long as it takes you to use the app. There's no test code to write and no configuration to set up.
A good starting set of recordings covers the main flows your users go through: onboarding, the primary feature screen, navigation between tabs, and settings. These become your regression test suite. When Cursor makes changes to any of these areas, it can replay the relevant tests and confirm that existing functionality still works.
The Workflow
With all three MCP servers configured, the development workflow becomes a tight loop. You describe what you want in Cursor, and it handles the rest: editing code, building, and verifying.
Say you ask Cursor to add a dark mode toggle to your settings screen. Cursor edits the SwiftUI code to add the toggle, updates the color scheme logic, and builds the project using XcodeBuildMCP. If there are compiler errors, it reads them and fixes the code. If the build succeeds, it installs and launches the app in the simulator.
Then comes verification. Cursor runs your qckfx tests. qckfx replays the recorded settings flow deterministically. It compares each screen against the baseline and returns the result. If the settings screen looks correct with the new toggle and everything else is unchanged, the tests pass. If the toggle accidentally pushed other elements off screen, or if the navigation bar changed color in an unexpected way, qckfx returns a failure with visual diffs showing exactly what's different.
The visual diffs are what make this workflow effective. Cursor doesn't have to interpret a screenshot and guess whether the UI looks right. It gets a definitive comparison: here is the baseline, here is the current state, and here are the pixels that differ. This means Cursor can iterate with confidence. If a test fails, it knows precisely what to fix. If all tests pass, it knows the change didn't break existing functionality.
Tips
Use .cursorrules to give Cursor project context. A .cursorrules file at the root of your project tells Cursor about your architecture, naming conventions, and coding patterns. For iOS projects, include details about your navigation structure, your data layer patterns, and any SwiftUI conventions your team follows. This helps Cursor generate code that fits your codebase rather than generic Swift. The more context Cursor has about your project, the fewer iterations it needs to get things right.
Record test flows for your most important screens. Prioritize onboarding, the main feature screens, and settings. These are the flows that touch the most code and are most likely to break when Cursor makes changes elsewhere. You don't need exhaustive coverage of every edge case. A handful of recordings covering the primary paths gives you a strong regression safety net. You can always add more recordings later as your app evolves.
Let Cursor verify after each change rather than batching. When Cursor makes a series of related changes, have it build and run tests after each one. This keeps the feedback loop tight. If something breaks, Cursor knows exactly which change caused the regression. Batching multiple changes before testing means Cursor has to untangle which edit introduced the problem, which is harder and burns more tokens.
Keep recordings up to date. When you intentionally change a flow (adding a new screen to onboarding, for example), re-record that test. The recording process is fast since you're just using the app normally. Outdated baselines will cause false test failures, which teach Cursor to ignore test results. Fresh baselines keep the verification signal clean.
Conclusion
Cursor is a powerful editor for iOS development, but editing code is only one part of the workflow. By adding XcodeBuildMCP for building, ios-simulator-mcp for simulator interaction, and qckfx for verification, you give Cursor the full development cycle. It can write code, compile it, run the app, and confirm that everything works.
The verification step is what makes this setup reliable. Without it, Cursor can build your app but has no way to know if the result is correct. With qckfx tests, Cursor gets definitive feedback: visual diffs showing exactly what changed, pass/fail results it can act on, and the confidence to iterate without your constant supervision.
qckfx is free and runs locally on your Mac.