mobile release pass · iOS Simulator
A mobile QA agent for the screens this release changed.
Greenroom installs your simulator build fresh, walks the iOS screens your diff touched like a new user, and posts an evidence-backed handoff on the PR. Native Swift, SwiftUI, and React Native / Expo.
After the first session, an error toast sits on top of the purchase button for about four seconds. On a phone there is no second monitor to notice it on; the user just sees a purchase button that will not respond.
Why this matters for mobile teams.
On the web a bad release is a redeploy away from fixed. On iOS it is a review cycle away: the defect ships to every phone, the fix waits in the queue, and your rating absorbs the difference. The states most likely to break are the ones scripted suites skip because they are expensive to script: a fresh install with no cached state, dark mode, large dynamic type, and the purchase moment.
Greenroom walks those states on a real simulator, from a clean install every time, and records evidence for every action so the handoff shows what the phone actually showed.
Built for the way iOS ships.
No device farm, no test scripts, no credentials in your build job. A simulator artifact from CI is the whole input.
Simulator artifact
A Release simulator build with the JS bundle embedded, so the app never needs a Metro server. App Store binaries are device builds and cannot be walked; the simulator .app is what Greenroom installs.
Two-job CI split
Your build job runs your toolchain with no secrets. The Greenroom job never runs your build system; its only credential is a short-lived OIDC token bound to that exact workflow revision.
Sandboxed backend
Compile the simulator build against staging and the app cannot reach production by construction. Every network event during the walk is recorded in the evidence for audit.
Diff-scoped screens
A state contract tells Greenroom how your router maps source to screens, for SwiftUI or Expo Router, so a change to one view walks the screens that view can reach.
The setup, end to end.
Four files and one pull request. The iOS quickstart in the docs has the complete workflow, pinned to reviewed commit SHAs.
Questions from mobile teams
Do I need a device farm?
No. Greenroom walks your build on the Apple Simulator, on a dedicated simulator created for the run. Physical devices are not part of the product.
Does it work with Expo and React Native?
Yes. Native Swift, SwiftUI, and React Native / Expo apps all work. The requirement is a simulator build with no dev-server dependency: a Release configuration with the JS bundle embedded.
Can it test in-app purchases?
Against the StoreKit sandbox, when your environment manifest declares sandbox purchases. The driver refuses purchases and account creation unless a goal explicitly grants them, so a walk cannot buy something by accident.
What about Android?
Not yet. Greenroom covers iOS on the Simulator and web against preview deploys today. We would rather say that plainly than list a platform that is not built.
How does it know which screens my change touched?
From your state contract, which names your router kind and where the screen graph lives. With it, scoping is exact: changed file, changed screens, affected states. Without it, Greenroom scopes conservatively and a clean run caps at inconclusive.
Questions before you connect a repository?
Tell us about the app: React Native, Expo, Swift or web, which flows matter, and what you want a pass to catch. We reply by email. There is no sales call to book.
Self-serve is the fast path: sign in with GitHub, install the app on one repository, merge the setup files, open a pull request.
on: pull_request · advisory · iOS Simulator + web or read a full handoff from proof v1.4.2 →