What gets checked
The checks a build has to survive before you are handed a preview, and what each one is there to catch.
Most tools call a build finished when the code compiles. Compiling proves almost nothing about a phone app: a build that compiles cleanly can still open to a blank screen, crash the moment someone taps a tab, or come back looking nothing like the prototype you approved.
So a Mistflow build has to earn the word "ready".
The checks
Compile
The app is bundled the way a real release is. Failures get a repair pass, then the build is failed rather than shipped.
Catches: broken code, missing imports, bad types.
Boot
The app is exported and loaded once in a headless browser inside the build sandbox.
Catches: apps that compile and then die on startup, and screens that render with no usable content. This is the "it built fine but the screen is white" class.
Fidelity
The built app is compared against the prototype you approved: the app name, the number of visible tabs, the accent colour, and whether a detail screen has leaked into the tab bar as though it were a section.
Catches: drift. You approved a thing; this is the check that you got that thing.
Run check on a real emulator
An Android emulator is booted, Expo Go is installed, your app is opened as a brand-new user, and the run is watched:
- The device is wiped first, so every run is a genuine first-time user
- The crash log is read for fatal errors, unresolved modules, and red screens
- Up to four tabs are tapped, since screens that load lazily crash on tap, not on launch
- Sign-up is filled in and submitted, and the result is checked for a real create, save, and read back
- A screen showing an error, or one that is close to empty, counts as a failure
Catches: the crashes that only exist on a device. This is the only check that runs your app on the real runtime people will use.
What this means for you
- A preview link means the app compiled, booted, matched your prototype, and survived a real-device run as a new user
- A build that fails these is failed, not delivered with a warning
- The first-run path is exercised on every build, which is the path you are least likely to test yourself
What it does not cover
- iPhone-specific runtime problems. The run check uses Android. iPhone previews work, but the equivalent automated run check for iPhone is not finished.
- Your business rules. Nobody checks that a booking cannot be double-booked except you.
- Long or multi-step flows. The automated run covers sign-up and tab navigation, not your seven-step checkout.
- Design quality. It checks that the app matches the prototype, not that the prototype was any good.
Automatic checks stop your app from being broken. They do not make it right. That is still your testing pass.
When a check fails
You see which stage failed in the build activity. Most failures are worth one retry, particularly on the emulator run, where genuine flakiness exists. Repeated failure at the same stage is a real problem in the app, and the crash detail is captured.