QAKit

An AI agent that QA-tests your iOS app on a real iPhone.
Every screen, every button, dark mode, large text, VoiceOver, a crash watch, Apple's accessibility audit, and a release verdict with evidence.
Plus the two checks a release needs behind it: would your tests notice a bug, and does your copy say what it claims.

One walk, one phone. Onboarding, every scroll position, every button tapped once, the audit on each screen. 29 frames from one test's attachments.

Same walk, three variants. --variant default --variant dark --variant large-text switches the phone, not the app. The examples/Notes app.

Sixty seconds

pip install qa-agent-kit                                   # qakit-device, qakit-release-checks, qakit-mutate, qakit-prose, qakit-install-skills
qakit-device doctor --manifest myapp/release/testing/device_qa.json      # Xcode, the phone, signing, the manifest
qakit-device test   --manifest myapp/release/testing/device_qa.json --suite qa --variant dark --variant large-text
qakit-device test   --manifest myapp/release/testing/device_qa.json --suite qa --variant dark --simulator   # no phone yet? the same run on a simulator

A run leaves summary.json, a contact sheet of every screenshot, the audit report per screen and any crash logs (docs/report.md). Your walkthrough test is a few lines on top of the Swift package:

import XCTest
import QAKit

QA.walk(app, "settings", in: self, deny: ["Delete"]) { QA.settle(app, on: screen, in: self) { relaunch() } }
QA.audit(app, "detail", in: self)        // Apple's accessibility audit, every issue in one report, known classes explained
QA.answerSystemAlert()                   // permission prompts, in the phone's language

Give the procedure to the agent you already use:

claude plugin marketplace add younatics/QAKit && claude plugin install qakit@younatics   # Claude Code: skills + MCP tools
qakit-install-skills --target codex        # or cursor, gemini, all; --scope user
claude mcp add qakit -- python3 /path/to/qakit/mcp/server.py   # any MCP client: doctor, test, shots, crashes, release checks, mutation, prose, verdict

What the agent does that a test runner does not

• Walks the app the way a tester does. QA.walk screenshots the screen, runs the accessibility audit, taps every visible button once at every scroll position, checks the app is still in front and comes back. Nothing random.
• Changes the phone, not the app. Dark mode, accessibility text sizes, a simulated location and VoiceOver are set on the device through Xcode 27's devicectl, so system alerts and other apps render as your users will see them.
• Explains the audit instead of drowning in it. One report per screen; the classes that are never a defect (a system bar button, text measured under the floating tab bar, secondary text that nearly passed) are counted and named.
• Checks what the store will check. What's New, review notes, localized permission strings, required-reason APIs, the age rating, entitlements and associated domains, before the upload (release_checks.py).
• Keeps one phone fair between agents. Several sessions share a USB iPhone in arrival order (qakit-device lock).
• Says what it did. The protocol has 180 checks with IDs, pass criteria and sources (docs/device-qa-protocol.md, 한국어); the verdict cites them.

The two layers behind it

Both are gates in forge, a multi-agent coding loop, on every task. The mutation layer was measured on humanize, tenacity and swift-argument-parser: of fifteen sampled survivors, seven were real test gaps (docs/case-studies.md).

Where it comes from

QAKit grew out of shipping App Store apps as a solo developer whose QA team is an agent. Every check was added after a defect that green tests let through. A >= became > at a grading boundary and 13 mutants survived. A review note ran over the 4,000-character limit. A caption failed contrast and nobody looked. A What's New still announced the first release in version 1.1. A walk put the phone in the app switcher. Two apps and the example app have been through it on a USB iPhone, and every gap they hit came back as a fix with a test and a tag (RELEASING.md).

Documentation

Requirements

iOS 17 or later for the accessibility audit, Xcode 15 or later to build the Swift package, Xcode 27 for the variants. A USB-attached iPhone is the real thing; --simulator runs the same suites and variants (except VoiceOver) on an iOS Simulator, so the first hour needs only Xcode. The Python tools need Python 3.10 or later and nothing else; the test suite runs on Linux too.

Status

Private beta, 178 tests, in daily use on the author's apps. The Swift API and the manifest keys may still change between minor versions until 1.0 (CHANGELOG.md). MIT (LICENSE).