Help us improve
Share bugs, ideas, or general feedback.
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.
npx claudepluginhub yusufkaran/swiftui-autotest-skill --plugin swiftui-autotest-skillHow this skill is triggered — by the user, by Claude, or both
Slash command
/swiftui-autotest-skill:ios-testThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
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.
Provides workflows for executing XCTest unit tests and XCUITest UI tests on iOS simulators/devices, detecting flaky tests, analyzing failures, and optimizing parallel/CI execution.
Builds, installs, launches iOS apps on simulator using XcodeBuildMCP. Captures screenshots and logs to verify UI, check for crashes, and test key screens.
Debugs iOS app issues in simulator via structured loop: captures screenshots/logs with ios-simulator/XcodeBuildMCP, analyzes problems, proposes specific fixes, confirms with user, rebuilds, and verifies changes.
Share bugs, ideas, or general feedback.
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.
--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).xcodeproj or .xcworkspace in the working directory
.xcworkspace if it exists (CocoaPods/SPM workspace)xcodebuild -list -workspace MyApp.xcworkspace
--scheme if providedIMPORTANT: Simulator must be selected BEFORE building. The build command uses the selected device name.
--device is provided: find that device via xcrun simctl list devices --json--device is not provided, check booted simulators:
xcrun simctl list devices booted --json
xcrun simctl list devices available --json, suggest the best iPhone match, ask for confirmation, then boot itThis step is MANDATORY. Runs BEFORE build. NEVER skip this step.
struct ... : View patterns in *.swift filesButton, TextField, SecureField, Toggle, Slider, Picker, DatePicker, NavigationLink, Image, .onTapGesture.accessibilityIdentifier()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)
/add-accessibility workflow (scan, generate, apply), then continue to step 4 (Build)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..app file:
find ./DerivedData -name "*.app" -path "*/Debug-iphonesimulator/*" | head -1
plutil -p /path/to/MyApp.app/Info.plist | grep CFBundleIdentifier
xcrun simctl install booted /path/to/MyApp.app
xcrun simctl launch booted <BUNDLE_ID>
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.
Discover and test all main screens:
--flow=<name>Test the specified user flow:
--screen=<ViewName>Find and test only the specified screen. Navigate to it if needed.
--states only)Test different app states using launch arguments.
Check if the app supports state overrides via CommandLine.arguments:
--show-empty-state, --show-error-state, --show-loading-state@AppStorage or UserDefaults debug flagsIf not found, ask the user:
No state test support found. Would you like me to add launch argument
handling to your @main App struct?
A #if DEBUG block will be added supporting:
- --show-empty-state
- --show-error-state
- --show-loading-state
Only active in DEBUG builds. Add it?
If available, relaunch the app for each state:
xcrun simctl terminate booted com.example.MyApp
xcrun simctl launch booted com.example.MyApp --show-empty-state
For each state verify:
Check for crashes during and after testing:
xcrun simctl spawn booted log show --predicate 'process == "MyApp" AND messageType == 21' --last 5m
If a crash is found:
--performance only)ONLY run when --performance is provided. SKIP in default tests.
Measure RAM usage per screen and check for memory leaks.
Find the app's PID:
xcrun simctl spawn booted launchctl list | grep <BundleID>
Take a baseline measurement on launch:
footprint -all <PID>
On each screen transition:
footprint -all <PID>, record RAMCheck for leaks on back navigation:
Run a full leak scan at the end:
leaks <PID>
Report: leak count, object types, stack traces
Performance report format:
Performance Report
━━━━━━━━━━━━━━━━━━━━━━━━━
Baseline (launch): 42 MB
Screen Transitions:
HomeView: 45 MB (+3 MB)
SettingsView: 52 MB (+7 MB)
ProfileView: 68 MB (+16 MB) ⚠️
→ HomeView (back): 61 MB (-7 MB, 16 MB not released) ⚠️
Memory Leaks: 2 found
- SettingsViewModel: 1 leak (closure retain cycle?)
- ImageCache: 1 leak
⚠️ High RAM: ProfileView (+16 MB jump)
⚠️ Potential Leak: 16 MB not released on return to HomeView
Show a summary report when testing is complete:
iOS Test Report
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
App: MyApp (com.example.MyApp)
Device: iPhone 16 (iOS 18.2)
Scheme: MyApp
Duration: 2m 34s
Screens Tested: 8
✅ HomeView - OK
✅ ProfileView - OK
⚠️ SettingsView - Toggle "notifications" not tappable
✅ OnboardingStep1 - OK
✅ OnboardingStep2 - OK
✅ OnboardingStep3 - OK
❌ CheckoutView - Crash (force unwrap on nil)
✅ SearchView - OK
Screenshots: 12 captured
Crashes: 1
CheckoutView.swift:42 - Force unwrap on nil optional
UI Issues: 1
SettingsView - notifications toggle not accessible
State Test Results:
✅ Empty State - OK
⚠️ Error State - Missing retry button
✅ Loading State - OK
--states is providedtest-home-screen.png)