Skip to content

release-ui-smoke-audit.md

Latest commit

 

History

History
90 lines (72 loc) · 3.65 KB

release-ui-smoke-audit.md

File metadata and controls

90 lines (72 loc) · 3.65 KB
Raw

Release UI Smoke Audit

Purpose

Release UI smoke auditing is a release-time visual confidence pass for the real app running in Simulator. It complements the repository's Xcode-native build, shared-library test, and retained-rule posture without replacing it.

Use this audit to catch issues that library tests and app builds cannot see:

  • launch failures
  • blank or frozen primary screens
  • unreachable core navigation
  • obvious clipping, overlap, or unreadable text
  • broken sheets, popovers, sidebars, and split-view layouts
  • companion target or widget coverage gaps that need human follow-up
  • visual issues a human release reviewer can spot from captured screenshots

Relationship to Verification

Standard task verification is Xcode-native-first: use the integration available in the agent environment for app build, shared-library test, runtime logs, Preview, live UI, and screenshots, then run bash ci_scripts/tasks/check_repository_rules.sh for SwiftLint and repository-specific static architecture checks. Release UI smoke auditing is a separate release-confidence pass and should not be added to every task by default.

Workflow

Use the global $xcode-ui-smoke-auditor skill when performing this audit. The skill resolves the current Xcode-native actions for building, launching, inspecting the live UI hierarchy, capturing screenshots, and reporting findings.

The repository expectation is:

  1. Run Xcode-native build/test checks and retained repository rules for code readiness.
  2. Run release UI smoke only when preparing a release or when a UI-sensitive change needs live Simulator evidence.
  3. Prefer representative iPhone and iPad Simulator coverage when available. For iPad, treat landscape as the representative layout because sidebar and split-view behavior are core release surfaces.
  4. Treat the Apple Watch app as companion target coverage. Audit it when the available tool surface supports watchOS Simulator inspection; otherwise, report it as a coverage gap with the concrete blocker.
  5. Treat widgets as extension visual surfaces. Audit them when the available tool surface can place or inspect WidgetKit surfaces safely; otherwise, report the skipped widget coverage explicitly.
  6. Keep screenshots and findings in the audit report, not as committed test artifacts.
  7. Group screenshots by device, orientation, and screen so the report can be used both as agent evidence and as a human release review gallery.
  8. Treat skipped targets and state-dependent coverage as explicit coverage gaps.

Safety Rules

Release UI smoke auditing is non-destructive by default.

  • Do not erase simulators, delete app data, reset keychains, or wipe containers unless explicitly requested.
  • Do not perform purchases, account actions, sends, deletes, or other externally visible actions.
  • Do not add UI test targets, snapshot tests, accessibility identifiers, or debug routes solely as part of the audit.
  • Use repository-provided debug or sample data flows only when they are clearly safe.
  • If deterministic state is needed, prefer debug-only launch arguments that do not remove existing data.

Reporting

Reports should be evidence-backed and concise. Use the structure from $xcode-ui-smoke-auditor:

  1. blocking issues
  2. warnings
  3. notes
  4. coverage gaps
  5. screenshots
  6. Xcode selection

When no issue is found, state that no blocking issue was observed in the audited coverage and still list remaining gaps.

Screenshot evidence should be reviewable. Prefer inline images when the environment supports local image rendering, and call out screenshots that are sideways, cropped, blank, obscured, or otherwise insufficient for human review.