Skip to content
Development
Skill

/run-simulator

Build, install, launch, and screenshot an iOS app in the Simulator to verify a change visually. Use when the user wants to run the app, see a change live, screenshot the running app, or confirm a UI fix actually works (not just that it compiles).

From plugin
rshankras-apple-skills
848181 skills

Claude Code

$ npx -y skills add rshankras/claude-code-apple-skills --skill run-simulator --agent claude-code

SKILL.md

run-simulator.SKILL.md
name: run-simulator
description: Build, install, launch, and screenshot an iOS app in the Simulator to verify a change visually. Use when the user wants to run the app, see a change live, screenshot the running app, or confirm a UI fix actually works (not just that it compiles).
allowed-tools: [Bash, Read, Glob]
last_verified: 2026-11-04
review_by: 2027-06-22

Run in Simulator

Launches the **actual app** in the iOS Simulator and drives it far enough to see what a user would see. Building proves the code compiles; this skill proves it *runs*. The payoff is a screenshot of the live app that you read back to confirm the change — a blank or crashed frame is a failure, not a pass.

> **The rule:** navigate with the accessibility tree; screenshots verify > outcomes, never locate tap targets. Text is cheap and exact; every image you > Read stays in context for the rest of the session.

This skill is generic. Nothing about a specific app is hardcoded — the scheme, simulator, product path, and bundle id are all discovered at runtime.

When This Skill Activates

Use this skill when the user:

  • Asks to "run", "launch", or "open" the app in the simulator
  • Wants to *see* a change working, not just compile it
  • Asks for a screenshot of the running app
  • Wants to verify a UI fix visually before committing or pushing
  • Says "does this actually work?" about a view/flow they just changed

Do **not** use it for unit/UI test runs (`xcodebuild test`) — that's a different goal. This is about meeting the app as a user would.

Process

Run the steps in order. Each step's output feeds the next, so don't hardcode values a previous step can discover.

1. Discover the project and scheme

Prefer a workspace over a bare project when both exist (CocoaPods/SPM setups often require the workspace):

# Find the container
ls *.xcworkspace 2>/dev/null || ls *.xcodeproj 2>/dev/null

# List schemes (use -workspace X.xcworkspace OR -project X.xcodeproj)
xcodebuild -list -project <App>.xcodeproj 2>/dev/null

Pick the app scheme (usually matches the app name). If several schemes look plausible and none clearly matches, **ask the user** which to run rather than guessing.

2. Pick a simulator destination

**Never hardcode a device name** — the named device may not exist on this Mac (e.g. assuming "iPhone 16" when only "iPhone 17 Pro" is installed fails with *"Unable to find a device matching the provided destination specifier"*). List what's actually available and prefer one already booted:

# Already-booted sim, if any (fastest — skip the boot wait)
xcrun simctl list devices booted

# Otherwise, available iPhones to choose from
xcrun simctl list devices available | grep -i iphone

Choose a booted device if present; otherwise pick a recent iPhone from the available list and remember its name for the destination string.

3. Build for the simulator

xcodebuild build \
  -project <App>.xcodeproj \
  -scheme <Scheme> \
  -destination 'platform=iOS Simulator,name=<SimName>' \
  2>&1 | tail -5
  • Read the tail for `** BUILD SUCCEEDED **`. Note that `-quiet` *suppresses*

that success line, so either drop `-quiet` for the confirming run or grep for `error:` explicitly.

  • On failure, surface the `error:` lines — don't proceed to install a stale or

nonexistent build.

4. Resolve the built `.app` and its bundle id

Don't guess the DerivedData path — ask the build system for it:

# Product directory + name from the resolved build settings
eval $(xcodebuild -project <App>.xcodeproj -scheme <Scheme> \
  -destination 'platform=iOS Simulator,name=<SimName>' \
  -showBuildSettings 2>/dev/null \
  | awk -F' = ' '/ TARGET_BUILD_DIR =/{print "DIR=\""$2"\""} / FULL_PRODUCT_NAME =/{print "NAME=\""$2"\""}')
