verify Mobile QA Start now

Tests like a human · Scales like a machine

Fully autonomous mobile QA on real mobile devices

Verify is an autonomous QA engineer for mobile teams. On every pull request it installs your build on a real mobile device, iPhone or Android, explores it the way a human tester would, and files bug reports backed by video, reproduction steps, and device logs, before your users find them.

No test scripts to write. No device farm to manage. One check on your PR.

Run #1847 iPhone 14 · iOS 17.5 · hardware
  1. 00:00.0INSTALLbuild 4f2c9a · app.ipa (signed)
  2. 00:04.2LAUNCHcold start 1.84 s
  3. 00:07.5OBSERVEscreen: Welcome · 14 elements
  4. 00:09.1TAP“Sign in”
  5. 00:11.8TYPEqa+pilot@… · ••••••••
  6. 00:14.0ASSERTsession established ✓
  7. 00:17.3SWIPEfeed ↓ ×3 · 60 fps held
  8. 00:21.6TAP“Checkout”
  9. 00:24.9✗ CRASHSIGABRT · NSInvalidArgumentException
  10. 00:25.0CAPTUREvideo · stack · syslog · a11y tree
  11. 00:25.2REPLAYreproduced 2 of 2 attempts
  12. 00:25.6FILEDFinding #312 · HIGH · posted to PR
Evidence Captured
100%Runs on real hardware, never just a simulator
0Test scripts written or maintained by your team
~25minFrom PR opened to evidence-backed verdict
+Every failing check reproduced before it reaches you

The new bottleneck

Writing code is no longer the bottleneck.
Knowing if it works, is.

A. Tests with the code’s blind spots

AI writes your code, and it happily writes your unit and e2e tests too. But tests built from the same assumptions prove the code does what its author intended. They can’t notice that the intention was wrong, or that the result looks broken to a human.

B. Human testing doesn’t scale

Launch the simulator, tap around, hope you hit the broken path. It’s slow, inconsistent, and the important flows get skipped exactly when you’re shipping fastest.

C. Mobile fails where you can’t see

Push notifications, biometrics, memory pressure, app lifecycle, frame drops. Whole classes of bugs simply never appear in a simulator or emulator. They appear on your users’ phones.

“Works in the simulator. Broken on a real phone.” The sentence every mobile team knows by heart.

How it works

A QA engineer that clocks in on every pull request.

01 / HOOK

Your PR triggers a run

Install the GitHub App once. Your CI uploads a signed build (.ipa or .apk) as usual. Verify picks it up and opens a Mobile QA check on the commit. No SDK, no code changes.

02 / DEVICE

Installed on real hardware

The build goes onto a dedicated, clean-slate iPhone or Android phone: real silicon, real OS, real radios. Screen recording and diagnostics start before the first frame renders.

03 / EXPLORE

The agent tests like a human

It reads the screen, signs in with your QA account, and works the app: tapping, typing, and swiping while it maps screens it hasn’t seen and probes the flows your users actually take.

04 / VERDICT

Evidence lands on your PR

Crashes, hangs, broken flows, layout breaks, and regressions are reproduced, packaged with video and logs, and posted to the PR. Fail only on proven bugs, never on vibes.

Exhibit A

Every bug ships with its own proof.

No flaky red ✗ with a stack trace and a shrug. A Verify finding is a complete dossier: what broke, exactly how to make it break again, and the footage to watch it happen, timestamped to the second.

Findings are reproduced on-device before they ever reach you. If we can’t make it happen twice, it’s labeled a suspected finding and never fails your build.

✓ Honest by design A passing check means the agent explored your app on real hardware and proved nothing objective broke, not that nothing was tested.
Finding #309 · Run #1847 Medium · Reproduced

Cart total clipped behind “Place Order” when a discount row is added

DeviceiPhone 14 · iOS 17.5
Build4f2c9a · PR #248
Video TS03:47 – 03:58
DetectorLayout · overlap
ConfidenceObjective · 2/2 repro
First seenThis PR ↰
  1. Launch app, sign in with QA account
  2. Add “Desk Lamp” to cart from search
  3. Apply promo code WELCOME10
  4. Discount row pushes the order summary down
  5. Total hidden behind Place Order: 24 px overlap
Replayed clean build: renders correctly on main Verdict: visual regression introduced by PR #248
Simulators miss →
Push notificationsFace ID & biometricsMemory pressureDeep linksApp lifecycle bugsFrame dropsCamera accessGPS & locationBluetoothBackground executionBattery drainCold-start latency Push notificationsFace ID & biometricsMemory pressureDeep linksApp lifecycle bugsFrame dropsCamera accessGPS & locationBluetoothBackground executionBattery drainCold-start latency

Built to be trusted

An agent in your pipeline has to be boringly safe.

§ 1 · ACCESS

Least-privilege by default

The GitHub App asks for the minimum: read your CI artifacts, write one check, comment on the PR. It never sees your source code unless you explicitly grant it. Every permission is documented and auditable.

§ 2 · GUARDRAILS

Explores boldly, acts carefully

Hard boundaries around destructive territory: no purchases, no real messages, no account deletion, no production data mutation. The agent tests your app. It doesn’t gamble with it.

§ 3 · SECRETS

Credentials stay sealed

QA credentials live in encrypted backend config, injected at runtime, scrubbed from every log, screenshot annotation, and report. Devices are wiped clean between runs. No residue, ever.

§ 4 · SIGNAL

A red check you can believe

Verify fails a build only on reproduced, objective bugs. Suspected issues are reported separately, with evidence, and never block your merge. False alarms are treated as defects in our product.

Pilot program · Now onboarding

Let the agent take the night shift.

We onboard one app at a time and treat the first bug like it matters, because it does. One real mobile device, your signed build, two weeks to your first evidence-backed finding. If we don’t find anything worth your time, you owe us nothing.

  Real iPhones & Android devices · built for teams shipping with Claude Code, Cursor & Codex