A mobile demo can pass on an emulator and still fail on stage because the test environment leaves out the physical device, network conditions, permissions, thermal load and app state used during the presentation. In practice, “tested” often means one successful run under controlled conditions, with no repeatable evidence that the release build survives the real setup.
The timeline below is a diagnostic reconstruction, not a report of a specific launch event. It shows how a weak testing process can turn an apparently working demo into a public failure.
Minute 0 to 2: The prepared path works
The presenter unlocks the phone and opens the app. The first screen loads. A saved account is already signed in, and the demo begins on the exact path rehearsed earlier.
At this point, the team’s confidence appears justified. The app ran successfully on an emulator during development. Someone may also have opened it once on the presentation device before doors opened.
Those checks establish very little.
An emulator can confirm that code launches in a simulated configuration. It cannot prove that the same build behaves correctly with the phone’s camera, radio, storage pressure, permission state or operating-system services. One clean rehearsal proves that one sequence worked once.
A defensible test record would answer basic questions: Which build ran? On what hardware and OS version? Was it a fresh install? Were permissions reset? Was the account state created from scratch? Could another person repeat the result?
If those answers are missing, “tested” describes a memory rather than evidence.
Minute 3 to 5: The demo leaves the rehearsed state
The presenter reaches the first step that depends on the device or venue. Perhaps the app requests camera access, changes network connections, resumes after the screen locks or calls a service using credentials stored during rehearsal.
The loading indicator stays visible longer than expected.
A weak test process usually treats this pause as a performance problem. The more useful question is whether the app has entered a state the team ever tested.
Development environments accumulate helpful residue: cached responses, accepted permissions, valid sessions and local data created over weeks. Those conditions can hide broken first-run behavior. A release build installed on a clean phone may face a different sequence entirely.
The same distinction appeared in Green Checks, Dead Application: a passing signal can describe the check rather than the user’s experience. Green status carries weight only when the test covers the path people will actually take.
By now, the launch team has a decision to make. Wait, retry or move on. Without visible diagnostics, each option is guesswork.
Minute 6 to 8: Recovery attempts create new variables
The presenter closes and reopens the app. The session may persist, expire or return in a partly completed state. A second attempt fails differently because the first attempt changed local data.
Someone suggests switching to venue Wi-Fi. Another person checks the backend. The backup phone comes out, but nobody can confirm whether it has the same build, account or configuration.
This is where a software defect becomes an operational failure.
A useful demo plan defines recovery before the event:
- Keep the exact release build on at least two verified devices.
- Test on the venue network and a separate connection.
- Reset the app and account to the intended starting state.
- Record the build number, device model, OS version and test time.
- Assign one person to call the fallback instead of debating it live.
Each step reduces uncertainty. None guarantees a flawless demo, but together they prevent the team from discovering its own setup in front of an audience.
Remote testing can widen coverage before that moment. Google Cloud’s public preview of Developer Device Platform includes remote emulators and physical devices, parallel testing, device streaming and agent-driven mobile test workflows. Those capabilities can help teams run the same path across more configurations. They still require a precise test case and a release build that matches the one used on stage.
Access to more devices does not repair an undefined test.
Minute 9 onward: The failure outlives the crash
Once the presenter abandons the live path, the technical problem may be over. The credibility problem remains.
The audience cannot see whether the cause was the app, the network, an expired session or a misconfigured phone. They see a product presented as ready failing under its own prepared conditions.
The internal postmortem should begin with artifacts, not recollections. Preserve the build identifier, device logs, network state, account status and exact sequence of actions. Compare them with the last successful rehearsal. Then identify which claim in the test record was too broad.
“Ran on emulator” should stay “ran on emulator.”
“Opened on device” should stay “opened on device.”
“Ready for a live demo” should mean the release build completed the full script repeatedly on physical hardware, under realistic network and account conditions, with a verified fallback.
Before the next launch, hand the demo phone to someone who did not build the app. Give them the script, start a timer and watch without helping. When they can complete the path from a clean install, twice, on both the primary and backup devices, “tested” finally has a useful meaning.
Sources
Google Cloud announcement of the public preview of Developer Device Platform, as described in the supplied event context.
Comments
No comments yet.