agentleFS
simiancraftsimiancraft/simiancraft-skills/skills/ios-simulator/SKILL.md

ios-simulator

Skill8 starsChanged 5 months agoMITView on GitHub

Drive an iOS Simulator headlessly on macOS: discover and boot a device, install and launch an app, drive its UI by accessibility (AXe) rather than brittle coordinates, capture screenshots, and navigate the simulator's own chrome, menus, and execution modes. The iOS analog of android-emulator-harness and playwright-harness. Project-agnostic core; Expo/React-Native specifics live in expo-ios-simulator, and "make the app driveable" lives in mobile-accessibility. Use for any task that is "boot/run an iOS simulator", "drive an iOS screen", "screenshot the simulator", or "automate an iOS flow".

  • Installs packages

8 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use android-emulator.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • eigenwalletSkill

    android-emulator

    Drive the Android emulator for realistic end-to-end tests of the app's Android features and UI (install APK, puppeteer the UI, read backend logs). Use whenever a change needs verification on Android.

    Also in 3 projects that use this

The file

We split this skill into the rules it gives an agent

5 rules. 0 are common, 1 is distinctive, and 4 are very specific to this project.

  • 0

    Common

    Most of the 7 edited versions we read keep these.

  • 1

    Distinctive

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Run the checks and install the driver: prerequisites.md.

    line 28
  2. Very specific:

    Trust effects, not exit codes: Every actuation channel here confirms delivery, not processing: AXe synthesizes HID events …

    line 51
  3. Very specific:

    Gate on readiness signals, never fixed sleeps: Wait on something provably true: simctl bootstatus -b for boot (references/lifecycle.md), …

    line 59
  4. Very specific:

    Prefer simctl and AXe (accessibility) over the window and coordinates, and identity over coordinates (the targeting ladder in …

    line 69
  5. Distinctive:

    Every factual claim here and in the references cites a primary source (the tool's own help, Apple, AXe).

    line 72

“Common” is measured: kept by at least 6 in 10 of the 7 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

iOS Simulator (core, project-agnostic)

The kernel for driving an iOS Simulator on macOS. Layers sit ON TOP of this: expo-ios-simulator (the Expo/React-Native runtime), mobile-accessibility (the tree you drive against), ios-simulator-triage (when it breaks), and ios-simulator-flow-evidence (capturing proof). Everything here goes through xcrun simctl and AXe; the Simulator app window is touched only for what the CLI cannot do.

Before anything

Run the checks and install the driver: prerequisites.md. In short, macOS with Xcode (so xcrun simctl), a booted simulator, and AXe (brew install cameroncooke/axe/axe).

The loop

  1. Boot, install, launch an app on a device (references/lifecycle.md): find the booted UDID, simctl install, simctl launch.
  2. Drive by accessibility, not coordinates (references/driving.md): axe tap --id or --label, axe type, axe swipe or gesture. See mobile-accessibility for what makes an app addressable.
  3. Capture (references/capture.md): simctl io ... screenshot; the screenshot is the device framebuffer, so window size and position never matter. Verify it with vision.
  4. Set device state and permissions (references/permissions.md, references/device-state.md): simctl privacy to skip dialogs; appearance, status bar, location, media, clipboard, and push to put the device in a known state.
  5. The app's own chrome (references/simulator-ui.md): menu-only features, the window geometry, and opening a URL on the device.

Rules

The first three are laws about how this environment fails; internalize them before the first command, because the failures they prevent emit no error.

  • Trust effects, not exit codes. Every actuation channel here confirms delivery, not processing: AXe synthesizes HID events (references/driving.md), an AppleScript menu click returns success even when Simulator is backgrounded and the click never lands (references/simulator-ui.md), and simctl launch / openurl return before the app is interactive (observed, reproducible; the readiness gates in expo-ios-simulator references/development-builds.md exist for exactly this). After any step whose outcome matters, verify the state actually changed: re-run axe describe-ui, or screenshot and read it.
  • Gate on readiness signals, never fixed sleeps. Wait on something provably true: simctl bootstatus -b for boot (references/lifecycle.md), --wait-timeout for an element, the accessibility tree growing labels for a screen. A sleep that worked once is a flake that has not fired yet. Layer skills add their own signals (Metro's /status probe and the first-bundle wait in expo-ios-simulator).
  • Ask what is on top before blaming the target. iOS stacks surfaces over the app: permission and app alerts, the software keyboard, and (on Expo) the dev menu, the LogBox toast, and the inspector overlay. When a tap silently does nothing or the tree looks wrong, dump the label inventory (references/driving.md) and clear the overlay first; ios-simulator-triage references/automation-failures.md walks the causes.
  • Prefer simctl and AXe (accessibility) over the window and coordinates, and identity over coordinates (the targeting ladder in references/driving.md). Read the Simulator's state; never resize or full-screen it.
  • Every factual claim here and in the references cites a primary source (the tool's own help, Apple, AXe); a prior-art skill is never a source.

Where to go next

  • Running an Expo or React Native app, the dev menu, the recurring launch prompts: expo-ios-simulator.
  • A build, runtime, or automation failure: ios-simulator-triage.
  • Screenshots and video as proof artifacts: ios-simulator-flow-evidence.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.