Auto-Setup XCUITest UI Tests for Your iOS App

Standing up XCUITest UI tests for a native iOS app by hand is slow — read your view
hierarchy, decide which screens matter, tag every element with a stable
`accessibilityIdentifier`, write a base test case, wire the app to a test backend, and fight
the simulator quirks that make selectors silently fail. **This skill does all of that wiring
for you.** Point it at your project root; it reads how your app is built and generates a
complete, runnable XCUITest suite — then tells you exactly how to run it.

### ✅ What you get
- **Screen discovery + curation** — SwiftUI views and UIKit view controllers; *you* pick which matter
- **An `accessibilityIdentifier` tagging plan** — with the XCUITest matcher caveats baked in
- **A shared `BaseUITestCase.swift`** — mock-server seam, error-injection helpers, and `loginViaUi()`
- **One happy-path spec per screen** — asserting by stable identifier, never visible text
- **Server-side error-state specs** — when a mock server is available, driven via `/__mock/*`
- **Scheme / test-plan steps** — launch-env `MOCK_PORT`, test-action membership, simulator hygiene

### 🔌 How it connects to your backend
The test build points your app's API base URL at a mock server (or your test backend) via a
`--api-url` launch argument the app reads at startup. The simulator shares the host network, so
the mock is reached at plain `localhost:<port>` — there is **no** `10.0.2.2` translation hop
(that is Android only). Specs drive the mock's `/__mock/*` control API over `URLSession` — no
in-app changes.

### 🧩 Works on its own — better with a mock server
On its own it stands up the **happy-path** specs and the base test case — that's the
auto-setup, done, no extra purchase needed. For **deterministic, offline runs and
server-side error-state** coverage, add a mock server exposing the `/__mock/*` control API:
the companion skill **Bootstrap Mobile Mock Server** scaffolds exactly that. No mock server?
This skill asks how you'd like to proceed and scaffolds the happy-path suite right away; add
the mock server later and re-run to generate the error-state specs.

### 🛡️ Safe by default
It shows the full plan and asks before writing anything. The only source edits it makes are
`accessibilityIdentifier` props — **no refactors, no logic changes.** The default login
strategy (`ui-login`) touches no app source. It **never edits your `.pbxproj` or scheme from
chat** — scheme/test-plan changes are emitted as Xcode steps for you to apply.

### 🧪 Why it works
Distilled from a **production iOS testing harness used on real shipping apps**, so it bakes in
the conventions that keep XCUITest suites stable:
- `accessibilityIdentifier` queries matched to the element kind, over brittle text matchers
- Scoping ambiguous matches from an identified ancestor instead of re-tagging
- Launch-arg mock wiring with `localhost` (no Android-style address translation)
- A bounded, defensive `clearMockError()` teardown that degrades to a timeout if the mock is down
- Simulator hygiene + `-only-testing` scheme-membership gotchas that otherwise report false green

### ▶️ What you run
It **scaffolds and instructs** — writes the suite and prints the exact Xcode steps + the
`xcodebuild test` / Cmd-U commands. You run them.

### 📋 Requirements
- A native iOS project (SwiftUI or UIKit) with an existing `*UITests` target
- Xcode + command-line tools

---
*Built for iOS developers and QA engineers who want a real XCUITest E2E suite stood up in
minutes instead of days.*