adversarial-ios-design

Adversarial iOS Design Gate

An iOS design-and-UX review gate — pass/fail: a single blind reviewer subagent judges the work against this gate's rules with an adversarial mandate, and the work passes only when every rule is PASS or N/A. This skill renders verdicts; it never fixes the work.

The gate judges rendered user interface, not source text. Capturing evidence — simulator screenshots and interaction recordings tiled into filmstrips — is a mandatory protocol step, and the reviewer works backwards from the pixels: observe the captures, suspect violations, then open code only to locate them. Code-only review is the gate's recorded failure mode: it turns the gate into a linter that prescribes animations it has never seen.

The rules are the decidable subset of what an Apple design review would flag — every rule names the evidence that decides it, drawn from the Human Interface Guidelines, WWDC design sessions, and Apple's own measured app conventions. The gate judges the failure modes agents and experienced-but-not-expert developers actually ship: hamburger drawers where tab bars belong, pushed forms that lose drafts on a swipe, alerts that say "Yes"/"No", blank empty states, whole-screen spinners, teleporting state changes, glass painted on content, and text that clips at accessibility sizes.

When to Apply

• A user-facing SwiftUI screen, feature, or PR is about to merge and needs an objective PASS/FAIL on design and UX quality, not advisory feedback.
• An agent (Claude, Codex) authored the UI and you want an independent check that it follows platform grammar — modality, navigation structure, alert discipline, feedback states — rather than web/Android idioms translated into Swift.
• A screen "works" but feels non-native, and you want the decidable causes enumerated with locations instead of taste adjectives.
• A design polish pass claims Apple-level quality and you want that claim tested against what the screen actually renders — screenshots and filmstrips — not against what the code implies.
• A previous "polish" or gate-driven fix round made the UI busier — added animations, haptics, or decoration — and you want the restraint direction enforced: gratuitous motion fails, and every fix must be the minimal change with removal preferred over addition.
• The diff changes gestures or interaction behavior (recognizers, drag/long-press/resize, custom ButtonStyle/PrimitiveButtonStyle implementations) — run this gate, with its capture protocol, before the sibling architecture gates: recognizer arbitration is invisible to code-only review, a single clean trial is not evidence (see the repeated-trials requirement in references/_evidence-capture.md), and sequencing this gate last is how interaction regressions ship looking reviewed.