← ClaudeAtlas

verifylisted

Build, launch and drive a React Native app on the iOS simulator to observe a change end-to-end. Use when verifying a code change actually works at runtime and not just in tests, when the user asks to run the app, take a screenshot, or check something on device, or when a bug can only be confirmed by driving the UI. Covers idb-based tapping, why synthetic clicks fail, where console output actually goes, and simulator gotchas.
ltatarev/skills · ★ 0 · Web & Frontend · score 68
Install: claude install-skill ltatarev/skills
# Verifying on the iOS simulator Static checks and unit tests do not prove a UI change works. This skill is the procedure for actually driving the app and observing it. ## Build and launch ```sh npx react-native run-ios --simulator='iPhone 17 Pro Max' ``` Cold builds take a few minutes (longer on a fresh pod install). After a **JS-only** change no rebuild is needed — Metro serves a fresh bundle on relaunch: ```sh xcrun simctl terminate booted <bundle-id> xcrun simctl launch booted <bundle-id> ``` Get the bundle id from the Xcode project or `app.json` rather than guessing. ## Driving the UI — use idb, not synthetic clicks **Do not** drive the simulator with AppleScript `click at` or `cliclick`. Both post mouse events that the Simulator delivers unreliably: they land at the wrong coordinates, get swallowed by the window's pointer capture ("Press esc to stop capture" in the title bar), and succeed only intermittently. This costs a lot of time and produces confusing evidence — you cannot tell a failed tap from a bug. Use `idb`, which taps the device directly in **device points**: ```sh brew install facebook/fb/idb-companion /usr/bin/python3 -m venv idbenv && ./idbenv/bin/pip install fb-idb # needs py3.9; fb-idb breaks on 3.14 idb_companion --udid <UDID> & # note the grpc port it prints ./idbenv/bin/idb connect localhost <port> ./idbenv/bin/idb ui tap <x> <y> ``` **Coordinates.** A screenshot from `xcrun simctl io booted screenshot