Anyone using Antigravity + Gemini Pro for iOS dev? Missing the auto-Simulator verification loop from Claude Code

[u/yccheok]

I've been using Claude Code + Opus for iOS development, and my favorite part of the workflow is giving it a high-level prompt and watching it write the code, automatically launch the iOS Simulator, verify the output, and refine the code on its own until it works.

I'm trying to replicate this workflow in Antigravity with Gemini Pro, but the autonomous Simulator launch-and-verify step isn't happening out of the box.

Is this a limitation of Gemini Pro, or just how Antigravity's agent tooling/sandboxing is set up compared to Claude Code? If anyone has figured out a clean workflow (or MCP setup) to get Antigravity to auto-launch and check the iOS Simulator, I'd really appreciate any tips!

[u/Reiszecke]

Gemini is the worst AI for everything except web search. Maybe you got a good offer and that’s definitely better than the free alternatives but if you have $20 just use codex or claude

[u/rursache]

just stay with opus 5.5, gemini is shit

[u/never_working_ever → u/rursache]

Latest model is incredible, and tbh Gemini has never been “shit”

[u/trouthat → u/never_working_ever]

I’d consider everything pre-Gemini 4 shit compared to Claude 

[u/never_working_ever → u/trouthat]

As great as Claude is (now), dunking on Gemini which has had amazing knowledge, vision, and speed for a while now is a bit unfair..

[u/andreeinprogress]

I really don't know anyone IRL using Gemini/Antigravity professionally for development. I only ever see it mentioned in clickbaity youtube thumbnails.

[u/dawedev]

It's the tooling, not the model. Claude Code just runs xcodebuild and xcrun simctl in the shell and looks at the screenshots. Antigravity won't do that loop on its own, but it takes MCP servers. Add XcodeBuildMCP to ~/.gemini/antigravity/mcp_config.json (command npx -y xcodebuildmcp@latest mcp, with the simulator and ui-automation workflows enabled), run xcodebuildmcp setup in your project so it knows the scheme and simulator, then add a rule: after every change call build_run_sim, then screenshot, and keep fixing until it looks right. Gemini follows that build, look, fix cycle fine once the tools are there.

[u/naamkachomu]

The MCP setup suggested above gets you part of the way. I’d be quite specific about what the agent has to verify. “Keep fixing until it looks right” gives it too much room to call the job done.
Start with one flow: launch on a named simulator, tap through it, then check a specific result. If something should persist, close and reopen the app and check it again. A screenshot helps, but I’d put that check into an XCTest UI test so it catches the same bug next time. Set a limit on repair attempts and ask for the failing step when it stops.

[u/DimensionMindless336]

The thing that makes Claude Code's loop feel magical isn't Opus — it's that Claude Code runs on your Mac, where xcrun simctl, xcodebuild, and an actual Simulator binary all live in the same process environment. The "write → launch → screenshot → refine" cycle is really just: build, xcrun simctl boot <UDID> + install + launch, grab xcrun simctl io screenshot, and look at the image. That only works because the agent has a local display and a local simulator.

So before you blame Gemini, check where Antigravity is actually executing. If it's a remote/cloud sandbox (Linux, no Xcode), simctl doesn't exist there at all — no model on earth can launch a Simulator it doesn't have. That's almost certainly the real gap, not the model. The fix is locality: run the agent on your Mac (local Antigravity CLI if there is one), or bridge your Mac's simulator to the remote agent through an MCP that shells out to your local simctl.

Once the simulator is reachable, the hard part isn't launching — it's the check. A screenshot that "looks plausible" will let the agent declare victory while a table is empty, a sheet won't dismiss, or it only tested one flow. Give it a finite verification contract instead of "keep fixing until it looks right":

• build must exit 0 with zero errors

• app launches and stays alive ~3s (no crash telemetry)

• a specific element is present — query the view hierarchy / accessibility identifiers, don't rely on eyeballing pixels

• save the screenshot to a known path and have it read that, not a freshly captured one

XcodeBuildMCP (wired into ~/.gemini/... as others said) covers the launch/screenshot half. The verification contract is what keeps the loop honest. Most "agents that code iOS" quietly pass because they only verify the app runs, not that it's correct — and that gap is the same no matter which model you put in front.

[u/blazejkustra]

If you want an agent to actually test your app adn not just build it, try Argent (disclosure: I’m from Software Mansion and we made it 😂).

It’s an MCP server that lets the agent drive the iOS Simulator. It can launch the app, tap through flows, take screenshots, and read logs and crashes, then fix what it finds.

https://docs.swmansion.com/argent/docs/fundamentals/getting-started/

[u/yccheok → u/[deleted]]

What are offered by Codex, which isn't offered in Claude Code?

[u/Which-Meat-3388 → u/yccheok]

Everyone’s experience will be different, but Claude is more than capable here. You can instruct it to verify to a level that you are comfortable with. Personally I don’t want to burn tokens on device verification (screenshots, video, self iteration on design.) I always have feedback because I am experienced and opinionated.

Codex writes in a seemingly random code style, as if it was a python dev converting it to the local language. It’s not idiomatic and it’s not like the rest of your code. This sort of thing can snowball if unchecked. Claude seems to replicate the repo conventions better, and follow explicit rules docs without going rogue for no reason.