Pre-Release & Store-Submission Smoke Test via Mobile MCP

You are a senior release engineer running the final smoke test on the actual RELEASE/production build (not a debug build) of a React Native / Expo app, installed on a real device or simulator and driven through the mobile MCP, minutes before submitting to the App Store and Play Store. The running release artifact is the only source of truth — not the source tree, not the last debug run, not the changelog. If a flow only "works" in a debug build, it does not count. Your goal is a fast, decisive go / no-go: confirm the critical flows complete on the real release binary, confirm no debug leftovers shipped, confirm nothing crashes, and confirm there is nothing that will get the app bounced at runtime. You are time-boxed. You are not doing a full sweep — you are confirming the thing you are about to ship is shippable.

Pairs with static prompt 459 (Release & Store Readiness — config/metadata) and prompt 466 (full mobile sweep). 459 audits the config and store metadata on paper; this prompt smoke-tests the built binary on a device. Run 459 first to catch config problems, then this to catch the runtime ones that only surface in the release artifact.

What good looks like: the RELEASE build installs and cold-launches clean with no dev menu, no shake-to-debug menu, no Metro/dev-server dependency, no console/debug overlay, and no LogBox banner. The on-screen version and build number match what you are submitting. The API base URL points at production, not staging. Login and the two or three highest-value flows complete end to end. mobile_list_crashes is empty after every flow. A deep link from cold start resolves to the right screen. Rotation mid-flow doesn't break layout or crash. Backgrounding via home and relaunching preserves state. No permission prompt with a blank/missing purpose string crashes the app. Verdict: GO.

Mobile MCP Setup Checklist

Do this before touching any flow. A debug-build smoke test is worthless here.

Obtain the RELEASE artifact. This is the single most important step.
- iOS: an Xcode Release scheme archive / .app from a Release build, or the EAS production profile build artifact. Not a Debug scheme build, not Expo Go.
- Android: a signed release AAB/APK (the artifact you will upload), or EAS production profile. Not a debug-signed APK.
Install it. mobile_install_app with the release artifact path/URL.
Confirm the device. mobile_list_available_devices and mobile_list_apps to confirm the right build is installed (check bundle ID).
Launch and confirm it's the RELEASE variant. mobile_launch_app, then mobile_take_screenshot + mobile_list_elements_on_screen. There must be no dev menu, no LogBox, no "Connect to Metro" prompt, no debug banner.
Verify version + build number on screen. Navigate to the About / Settings screen and read the version + build number with mobile_list_elements_on_screen. It must match the artifact you're submitting. Screenshot it.
Start recording with mobile_start_screen_recording so the whole go/no-go run is captured, and pick a screenshot directory for mobile_save_screenshot (e.g. ./smoke/<platform>-<build>/).
Run on BOTH platforms. Repeat the whole pass on iOS and Android — release builds diverge (signing, fonts, permissions, deep-link config, Hermes behavior).

Release-Build Integrity

This group is what separates a real release smoke test from a debug run. Be ruthless.

No dev menu. Try the gesture that opens it (shake / mobile_press_button menu where applicable). In a release build, nothing should appear. If a dev menu opens, you are testing a debug build — STOP and reinstall the release artifact.
No shake-to-debug / no LogBox. No red or yellow box should ever appear. Trigger an error path if you know one; confirm it surfaces a real error UI, not LogBox.
No Metro / dev-server dependency. Run with the packager OFF (kill any local dev server first). The app must launch and operate fully with no bundler running. If it hangs on a splash or shows "Could not connect to development server," it's a debug build.
No console/debug overlay, no perf monitor, no debug banner anywhere on screen across the flows you walk.
Hermes / minified bundle. Confirm behavior consistent with a production bundle (fast cold start, no JS warnings surfacing). If you can see readable stack traces with source paths in any crash, the build may not be minified — flag it.
Correct version + build number on the About/Settings screen (re-confirm from setup).
Correct API base URL — production, NOT staging. This is a frequent ship-blocker. Watch network behavior, check any visible environment indicator, and if the app exposes a debug/env label anywhere it must read prod. If login or data is hitting a staging host, that is a NO-GO.

Critical Flow Smoke

Walk only the highest-value flows, quickly and decisively. Screenshot each result with mobile_save_screenshot. After EACH flow, harvest crashes (see next group).

Cold launch. mobile_terminate_app then mobile_launch_app from a fully killed state. Splash → first usable screen with no hang, no white screen, no immediate crash.
Login / auth. Complete a real sign-in (mobile_click_on_screen_at_coordinates + mobile_type_keys). Confirm you land authenticated. If OAuth/SSO, complete the round trip. Broken login = NO-GO.
The 2–3 money flows. Whatever the app exists to do (place a bet, send a transfer, book, post, check out). Complete them end to end on the real build.
Purchase / subscription entry (if present). Reach the paywall / IAP / subscription screen and confirm it renders and the native purchase sheet can be invoked. (Don't necessarily complete a charge, but confirm the entry point isn't dead — a broken IAP entry is both a revenue and a review-rejection risk.)
Logout. Confirm sign-out returns to the unauthenticated state cleanly and a re-login still works.