APP="$DIR/$NAME"
echo "APP: $APP"

# Bundle id straight from the built Info.plist
BID=$(/usr/libexec/PlistBuddy -c "Print :CFBundleIdentifier" "$APP/Info.plist")
echo "Bundle id: $BID"

5. Boot, install, launch

SIM="<SimName>"
xcrun simctl boot "$SIM" 2>/dev/null   # no-op if already booted
open -a Simulator                      # bring the window forward
xcrun simctl bootstatus "$SIM" -b      # block until fully booted

xcrun simctl install "$SIM" "$APP"
xcrun simctl launch "$SIM" "$BID"

`simctl launch` prints `<bundleid>: <pid>` on success. A non-zero exit or an error string here means the app failed to start — investigate before screenshotting.

6. Navigate to the screen (if the change is behind navigation)

`xcrun simctl` **cannot tap** — `simctl io` has no tap operation (only `enumerate`, `poll`, `recordVideo`, `screenshot`). Navigation needs a tool that reads the accessibility tree. Pick the first that works:

**a. Deep link** — if the app has a URL route to the screen, it's the cheapest path: `xcrun simctl openurl "$SIM" "<scheme>://<path>"`.

**b. AXe** (`command -v axe`; install: `brew install cameroncooke/axe/axe`). AXe needs the simulator's UDID:

UDID=$(xcrun simctl list devices booted -j \
  | jq -r --arg n "$SIM" '.devices[][] | select(.name==$n or .udid==$n) | .udid' | head -1)

# Compact element list: type, label, id, centre point. ~2 KB per screen.
# NEVER Read raw `axe describe-ui` output — it is ~280 KB (≈70k tokens) for
# one screen, far more than a screenshot.
UI_FILTER='[.. | objects | select(has("type") and (.AXLabel // .AXUniqueId // "") != ""
  and .type != "Application" and .type != "Group")
  | {t: .type, l: .AXLabel, id: .AXUniqueId, v: .AXValue,
     xy: [(.frame.x + .frame.width/2 | floor), (.frame.y + .frame.height/2 | floor)]}
  | with_entries(select(.value != null))]'
axe describe-ui --udid "$UDID" | jq -c "$UI_FILTER" | jq -c '.[]'

Tap the target, most specific first:

axe tap --id "<AXUniqueId>" --udid "$UDID"                              # 1. accessibilityIdentifier
axe tap --label "<AXLabel>" --element-type Button --wait-timeout 5 --udid "$UDID"  # 2. label (+ type)
axe tap -x <x> -y <
Read more
@rshankras
Ships withrshankras-apple-skills

A collection of Claude Code skills for iOS, macOS, watchOS, visionOS, and Apple platform development. These skills help you plan and build apps, maintain code quality, ensure HIG compliance, and guide you from idea to App Store.

Stars on GitHub

Momentum

stars in total
848
Star history of rshankras/claude-code-apple-skills on GitHub, a chart by star-history.com

Other skills on rshankras-apple-skills.

More skills from other plugins.

brainstorming
Auto-invoked

brainstorming

You MUST use this before any creative work - creating features, building components, adding functionality, modifying behavior, or…

@obra@obraInstall Skill
ask-matt

ask-matt

Ask which skill or flow fits your situation. A router over the skills in this repo.

skills10d309k
@mattpocock@mattpocockInstall Skill
accessibility
Auto-invoked

accessibility

Design, implement, and audit accessible UI to WCAG 2.2 Level AA across Web, iOS, and Android — semantic ARIA roles and labels,…

ecc12d293k
@affaan-m@affaan-mInstall Skill
compiler-commit

compiler-commit

Use when you want to verify compiler changes and commit with the correct convention. Runs tests, lint, and format, then commits…

react1d252k
@facebook@facebookInstall Skill

Questions about run-simulator.

Which coding agents can use run-simulator?
run-simulator installs in Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot, OpenCode and Windsurf with the skills CLI, using each agent's flag shown on this page. Flowy's auto-invocation, which fires a skill when your prompt matches, runs in Claude Code only.