A long-running AI task creates a mobile problem that a chat request does not: the work can outlive the screen, the network, the access token, and the app process.
The success condition is not “the spinner kept spinning.” It is “the user can leave, return, and recover the authoritative task state without duplicating work or losing control.”
This article is a test protocol, not a device benchmark. It defines the devices, network transitions, evidence, and invariants a team should record before claiming mobile continuity.
Define the system boundary first
Write down where the task actually runs:
mobile app -> task API -> durable task record -> worker -> artifacts
^ |
+-------------+ status stream or polling
If the task executes in a cloud development environment, suspending the phone should not terminate the task. If execution is on-device, background limits, thermal state, battery, and operating-system scheduling become part of correctness. Do not mix those architectures in one result table.
Record a complete test envelope
Every result needs enough context to reproduce it:
device_model:
os_and_version:
app_build:
execution_location: cloud | edge | device
network_start: wifi | cellular | constrained
account_role:
task_fixture_and_revision:
task_id:
task_start_utc:
transition_start_utc:
recovery_start_utc:
battery_start_percent:
battery_end_percent:
screen_state:
expected_invariant:
observed_result:
evidence_links:
Use at least one current iOS device and one Android device from the team's supported range. Add an older or memory-constrained device when it represents real users. A simulator is useful for deterministic UI flows, but it is not evidence for battery, radio behavior, thermal limits, or real process eviction.
Use one deterministic task fixture
Choose a repository and task that:
- takes at least five minutes so lifecycle changes can occur;
- produces an inspectable patch and test result;
- is safe to repeat;
- has no production credentials;
- starts from a pinned revision;
- has a known success condition.
Example fixture:
Repository: a disposable calculator API
Revision: pinned commit SHA
Task: add input validation for division by zero
Success: one expected source change + one new passing test
Maximum duration: 15 minutes
Do not change the prompt between network scenarios. Otherwise task variance can be mistaken for mobile lifecycle behavior.
Run the continuity matrix
| Scenario | Action | Invariant |
|---|---|---|
| Background | Send app to background for 30 seconds, then five minutes | One task continues; return shows authoritative state |
| Screen lock | Lock during execution, then unlock | No duplicate task; sensitive content follows lock policy |
| Process death | Terminate the app process, then relaunch | Task is recovered by server ID, not recreated from UI memory |
| Wi-Fi → cellular | Switch networks during a status update | Reconnect resumes from a cursor/version without losing terminal state |
| Offline | Enable airplane mode for 60 seconds | UI says state is stale and disables unsafe repeated submission |
| Token expiry | Expire auth while task runs | Reauthentication preserves task identity and intended return path |
| Duplicate tap | Tap submit repeatedly under latency | One logical task is accepted or duplicates are explicitly linked |
| Cancel offline | Request cancel while disconnected | UI labels the request as pending, not completed |
| Cancel during command | Cancel while a build runs | “Requested” and “confirmed” are distinguishable |
| Notification tap | Open from task-complete notification | Correct account and task open; access is rechecked |
| Account switch | Switch account before opening a deep link | No cross-account task data appears |
| Server restart | Restart a non-production worker during the task | Mobile UI reports recovery or failure without inventing success |
The offline cancel case is especially revealing. A local button tap is not proof that the server accepted cancellation.
Model freshness in the UI
The mobile client needs more than a task state. It also needs the age and source of that state:
{
"taskId": "task-123",
"state": "running",
"version": 17,
"updatedAt": "2026-07-10T08:00:00Z",
"connection": "reconnecting",
"pendingAction": null
}
Render “Running — last updated 42 seconds ago; reconnecting” rather than a fresh-looking animation. When a cancel action is queued locally, show “Cancel will be sent when connected” and provide an undo path if the product can support it.
On reconnect, compare a monotonic version or event cursor. A response older than the displayed version must not move the UI backward from succeeded to running.
Measure recovery, not animation smoothness
Capture these metrics per scenario:
| Metric | Definition |
|---|---|
| State recovery latency | app foreground or relaunch to authoritative task state |
| Duplicate task count | extra server tasks created for one intended submission |
| Stale-state duration | time UI presents a state older than the server record |
| Ambiguous cancel window | cancel tap to confirmed terminal state or explicit failure |
| Data transferred | bytes during the scenario, separated from artifact downloads |
| Battery delta | percentage and duration, reported with device and screen state |
Do not publish a cross-device average without the individual samples. A median over three runs per scenario is a reasonable starting summary; keep raw runs for regressions.
A source-based MonkeyCode application
The MonkeyCode README documents an online environment with native mobile support and synchronized PC/mobile data. Its repository includes this mobile screenshot:
Source: MonkeyCode repository at commit 1ac778f, licensed with the project under AGPL-3.0.
That public material makes MonkeyCode a relevant target for this protocol. It does not supply the device, OS, network, battery, or recovery measurements required to fill in the result table. Those claims should wait for a controlled device run.
Disclosure: I contribute to the MonkeyCode project. This is a proposed mobile test protocol based on public documentation, not a hands-on performance review.
Mobile developers can join the MonkeyCode Discord to ask the team about supported workflows and help turn the matrix into version-specific tests. The team can also confirm current eligibility and usage limits for any free model credits.
Mobile continuity is a server-state and recovery problem wearing a small-screen interface. Test process death, stale data, and ambiguous cancellation before celebrating that the task can be opened from a phone.
Top comments (0)