weftrun runs your release build on real devices and your web app in a real browser, repeats every flow, photographs every screen and checks every journey. A change is flagged only when it clears the noise it was measured against.
No SDK and no source changes. The CLI builds your release app or opens your web app in a browser, measures it and puts everything back.
Sign in from the terminal and register the app, a mobile build or a web app. Flows live in your repo next to the code, so every machine runs the same steps.
Each repeat is a fresh cold start of the optimized build, or a fresh browser with the HTTP cache off. The spread across repeats becomes that metric's noise floor.
The dashboard compares the new version with the last one. Numbers turn red or green only when the move is bigger than the noise.
Speed, screens and journeys for mobile builds and web apps, measured against the same build and compared with the version before it.
On mobile, RAM, renders, launch time and frame pacing from the production build. On the web, Core Web Vitals rated against Google's thresholds, with JS heap and network beside them. Each step of the flow gets its own memory delta, so a leak points at the screen that caused it.
Every route photographed in light and dark, on device screens or browser viewports. Changed screens come first, and a navigation that silently failed is flagged instead of shipped as a stale picture.
Maestro flows sharded across devices, or Playwright journeys run in parallel in a browser. Every journey lists its steps as they run, and a failure names the step, the assertion and where it happened.
Enroll the Macs you already have. weftrun checks Xcode, simulators, Maestro, the browser toolchain and disk before it hands them a job, and tells you what to fix.
Most tools flag anything over a flat 5%, which cries wolf on a noisy metric and misses a real leak on a quiet one. weftrun colors a delta only when it clears twice the standard deviation it measured. Drag the candidate below and watch where red begins.
Mobile builds are instrumented at build time and reverted when the run ends; web apps are measured from the browser. Your repo stays clean.
The app is terminated between repeats and every web repeat gets a fresh browser, so caches from the last run never flatter the next one.
Retained memory is measured per step, so the number holds whether the run lasted 30 seconds or two minutes.
Different device, OS, simulator or browser? weftrun says the runs aren't comparable instead of guessing.
Free while you try it on one app. Team when the whole release depends on it.
For one app and a few runs a month.
For teams that gate every release on it.
For mobile apps, memory, render counts, launch timings, JS heap and frame pacing. For web apps, Core Web Vitals (LCP, FCP, TTFB, layout shift, blocking time), JS heap and network. Both get a photo of every screen and the result of every end-to-end journey, step by step.
No. weftrun instruments a mobile release build when it is built and reverts every change when the run ends; a web app is measured from the browser as it is. There is no SDK to add.
A single run can't tell a real change from a noisy one. Repeating gives every metric its own spread, and a delta is only colored when it clears twice that spread.
React Native apps on iOS and Android, Expo included, and web apps in Chromium. End-to-end flows use Maestro on mobile and Playwright on the web.
On Macs you enroll as runners, or on your own machine through the CLI. Results, screenshots and logs upload to your team's dashboard.
Access opens in batches. Join the waitlist and we'll email you when your seat is ready.
Join the waitlist and we'll email you the moment your seat is ready.
Free while in beta · one email when your seat opens