/ios-test

name: ios-test
description: Build, launch, and visually test iOS/SwiftUI apps in the Simulator using computer use. Automated screen navigation, crash log analysis, state testing (empty/error/loading), and memory leak detection. Use when you need to test an iOS app, run it in the Simulator, check for crashes, or verify UI flows.

iOS Test Skill

Overview

Use this skill to build an iOS/SwiftUI application, launch it in the Simulator, and visually test it using computer use. The skill navigates through every screen, screenshots each state, checks crash logs, and produces a structured test report — without writing a single line of test code.

Options

• `--flow=<name>`: Test a specific user flow (e.g., onboarding, login, checkout)
• `--screen=<ViewName>`: Test only a specific screen
• `--device=<name>`: Choose a Simulator device (e.g., "iPhone 16", "iPhone SE")
• `--scheme=<name>`: Specify the Xcode scheme
• `--states`: Test empty, error, and loading states via launch arguments
• `--screenshot-all`: Screenshot every step
• `--performance`: Measure RAM per screen and check for memory leaks (skipped by default)

Workflow

1) Project Discovery

• Find `.xcodeproj` or `.xcworkspace` in the working directory
• Prefer `.xcworkspace` if it exists (CocoaPods/SPM workspace)
• If multiple exist, ask the user which one to use
• If none found, stop with an error
• List available schemes:

  xcodebuild -list -workspace MyApp.xcworkspace

• Use `--scheme` if provided
• If only one scheme exists, use it automatically
• If multiple, ask the user

2) Simulator Selection (BEFORE build)

**IMPORTANT: Simulator must be selected BEFORE building. The build command uses the selected device name.**

• If `--device` is provided: find that device via `xcrun simctl list devices --json`
• If `--device` is not provided, check booted simulators:

  xcrun simctl list devices booted --json

• **No booted simulator**: list available devices with `xcrun simctl list devices available --json`, suggest the best iPhone match, ask for confirmation, then boot it
• **One booted simulator**: use it directly, no questions
• **Multiple booted**: list them and ask the user which one to use

3) Accessibility Check (MANDATORY — DO NOT SKIP)

**This step is MANDATORY. Runs BEFORE build. NEVER skip this step.**

1. Scan SwiftUI files in the project — look for `struct` ... `: View` patterns in `*.swift` files 2. Count interactive elements: `Button`, `TextField`, `SecureField`, `Toggle`, `Slider`, `Picker`, `DatePicker`, `NavigationLink`, `Image`, `.onTapGesture` 3. Check how many have `.accessibilityIdentifier()` 4. **ALWAYS ask the user (this question cannot be skipped):**

Accessibility Scan Result:
   Total interactive elements: XX
   With identifier: XX
   Missing identifier: XX

Identifiers help me find elements more reliably during testing.

Run /add-accessibility to add identifiers now?
  → Yes: adds identifiers, then builds and continues to testing
  → No: builds directly and uses coordinate-based testing (slower and more fragile)

5. **WAIT for the user's response.** Do not proceed without an answer. 6. If yes → run the full `/add-accessibility` workflow (scan, generate, apply), then continue to step 4 (Build) 7. If no → continue to step 4 (Build) directly

4) Build

• Build the selected scheme using the device chosen in step 2:

  xcodebuild build \
    -workspace MyApp.xcworkspace \
    -scheme MyApp \
    -destination 'platform=iOS Simulator,name=<SELECTED_DEVICE>' \
    -derivedDataPath ./DerivedData \
    2>&1

**NEVER hardcode a device name. Always use the device selected in step 2.**

• If build fails: analyze errors, suggest fixes, and **STOP** — never proceed to testing with a failed build
• Report build warnings (but don't stop)

5) Install & Launch

• Find the built `.app` file:

  find ./DerivedData -name "*.app" -path "*/Debug-iphonesimulator/*" | head -1

• Get the bundle identifier:

  plutil -p /path/to/MyApp.app/Info.plist | grep CFBundleIdentifier

• Install and launch:

  xcrun simctl install booted /path/to/MyApp.app
  xcrun simctl launch booted <BUNDLE_ID>

6) Visual Testing with Computer Use

**IMPORTANT: This phase requires the `computer-use` MCP server to be enabled.**

If computer use is not enabled, tell the user:

Computer use is not enabled. Required for visual testing.
Run /mcp and enable the computer-use server.

Default test (no arguments)

Discover and test all main screens:

1. **TabView present** → tap each tab, inspect each screen 2. **NavigationStack present** → tap each navigation link, go back 3. **On each screen** check:

• Layout renders correctly (no overflow, overlapping, or empty areas)
• Buttons are tappable
• Scroll works and content is visible
• Text is readable (not too small, not truncated)

4. Screenshot each screen

With `--flow=<name>`

Test the specified user flow:

• **onboarding**: swipe through onboarding screens, complete all steps
• **login**: fill email/password fields (test@example.com / Test1234), tap login, verify next screen
• **signup**: fill the registration form, tap signup
• **checkout**: navigate to cart, complete the payment flow
• **settings**: open settings, try each toggle/slider, go back
• Other flows: ask the user "What steps should I follow for this flow?"

With `--screen=<ViewName>`

Find and test only the specified screen. Navigate to it if needed.

7) State Testing (`--states` only)

Test different app states using launch arguments.

1. Check if the app supports state overrides via `CommandLine.arguments`:

• Search SwiftUI files for `--show-empty-state`, `--show-error-state`, `--show-loading-state`
• Search for `@AppStorage` or `UserDefaults` debug flags

2. If not found, ask the user:

   No state test support found. Would you like me to add launch argume