Skip to content

Commit b4cf7ea

Browse files
AvdLeeAvdLee
authored
Merge pull request #1059 from AvdLee/docs/seo-article-batch
Add SEO-focused RocketSim blog articles
2 parents 03c7ab1 + aa8d07c commit b4cf7ea

7 files changed

Lines changed: 394 additions & 9 deletions

File tree

‎docs/src/content/blog/ai-agents-ios-simulator/cli-agent-settings-hero.png‎

78.8 KB
Loading

‎docs/src/content/blog/ai-agents-ios-simulator/index.mdx‎

Lines changed: 110 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,110 @@
1+
---
2+
title: "AI Agents for the iOS Simulator"
3+
pageTitle: "AI Agents for the iOS Simulator: Navigate Apps with RocketSim"
4+
description: "Let AI agents inspect, navigate, and verify iOS Simulator apps with RocketSim's CLI, Agent Skill, screenshots, and semantic interactions."
5+
publishedTime: 2026-06-18T18:50:00.000Z
6+
image: ./cli-agent-settings-hero.png
7+
imageAlt: "RocketSim CLI and Agent settings showing the Agent Skill installed for General Agents and available for Xcode, Cursor, Claude, and Codex."
8+
---
9+
10+
**AI agents for the iOS Simulator** become much more useful once they can see and control the app they are changing. Reading code is powerful, but many iOS bugs only become obvious after navigating the real UI: onboarding steps, login flows, settings screens, purchase states, and accessibility edge cases.
11+
12+
That is where RocketSim comes in. RocketSim gives agents a version-matched CLI and Agent Skill so they can inspect visible elements, tap controls, type text, wait for screen changes, and capture screenshots from the running Simulator. In other words: the agent can close the loop between code changes and app behavior.
13+
14+
## Why agents need the Simulator
15+
16+
Most coding agents are great at editing files and running terminal commands. They can read errors, update code, and rerun tests. However, iOS development often has a visual feedback loop that is hard to replace with unit tests alone.
17+
18+
You might change a SwiftUI view and compile successfully, but the button could be hidden below the fold. You might update a navigation path and only discover that the back button no longer appears after moving through three screens. You might fix an accessibility label and still have the wrong reading order.
19+
20+
I do not want an agent to guess whether those changes worked. I want it to open the app, inspect the current screen, interact with it, and report what happened. That is the difference between "the code compiles" and "the feature works in the Simulator."
21+
22+
## How RocketSim helps agents navigate
23+
24+
[Agentic Development with RocketSim](/docs/features/agentic-development/) is built around a simple idea: RocketSim stays connected to the running Simulator and exposes that state to agents through a compact command line interface.
25+
26+
<figure>
27+
<video
28+
controls
29+
playsinline
30+
poster="/features/posters/agentic-demo.jpg"
31+
class="w-full rounded-2xl"
32+
>
33+
<source src="/features/agentic-demo.mp4" type="video/mp4" />
34+
</video>
35+
<figcaption>
36+
RocketSim lets an AI coding agent inspect and interact with a running iOS
37+
Simulator app.
38+
</figcaption>
39+
</figure>
40+
41+
The agent loop looks like this:
42+
43+
1. Read the visible UI elements
44+
2. Decide which element to interact with
45+
3. Tap, type, swipe, or press a hardware button
46+
4. Wait for the screen to change
47+
5. Read the new state and continue
48+
49+
That might sound basic, but it is the missing piece in many agent workflows. The agent no longer has to rely on screenshots alone or make fragile coordinate guesses. It can use accessibility elements and semantic interactions whenever possible.
50+
51+
## Why RocketSim's CLI performs well
52+
53+
Agent workflows are sensitive to small amounts of friction. Every screen read costs tokens, every oversized response fills context, and every wrong tap can send the agent down a completely different path.
54+
55+
That is why RocketSim's CLI talks to the running Mac app instead of starting from scratch for every command. RocketSim already knows which Simulator is focused, can keep useful state warm, and can return compact `rs/1` output that is designed for agents.
56+
57+
In our internal research, RocketSim's CLI completed the same agent workflows about **19% faster**, avoided wrong taps entirely, and used about **63% fewer estimated tokens** than a popular alternative. Looking at the lower-level protocol output, the `rs/1` agent format produced **2.7x lower estimated token usage**, **9.7x fewer output bytes**, and **4x fewer wrong taps** overall.
58+
59+
Those numbers matter because they show up directly in your day-to-day agent loop. A smaller screen summary gives the model more room to reason about the task, faster commands reduce waiting, and fewer wrong taps mean fewer recovery steps.
60+
61+
## Accessibility elements beat screenshots
62+
63+
Screenshots are useful, but they are expensive context. They require visual interpretation, and they do not always tell an agent which controls are tappable or what a field is called.
64+
65+
Accessibility elements are closer to how a developer thinks about UI. A button has a label. A text field has a value. A tab bar item has a role. When RocketSim returns a compact element summary, the agent can make a more reliable decision with fewer tokens.
66+
67+
This is one of the reasons I like accessibility-driven automation. It rewards you for building accessible apps, and it gives agents a structured way to navigate. If a screen exposes bad accessibility metadata, the agent will struggle in the same area where a VoiceOver user would struggle.
68+
69+
RocketSim can still fall back to screenshots when the accessibility data is not enough. That balance matters. Use structured UI data first, then visual context when needed.
70+
71+
## Use the RocketSim Agent Skill
72+
73+
You can call the [RocketSim CLI](/docs/features/agentic-development/rocketsim-cli) yourself, but agents perform better when they know the right sequence of commands. The [RocketSim Agent Skill](/docs/features/agentic-development/agent-skill) teaches Cursor, Claude, Codex, Xcode, and other coding tools how to use RocketSim safely.
74+
75+
The skill nudges the agent to:
76+
77+
- Read compact `--agent` output before interacting
78+
- Prefer semantic interactions over coordinate taps
79+
- Wait for screen changes instead of racing ahead
80+
- Use screenshots when accessibility data is sparse
81+
- Run `rocketsim doctor` when setup looks broken
82+
83+
That last point is underrated. A lot of automation failures are not caused by the app. They are caused by a missing permission, an unfocused Simulator, or a stale tool path. `rocketsim doctor` gives the agent a first step before it starts guessing.
84+
85+
## A practical agent workflow
86+
87+
Imagine you ask an agent to update an onboarding screen. Without Simulator access, it can edit the SwiftUI view and maybe run a build. With RocketSim, you can ask for the full loop:
88+
89+
```text
90+
Use RocketSim to navigate through the onboarding flow in the Simulator.
91+
Verify that the new primary CTA appears on the final step and take a screenshot.
92+
```
93+
94+
The agent can inspect the first screen, tap through the flow, wait for transitions, and confirm that the final screen contains the expected CTA. If the accessibility snapshot does not expose enough detail, it can capture a screenshot as proof.
95+
96+
I find this especially useful for changes that are not covered by tests yet. You still need proper tests for critical behavior, but an agent-driven Simulator pass gives you quick confidence before you review the UI yourself.
97+
98+
## Where RocketSim fits in your workflow
99+
100+
RocketSim fits after your normal build step. You still use Xcode, `xcodebuild`, or your existing tooling to build and launch the app, then RocketSim gives the agent a reliable way to inspect and interact with the running Simulator.
101+
102+
That separation keeps the workflow simple. Build tools stay responsible for building, while RocketSim focuses on the running app: visible elements, interactions, screenshots, videos, and recovery paths.
103+
104+
It also means you can add RocketSim to the coding agent workflow you already have instead of replacing it. Let the agent use your build command, then let RocketSim handle the Simulator interaction.
105+
106+
## Conclusion
107+
108+
AI agents become much more useful for iOS development when they can navigate the iOS Simulator. RocketSim gives them a practical control layer: compact accessibility summaries, semantic interactions, waits, screenshots, videos, and a version-matched Agent Skill that explains how to use everything together.
109+
110+
If you already use a coding agent for iOS work, install [RocketSim from the Mac App Store](https://apps.apple.com/app/apple-store/id1504940162?pt=117264678&ct=ai-agents-ios-simulator&mt=8), then open **Settings → CLI & Agent** and install the command line tool plus the [RocketSim Agent Skill](/docs/features/agentic-development/agent-skill). You can also read Apple's [accessibility overview](https://developer.apple.com/accessibility/) to understand why structured UI metadata matters for both users and agents. Feel free to reach out on [X/Twitter](https://x.com/twannl) or [open an issue on GitHub](https://github.com/AvdLee/RocketSimApp/issues) if you have ideas for better agent workflows. Thanks!

‎docs/src/content/blog/debug-urlsession-requests-without-proxy/index.mdx‎

Lines changed: 137 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,137 @@
1+
---
2+
title: "Debug URLSession Requests Without a Proxy"
3+
pageTitle: "Debug URLSession Requests Without a Proxy or Certificates"
4+
description: "Debug URLSession requests in the iOS Simulator without proxy setup or certificates. Inspect responses, failures, cURL, and AI-ready exports."
5+
publishedTime: 2026-06-18T18:55:00.000Z
6+
image: ../../docs/docs/features/networking/network-traffic-monitoring/network_monitor_logs.png
7+
imageAlt: "RocketSim Network Monitor showing URLSession requests and app logs next to a running iOS Simulator app."
8+
imageCaption: "RocketSim shows URLSession requests and app logs in one timeline: 1) switch between requests, logs, or both; 2) inspect debug logs next to the request that caused them."
9+
---
10+
11+
import { Image } from "astro:assets";
12+
import networkInsightsOverview from "../../docs/docs/features/networking/network-traffic-monitoring/network-insights-overview.png";
13+
import networkRequestDetail from "../../docs/docs/features/networking/network-traffic-monitoring/network-request-detail.png";
14+
import networkRequestPromptsToolbar from "../../docs/docs/features/networking/network-request-prompts/network-request-prompts-toolbar.png";
15+
16+
**Debugging URLSession requests without a proxy** sounds like a small workflow improvement until you hit a network bug right before shipping. You open the app, reproduce the issue, and realize you did not start your proxy, forgot to trust a certificate, or missed the exact request that failed.
17+
18+
Proxy tools like Charles Proxy and Proxyman are powerful, and I still think they have a place. However, most everyday iOS Simulator debugging is simpler: I want to see which `URLSession` requests fired, what the response looked like, why a call failed, and whether the app made the same request too many times. RocketSim's [Network Monitor](/docs/features/networking/network-traffic-monitoring) focuses on that loop.
19+
20+
The banner above shows why I like this view during development. The first callout highlights the filters for **Network**, **Logs**, or **All**, while the second callout shows debug logs mixed into the same timeline as your requests. Seeing both together makes it much easier to understand what happened before and after a failing API call.
21+
22+
## Why proxy setup slows you down
23+
24+
Proxy debugging often starts with setup instead of debugging. You configure a system proxy, install a certificate, trust it on the Simulator, enable SSL proxying for the right host, and then hope the app is using a networking stack that goes through the path you expect.
25+
26+
That is fine when you need full proxy power. You might want to rewrite responses, inspect traffic from an app you cannot instrument, or test low-level proxy behavior. In those cases, a dedicated proxy tool is the right choice.
27+
28+
However, if you are debugging your own app during normal development, the setup can be too much. The bug happens, you want the request details now, and you do not want to restart the whole flow just because your proxy was not ready.
29+
30+
## Use RocketSim's Network Monitor
31+
32+
RocketSim takes a different route. With [RocketSim Connect](/docs/getting-started/setting-up-rocketsim-connect), your debug build connects to RocketSim locally and sends captured `URLSession` activity over Bonjour. There is no system proxy setup and no custom certificate to trust.
33+
34+
<figure>
35+
<video
36+
controls
37+
playsinline
38+
poster="/features/posters/network-monitoring-demo.jpg"
39+
class="w-full rounded-2xl"
40+
>
41+
<source src="/features/network-monitoring-demo.mp4" type="video/mp4" />
42+
</video>
43+
<figcaption>
44+
RocketSim's Network Monitor shows URLSession requests, responses, logs,
45+
metrics, and cURL exports next to your Simulator workflow.
46+
</figcaption>
47+
</figure>
48+
49+
Once connected, RocketSim shows recent requests directly in the side window and a full Network Monitor when you need more detail. You can inspect headers, request and response bodies, status codes, metrics, and logs in one place.
50+
51+
In my own workflow, that timeline is the part I care about most. A single failed response is useful, but seeing the order around it is often what explains the bug. Did the token refresh run first? Did the app call the endpoint twice? Did a warning log appear before the request failed?
52+
53+
## Inspect responses and failures
54+
55+
A network bug rarely starts with "the backend is down." More often, it is a missing header, an unexpected response body, a stale token, a validation error, or a request that fires at the wrong time.
56+
57+
<figure>
58+
<Image
59+
src={networkRequestDetail}
60+
alt="RocketSim Network Monitor showing URLSession request details with headers, response body, metrics, and cURL export options."
61+
class="w-full rounded-2xl"
62+
/>
63+
<figcaption>
64+
The request detail view gives you headers, response bodies, metrics, and a
65+
cURL export for the selected URLSession request.
66+
</figcaption>
67+
</figure>
68+
69+
RocketSim helps you answer those questions quickly:
70+
71+
- Which URLSession request failed?
72+
- Which status code came back?
73+
- What did the response body contain?
74+
- Which app log appeared around the same time?
75+
- Can I copy the request as cURL and reproduce it?
76+
77+
Copying a request as cURL is especially useful when you need to share a failing call with a teammate or backend engineer. It moves the conversation from "something is wrong" to "this exact request returns this exact response."
78+
79+
If you only need a quick overview, the side window keeps recent traffic visible while you keep using the Simulator. If you need the full detail, the Network Monitor gives you the deeper request view.
80+
81+
## Find duplicate calls
82+
83+
Network debugging is not only about failures. A lot of app performance issues come from repeated or wasteful requests: the same endpoint fires when a view reappears, a list reloads too often, or a detail screen fetches more data than it needs.
84+
85+
[Networking Insights](/docs/features/networking/networking-insights) gives you a historical view of those patterns. You can look for duplicate calls, caching opportunities, slow endpoints, failure spikes, and the most requested URLs across sessions.
86+
87+
<figure>
88+
<Image
89+
src={networkInsightsOverview}
90+
alt="RocketSim Networking Insights overview showing failure spikes, duplicate calls, caching opportunities, slow endpoints, and most requested URLs."
91+
class="w-full rounded-2xl"
92+
/>
93+
<figcaption>
94+
Networking Insights turns captured traffic into patterns you can act on,
95+
like duplicate calls, slow endpoints, and failure spikes.
96+
</figcaption>
97+
</figure>
98+
99+
This is the kind of debugging I like because it turns invisible waste into something concrete. You might feel that a screen is slow, but seeing five duplicate calls in a row makes the fix obvious.
100+
101+
## Export requests to AI
102+
103+
RocketSim can also export network requests as redacted prompts for AI-assisted debugging. Instead of pasting raw request data into Claude or ChatGPT, you can use [AI Network Request Prompts](/docs/features/networking/network-request-prompts) to generate focused summaries.
104+
105+
The built-in prompt types target common problems:
106+
107+
- **Redundant calls & caching** for duplicate requests and missing cache strategy
108+
- **Performance / overfetching** for slow endpoints and oversized payloads
109+
- **Failures & error spikes** for non-2xx responses and likely causes
110+
111+
<figure>
112+
<Image
113+
src={networkRequestPromptsToolbar}
114+
alt="RocketSim Network Monitor toolbar showing Copy export and Copy prompt menus for AI-assisted URLSession debugging."
115+
class="w-full rounded-2xl"
116+
/>
117+
<figcaption>
118+
Copy export and Copy prompt turn a filtered request set into redacted,
119+
AI-ready debugging context.
120+
</figcaption>
121+
</figure>
122+
123+
The redaction is important. Network traffic often contains bearer tokens, user identifiers, or private payloads. RocketSim keeps the export compact and removes sensitive values so you can ask an AI assistant for help without dumping raw traffic into a chat.
124+
125+
## Keep proxy tools for proxy-specific jobs
126+
127+
Proxy tools are still the right choice when you need proxy-specific power: response rewriting, breakpoints, advanced SSL inspection, or traffic from apps you cannot instrument. Tools like [Charles Proxy](https://www.charlesproxy.com/) and [Proxyman](https://proxyman.io/) are excellent for those jobs.
128+
129+
RocketSim is for the everyday debug-build loop. You are working on your own iOS app, running it in the Simulator, and you want request visibility without setup friction. That covers a lot of debugging sessions.
130+
131+
The nice part is that both workflows can exist together. Use RocketSim for the fast loop, then reach for a full proxy when the bug specifically needs proxy behavior.
132+
133+
## Conclusion
134+
135+
Debugging URLSession requests without a proxy is mostly about removing friction. If your debug build can show requests, responses, failures, logs, cURL exports, historical insights, and AI-ready summaries right next to the Simulator, you can catch many issues before they turn into longer debugging sessions.
136+
137+
If you have a network issue to investigate in your own app, install [RocketSim from the Mac App Store](https://apps.apple.com/app/apple-store/id1504940162?pt=117264678&ct=debug-urlsession-requests-without-proxy&mt=8) and follow the [Network Monitor documentation](/docs/features/networking/network-traffic-monitoring). You can also read Apple's [`URLSession` documentation](https://developer.apple.com/documentation/foundation/urlsession) if you want to revisit the API RocketSim observes in debug builds. Feel free to reach out on [X/Twitter](https://x.com/twannl) or [open an issue on GitHub](https://github.com/AvdLee/RocketSimApp/issues) if you have ideas for better network debugging workflows. Thanks!

0 commit comments

Comments
 (0)