Expo Simulators Makes Build Identity Part of Review Evidence

Summary

Expo Simulators moves mobile app checks into cloud sessions with recordings and other review artifacts. The engineering requirement is to connect that evidence to the exact build and JavaScript under review: a matching native fingerprint does not establish that a release build contains the latest change.

Key Updates

• Cloud sessions are generally available. Expo launched the service on November 12 for paid plans. It provides iOS Simulators and Android Emulators that agents, CI jobs and teammates can operate remotely. Expo says each session uses its own VM, and recordings, screenshots and logs remain available for later review. Launch announcement
• Build selection can change what the evidence means. Expo's build guide says release builds use JavaScript embedded at build time; development builds load it from Metro. A matching fingerprint identifies native compatibility, but a release build selected that way can still contain an older JavaScript bundle. Connecting that release build to Metro does not make it show live edits. Builds and bundles
• Evidence has different coverage and access rules. Session activity records controller actions, while app logs describe application output. Saved iOS app logs cover only the first 30 minutes. Job logs have a 30-day availability window; session artifacts remain until the session is deleted. Artifact download URLs work without an Expo login. Evidence guide

Why It Matters

Our interpretation is that a review now needs an evidence manifest alongside the recording: what ran, which change it contained, and which behavior the session exercised. Otherwise, an agent can demonstrate a convincing success path while the reviewer attributes that result to code the installed app never loaded.

This extends our isolated runtime preview coverage, which examined what a branch environment actually isolates. Here, the additional question is whether the observed mobile runtime contains the proposed change. Our Expo JNI analysis addressed application performance and resource lifetimes; a simulator recording supplies a different kind of evidence.

Keep that distinction explicit. Expo's limitations page says recordings can miss frames and cannot establish whether a brief frame drop occurred. Physical devices are not provided. It also labels simulator commands experimental even though the service launch is GA. This article reviews documentation; it does not report an independent service trial, benchmark or security assessment. Documented limitations

Builder Takeaway

For one pull request, record the commit, build identifier, build type, JavaScript source, device configuration and session ID. Confirm that the installed app contains the change before collecting evidence. Use a test account and a controlled backend, then capture the relevant success and failure paths with expected outcomes.

Attach the recording and supporting logs with a short statement of what was exercised and what remains untested. Export evidence needed beyond its retention window, and review artifact links before sharing them. Keep physical-device and profiling checks in the release process where hardware behavior or frame timing matters. These are proposed acceptance steps, not tests performed for this article.