app-store
App Store optimization and marketing skills for descriptions, screenshots, keywords, review responses, and comprehensive…
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).
Claude Code
$ npx -y skills add rshankras/claude-code-apple-skills --skill run-simulator --agent claude-code
Codex
$ npx skills add rshankras/claude-code-apple-skills --skill run-simulator -a codex -y
Cursor
$ npx skills add rshankras/claude-code-apple-skills --skill run-simulator -a cursor -y
Gemini CLI
$ npx skills add rshankras/claude-code-apple-skills --skill run-simulator -a gemini-cli -y
GitHub Copilot
$ npx skills add rshankras/claude-code-apple-skills --skill run-simulator -a github-copilot -y
OpenCode
$ npx skills add rshankras/claude-code-apple-skills --skill run-simulator -a opencode -y
Windsurf
$ npx skills add rshankras/claude-code-apple-skills --skill run-simulator -a windsurf -y
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
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.
Use this skill when the user:
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.
Run the steps in order. Each step's output feeds the next, so don't hardcode values a previous step can discover.
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.
**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.
xcodebuild build \ -project <App>.xcodeproj \ -scheme <Scheme> \ -destination 'platform=iOS Simulator,name=<SimName>' \ 2>&1 | tail -5
that success line, so either drop `-quiet` for the confirming run or grep for `error:` explicitly.
nonexistent build.
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"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.
`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 <
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.
App Store optimization and marketing skills for descriptions, screenshots, keywords, review responses, and comprehensive…
Privacy-preserving ad measurement with AdAttributionKit (SKAdNetwork's successor) — install and re-engagement attribution,…
Generate compelling App Store descriptions that convert browsers into users. Use when writing initial descriptions, improving…
Apple Search Ads campaign strategy for indie developers — paid acquisition, keyword bidding, budget planning, and ROAS…
Take a one-time in-app purchase from MISSING_METADATA to READY_TO_SUBMIT in App Store Connect — set its price schedule and…
Optimize app title, subtitle, and keywords for maximum App Store discoverability. Use when launching a new app, improving search…
You MUST use this before any creative work - creating features, building components, adding functionality, modifying behavior, or…
Ask which skill or flow fits your situation. A router over the skills in this repo.