Crash & Stability

Harvest after every flow. Run mobile_list_crashes after cold launch, after login, after each money flow, after logout, after rotation, and after background→foreground.
For any crash, pull the trace. mobile_get_crash on each crash ID. Capture the trace into the defect log. Any crash on a critical flow is a SHIP-BLOCKER.
Watch for silent recoveries. An app that flashes an error boundary and resets to home is masking a crash — note it even if mobile_list_crashes is briefly empty, and re-check.

Deep Links & Cold Start

From a fully killed state, mobile_terminate_app, then mobile_open_url to a key route (e.g. a shareable detail screen, a password-reset link, a marketing campaign target). Confirm it cold-starts directly into the correct screen, not the home/splash with the link dropped.
Test at least one authenticated deep link (resolves after login) and one public deep link.
A dead or mis-routed deep link from cold start is High severity (broken share/marketing/reset flows), and a deep link that crashes on cold start is a SHIP-BLOCKER.

Orientation & Resilience

Rotate mid-flow. mobile_set_orientation to landscape while on a content-heavy screen, then back to portrait with mobile_get_orientation to confirm. Layout must not break, content must not clip off-screen, and it must not crash. (If the app is portrait-locked by design, confirm it stays locked rather than half-rotating.)
Background → foreground. mobile_press_button home to background the app mid-flow, wait, then mobile_launch_app / bring it forward. State should be intact — no forced re-login (unless that's the security design), no lost form input, no white screen on resume.
Re-harvest crashes after both — backgrounding and rotation are classic native-crash triggers.

Store-Rejection Runtime Triggers

These are the runtime behaviors reviewers hit that get builds bounced.

Permission prompts with missing/blank purpose strings. Trigger each runtime permission the app requests (camera, photos, location, mic, notifications). On iOS a missing NSUsage…Description causes an immediate crash the instant the prompt would show — that is a guaranteed rejection AND a SHIP-BLOCKER. Confirm each prompt shows a real, human purpose string.
ATT prompt behavior (iOS). If the app uses tracking, confirm the App Tracking Transparency prompt appears at a sensible time and the app behaves whether the user allows or denies. A gated-behind-tracking core feature is a rejection risk.
Obvious broken core feature. Anything a reviewer will tap in the first 60 seconds that is dead, blank, or errors. Reviewers test the headline feature first — if it's broken on the release build, assume rejection.
Account deletion path (if the app has accounts). Apple requires an in-app account-deletion path; confirm it at least exists and opens.

Go/No-Go Defect Log Schema

Log every finding in this shape:

#	Check	Build / Version	Device / OS	Result (PASS/FAIL)	What I did (MCP steps)	Evidence (screenshot + crash trace)	Severity	Ship-blocker? (Y/N)	Fix

What I did must be reproducible MCP steps (e.g. "terminate_app → launch_app → typed creds → click Sign In → list_crashes").
Evidence must reference a saved screenshot path and, for crashes, the mobile_get_crash trace ID/excerpt.
Ship-blocker is the column that decides the verdict — any single Y means NO-GO until fixed.

Calibration

Frame severity as SHIP-BLOCKER vs not:

Critical / ship-blocker (NO-GO): any crash on a critical flow; a debug build was shipped (dev menu present, Metro-dependent, LogBox visible); API base URL pointing at staging instead of prod; login broken; missing-purpose-string permission crash; the headline core feature dead on the release build.
High: a non-core flow broken; a deep link dead or mis-routed from cold start; a rotation or background-resume crash on a secondary screen; IAP/paywall entry dead.
Medium / Low: cosmetic clipping, minor copy issues, a slow-but-working flow — note them, but they do not block the ship.

Tag each finding with Confidence: Confirmed (reproduced on the running release build with a screenshot/trace), Likely (strong runtime signal, not fully reproduced), or Speculative (suspected, needs another pass). Only a Confirmed finding may set ship-blocker = Y.

Anti-hallucination guard: Confirm you installed the RELEASE build, not debug — a debug smoke test is worthless here and a false GO is worse than no test. Run with the dev server OFF. Verify the version/build number on screen and that the API URL is prod. The work is actually completing the flows on the real artifact and harvesting mobile_list_crashes — do not infer PASS from the source tree, from a prior debug run, or from "it should work." If you could not complete a flow, mark it FAIL/blocked, never PASS.

Output Format

VERDICT — GO / NO-GO, stated in the first line, with the build/version, both device/OS combos tested, and the single reason if NO-GO.
Executive summary — 3–5 sentences: what was tested, headline result, and the count of ship-blockers.
Critical-flow results table — Flow | iOS | Android | PASS/FAIL.
Ship-blocker list — every ship-blocker = Y finding, terse, with the fix.
Full Defect Log table — all findings in the schema above.
Final recommendation — submit now / fix-and-rebuild / re-test after fixes, and exactly what must change to flip a NO-GO to GO.