Plan on iPhone, review on iPad, execute on Mac: a mobile-web acceptance checklist

Start with the actual release boundary

As of September 21, 2026, Critical Path has a web application, but no verified public signed native release for iPhone, iPad, or Mac. Native project preparation does not establish App Review acceptance, native push, offline editing, or operating-system handoff. This guide deliberately tests the browser workflow and does not direct you to a nonexistent store listing.

Apple documents adding a website to the iPhone Home Screen and opening it as a web app. That is a browser-platform convenience, not a promise that this particular website implements every native capability. Browser, operating-system version, managed-device policy, and storage permissions can affect behavior. Start in a normal browser tab, then separately test any home-screen installation you choose to use.

Record device model, operating-system version, browser version, and whether you used a tab or home-screen window. Without that context, a statement that it worked on an iPhone is too vague to reproduce when a colleague encounters a different result.

Sources: Apple: turn a website into an iPhone web app

Use one fictional commitment across all three screens

Our fictional test action is Prepare the partner-review decision, owned by the tester, due next Friday, with 90 minutes allocated. Its plan has three steps: collect questions, compare options, and write the recommendation. No real customer names, invitees, or confidential documents are needed. This keeps failures easy to diagnose without exposing useful business data.

On iPhone, capture the action and confirm the parsed details. On iPad, review its quadrant, owner, and allocation. On Mac, inspect the plan and calendar placement. Then close one plan step and check that another device shows the same progress after loading current saved state. Do not create three copies of the action to make the screenshots look consistent.

This sequence tests persistence and comprehension, not just layout. A screen can look excellent while showing an old record. The test passes only when the saved title, owner, date, allocation, and step progress match, and when the user understands what remains unfinished.

Give each device a meaningful job

Use the device for the interaction you actually expect in daily work. Avoid requiring a phone to reproduce a desktop density preference or accepting a tablet view merely because it fits inside a screenshot. The following checks are proposed acceptance criteria; they are not a report of signed-device testing already performed.

Treat Saved as a boundary, not a decorative label

After editing, wait for the workspace to report Saved before moving to another device. If the application reports offline, retry, or review-sync attention, do not assume that closing the drawer or seeing the new value means the server accepted it. Reopen from the second device only after confirming the first edit is saved, and compare a distinctive but harmless note.

The current recovery mechanism retains pending changes in tab-local browser session storage where available. That is not a cloud backup and should not be expected to appear on another device. Browser restrictions, cleared storage, or losing the tab can limit recovery. If a conflict appears, download a recovery copy before choosing to load the saved server version.

Do not force a conflict using important work. With the fictional test action, try two separate cases: edit different fields from tabs sharing an older starting version, then change the same field to different values. Non-overlapping changes may merge safely; overlapping changes should require review. Preserve both intended values when testing the conflict. Silently overwriting another person's edit is not a convenience worth accepting.

Test sign-in and calendar authorization independently

Sign in to the same account and workspace on each device. A familiar name in the interface is not enough when you have multiple accounts. Open a normal workspace page from a logged-out browser, complete sign-in, and check the destination. Do not paste invitation tokens or authentication callback URLs into public troubleshooting notes.

Calendar authorization is a separate test. In Settings → Connections, verify the actual connection state. Requested is not connected. With authorization healthy, allocate the test action, give it a due date, review placement, and inspect the provider calendar. A device showing a Calendar page is not proof that the external event exists.

Check the workspace time zone against the provider display before judging a mismatch. A due date represents a day; a reservation has a time and duration. Moving between devices with different display settings should not be treated as a reason to casually edit the deadline. If a change is unexpected, capture the relevant zone and local time without exposing private meetings.

Include accessibility and interruption checks

Try browser zoom, larger text, and the assistive technology you actually rely on. On a keyboard, move through the page and open and close a task drawer without touching the pointer. On a touch screen, confirm that status, date, and allocation controls can be used accurately. A color difference should not be the only way you recognize a state.

With VoiceOver or another screen reader, check whether the task title, field labels, buttons, and error messages are understandable in reading order. This is a test prescription, not an accessibility-conformance claim. If a key action is unreachable or ambiguously named, record the exact control and stop treating that device as an accepted primary workflow.

Finally, background the browser during a harmless edit and return. Test a temporary network interruption without relying on it as an offline mode. Confirm the visible save state afterward. Native background execution, push delivery, and offline synchronization require their own verified implementation; a responsive web page does not establish them.

Finish with evidence and a conservative adoption decision

Use Help & setup to revisit the guided sequence: capture, allocate, connect, verify a block, and align an outcome. The current checklist examines workspace records; you should still confirm that your own test action, not a sample record, produced the evidence. Optional automation setup can wait until the basic cross-device loop is trustworthy.

Download a snapshot from Settings → Data & privacy if you need a private record. The JSON includes current workspace state and may include pending recovery information. Keep it out of public issue trackers and check it before sharing with support. A successful download is not a promise of automatic import into another product.

Adopt the device combination only when your important actions pass. If capture works on phone but detailed planning is difficult, a deliberate phone-capture and desktop-review workflow may still suit you. Describe the limitation honestly rather than pretending every screen is interchangeable. Report reproducible failures with device details, expected result, actual result, and a redacted example.

Common questions