Menu
Step-by-step workflows for developing or debugging React Native apps on iOS simulator or Android emulator. Use when starting the app, debugging Metro, fixing builds, diagnosing runtime errors, or running tests.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Set up and connect to an Android emulator using argent MCP tools. Use when starting a new session on Android, booting an emulator, getting a device serial, or before any UI interaction task.
Record a reusable flow (scripted sequence of MCP tool calls) that can be replayed later with a single command. Use when the user asks to create, record, or build a flow, or to script a sequence of simulator actions.
Interact with an iOS simulator or Android emulator using argent MCP tools. Use when tapping UI elements, performing gestures, scrolling, typing text, pressing hardware buttons, launching apps, opening URLs, taking screenshots.
Set up and connect to an iOS simulator using argent MCP tools. Use when starting a new session, booting a simulator, getting a simulator UDID, or before any simulator interaction task.
Debug a React Native app via Metro CDP using argent debugger tools. Use when connecting to Metro, inspecting React components, reading console logs, or evaluating JavaScript in the app runtime.
Native profiling for CPU hotspots, UI hangs, and memory leaks. Currently iOS-only (xctrace-backed); Android support (Perfetto/simpleperf) is on the roadmap. Use when diagnosing native-level performance issues.
| name | argent-react-native-app-workflow |
| description | Step-by-step workflows for developing or debugging React Native apps on iOS simulator or Android emulator. Use when starting the app, debugging Metro, fixing builds, diagnosing runtime errors, or running tests. |
Before running commands, read the project's build and run configuration from the argent-environment-inspector subagent result.
Do NOT default to npx react-native start or npx react-native run-ios without first checking for custom scripts and workflows.
Manual fallback (if neither the agent nor the tool is available): read ALL package.json scripts — look for custom scripts like start:local, start:dev, ios, build:ios, flavors, etc. Custom scripts take priority over default commands. Also check metro.config.js for non-default port or watchFolders. For iOS builds, prefer opening .xcworkspace over .xcodeproj (CocoaPods generates the workspace).
If the project structure is convoluted, ask the user before proceeding.
Remember the workflow: Once you discover the project's build/run workflow, save it to project memory so you don't need to re-discover it each time.
Checklist before start:
node_modules present (if not: bun install)ios/Podfile exists; if ios/Pods missing or stale, run cd ios && pod install && cd ..Check whether metro is already running on port found in configuration and if it is - do not start another server. Refer to point 2.1.
Use the project's custom start script if one exists (e.g. npm run start:local, yarn start:dev). In this monorepo:
bun mobile start
Fall back to npx react-native start only if no project script exists. Optional: bun mobile start --reset-cache if cache issues are suspected.
Verify Metro is ready: use the debugger-status tool to verify Metro is running and reachable.
Projects with flavors or custom configs: Use project-specific start script if present (e.g. npm run start:local), and start Metro before running the app.
In a separate terminal (Metro keeps running in the first):
Use the project's custom build/run script if one exists (e.g. npm run ios, npm run android, yarn ios:debug). Only fall back to the default if no custom scripts are defined:
npx react-native run-ios # iOS
npx react-native run-android # Android
Optional: specify the target device, e.g. npx react-native run-ios --simulator="iPhone 16" or npx react-native run-android --deviceId=<serial>.
Android only: after install, run adb -s <serial> reverse tcp:8081 tcp:8081 so the emulator/device can reach Metro on your host. Repeat if the device restarts or adb drops.
Agent checklist:
boot-device with the iOS udid or Android avdName. Refer to the argent-ios-simulator-setup / argent-android-emulator-setup skill.adb -s <serial> reverse tcp:8081 tcp:8081 done.Before starting Metro, avoid "port already in use" errors. Default port to check is :8081, infer the port from documentation:
lsof -i :PORT
Use the debugger-status tool to check whether the process on that port is actually a Metro server. If not Metro — ask the user whether you may kill the process.
To kill a Metro process, use the stop-metro tool (requires user confirmation).
Verify Metro is reachable: use the debugger-status tool.
After code or config changes, the app must load the new bundle:
| Method | How |
|---|---|
| Reload tool | Use the debugger-reload-metro tool |
| Restart app | Use the restart-app tool, or kill the app in simulator and run npx react-native run-ios again |
Agent checklist:
Order of operations (simplest first):
watchman watch-del-all, remove node_modules + lockfile, bun install, then cd ios && rm -rf build Pods Podfile.lock && pod install --repo-updatepod deintegrate then pod install --repo-updateios/*.xcworkspace in Xcode for detailed errors in the Report navigatorAfter 2-3 failed build or run attempts, STOP and ask the user for guidance. The user may know about required env vars, Xcode version requirements, custom build configurations, monorepo-specific setup, or required external services.
If the project structure is convoluted and the correct build approach is not obvious, ask the user early rather than guessing.
Once you discover the correct build/run workflow for a project, save it to project memory. Capture: commands to start Metro, commands to build/run the app, and any required environment setup.
| Situation | Action |
|---|---|
| JS/React only changed | Use debugger-reload-metro tool. No rebuild. |
Native code or pod install / project config changed | Rebuild: npx react-native run-ios (Metro can stay running). |
node_modules or package.json changed | bun install, then if native deps changed run cd ios && pod install. Then rebuild. |
| App needs reinstalling from .app path | Use reinstall-app tool with UDID, bundle ID, and .app path. |
| Persistent native build errors | Full clean + reinstall (step 2 above). |
| Action | Tool / Command |
|---|---|
| List devices | list-devices tool (iOS + Android) |
| Boot an iOS simulator | boot-device tool with udid |
| Boot an Android emulator | boot-device tool with avdName |
| Launch an app | launch-app tool (pass device id + bundle id / package name) |
| Restart an app | restart-app tool (pass device id + bundle id / package name) |
| Open a URL / deep link | open-url tool (pass device id + URL) |
| Rotate device | rotate tool |
| Stop simulator server | stop-simulator-server tool (iOS UDID or Android serial — one device) |
| Stop all simulator servers | stop-all-simulator-servers tool (iOS + Android) |
For full simulator setup workflow, refer to the argent-ios-simulator-setup skill.
Applies to Android local release-variant builds (bun mobile android:<flavor>:release:local, i.e. apps/mobile/scripts/runAndroidLocal.sh). Release variants embed the JS bundle in the APK, so a verify-on-device loop can silently test old code through two independent caching layers. Each makes a change look like it had "no effect" when it was never in the installed APK. Both must be defeated — disabling one alone is not enough. runAndroidLocal.sh handles both by default; this section is for recognizing the symptoms if a build looks stale or you build with another command.
apps/mobile/app.config.ts sets experiments.buildCacheProvider: 'eas'. expo run:android computes a native fingerprint and, on a match, downloads + installs a cached APK instead of building. A JS-only change does not move the native fingerprint, so for a release variant it reinstalls an APK with old JS.
Searching builds with matching fingerprint on EAS servers → Successfully downloaded cached build → install path under …/eas-build-run-cache/….apk.eas-build-run-cache path.runAndroidLocal.sh — it exports EXPO_LOCAL_NO_BUILD_CACHE=1, which gates the provider off in app.config.ts so a real build runs. Confirm › Building app... in the logs (not "downloaded cached build"). If invoking expo run:android directly, export EXPO_LOCAL_NO_BUILD_CACHE=1 yourself.createBundle<Variant>JsAndAssets stays UP-TO-DATEEven with the EAS cache off, gradle's incremental check misses changes to monorepo JS sources (e.g. packages/uniswap/**), so the bundle task stays UP-TO-DATE and the APK embeds the previously-bundled index.android.bundle.
Symptom (logs): > Task :app:createBundleDevReleaseJsAndAssets UP-TO-DATE.
Detection: compare the embedded bundle mtime to your edit time:
ls -la apps/mobile/android/app/build/generated/assets/createBundle<Variant>JsAndAssets/index.android.bundle
Fix: runAndroidLocal.sh deletes the bundle task outputs by default (pass --no-clean-js to skip for native-only rebuilds). To clear them manually, remove:
apps/mobile/android/app/build/generated/assets/createBundle<Variant>JsAndAssetsapps/mobile/android/app/build/generated/res/createBundle<Variant>JsAndAssetsapps/mobile/android/app/build/intermediates/assets/<variant>A successful regen logs > Task :app:createBundle<Variant>JsAndAssets (no UP-TO-DATE) and Writing bundle output to …. <Variant> is the capitalized gradle variant (DevRelease, BetaRelease, ProdRelease); <variant> is the camelCase form (devRelease, …).
| Problem type | Tool / Where to look |
|---|---|
| JavaScript errors / logs | Use debugger-log-registry to get a summary and log file path, then Grep/Read to search. |
| React component hierarchy | Use debugger-component-tree tool for a text tree, or debugger-inspect-element at specific logical pixel coordinates (not normalized 0-1). |
| Visual state of the app | Use screenshot tool to capture the current screen, but prefer describe or debugger-component-tree for actual navigation and target discovery. If a permission prompt or system-owned modal overlay is not exposed reliably, then fall back to screenshot. |
| Evaluate JS in the app | Use debugger-evaluate tool to run JavaScript in the app's runtime. |
| Native crashes / native stack | npx react-native log-ios or iOS Simulator: Debug → Open System Log. |
| Build/runtime config | metro.config.js, babel.config.js, package.json scripts, ios/Podfile. |
For comprehensive Metro debugging workflows (component inspection, console logs, JS evaluation), refer to the argent-metro-debugger skill.
Logs are written to a flat log file on disk under ~/.argent/tmp/. Use the log-registry → grep pattern instead of reading logs inline.
For the full workflow, flat entry format, and grep examples, see argent-metro-debugger skill §5.
Use the argent tools instead.
Check the argent-environment-inspector result for test commands. For interactive UI testing with automatic screenshot verification, use the argent-test-ui-flow skill.
package.json ("test": "jest", jest config). Run: npm test or yarn test..detoxrc.js or similar), or other E2E config. Dependencies: detox, detox-cli, and for iOS often applesimutils.argent-test-ui-flow skill.If the user's intent is ambiguous (run existing tests, write new tests, or find missing coverage), clarify before proceeding.
npm test or npx jest.detox build --configuration ios.sim.release (or debug).detox test --configuration ios.sim.release.package.json and test config (Jest, Detox, etc.).| Goal | Tool / Command |
|---|---|
| Check port 8081 | lsof -i :8081 |
| Kill Metro | stop-metro tool |
| Start Metro | npx react-native start |
| Start Metro (reset cache) | npx react-native start --reset-cache |
| Run iOS app | npx react-native run-ios |
| Run Android app | npx react-native run-android |
| List devices | list-devices tool (iOS + Android) |
| Boot a device | boot-device tool (pass udid for iOS or avdName for Android) |
| Take screenshot | screenshot tool |
| Describe screen (a11y tree) | describe tool for normal app screens and in-app modals; use screenshot only when permission/system overlays are not exposed reliably |
| Read JS console logs | debugger-log-registry tool |
| Reload JS bundle | debugger-reload-metro tool |
| Check Metro status | debugger-status tool |
| Inspect React component tree | debugger-component-tree tool |
| Run JS in app | debugger-evaluate tool |
| iOS native logs | npx react-native log-ios |
| Android native logs | npx react-native log-android or adb -s <serial> logcat |
| Clean + reinstall (nuclear) | See §3.1 step 3 |
| Skill | When to use |
|---|---|
argent-ios-simulator-setup | Initial simulator boot and connection setup |
argent-device-interact | Tapping, swiping, typing, hardware buttons, gestures on the simulator/emulator |
argent-metro-debugger | Full Metro CDP debugging: component inspection, console logs, JS evaluation |
argent-react-native-profiler | Profiling performance, finding re-render issues, CPU hotspots |
argent-test-ui-flow | Interactive UI testing with automatic screenshot verification after each action |
Ask the user before running tests: confirm which test suite (unit, E2E, or both), whether to use existing CI commands, and whether they want you to run existing tests, write new ones, or explore test cases yourself.