In this guide
  1. Fix the device and deployed revision
  2. Use simulation as an initial check
  3. Exercise the software keyboard
  4. Hypothetical task: resubmission after failure
  5. Separate observed failure and diagnosis
  6. Preserve the release evidence

Fix the device and deployed revision

Record device, operating system, browser, orientation, deployed URL and application revision. Begin with the configurations your users need and list untested conditions instead of claiming every phone was covered. An app built in Bolt, Lovable or Replit still has distinct preview and published destinations. For a hypothetical request form, complete input through the result on the deployed revision. Verify that an old tab or different URL is not supplying the observed behavior. Aligning device and release evidence makes it possible to distinguish a device-specific problem from simply checking the wrong build.

Use simulation as an initial check

Chrome documentation describes Device Mode as an approximation rather than code running on a mobile device. It helps examine width, orientation and throttled conditions, but does not replace every hardware, input or browser behavior. Fix obvious layout problems in simulation, then repeat the same journey on a real device. Chrome provides a documented Android remote-debugging route when deeper evidence is needed. Do not assume the same procedure covers another operating system or browser. Match the investigation method to the actual target and keep simulated observations distinguishable from results obtained on the device.

Exercise the software keyboard

Focus a field and inspect whether the software keyboard hides submission controls or an error. Move between fields, scroll to correct input and continue to the result. Try relevant sample input such as Japanese composition, long text and pasted values. Fitting the viewport does not establish a completable interaction. When requesting a fix, supply the device conditions, field, hidden information and expected behavior. A screenshot alone cannot establish keyboard or persistence assumptions. Reproduction steps let the maintainer verify the same failure after the patch instead of judging a different static layout.

Hypothetical task: resubmission after failure

For a hypothetical request form, consider a connection failure during submission. Define whether input is preserved, the failure is understandable and retry avoids duplicate storage. These are example requirements for your app, not automatic guarantees from a builder. After recovery, inspect the saved result rather than accepting a success message alone. Add back navigation, orientation change or returning from another tab when relevant to the intended journey. Use sample records and test connections so the exercise does not notify real customers. The evidence should distinguish an interface update from a verified stored outcome.

Separate observed failure and diagnosis

A broad statement that mobile does not work gives no reproducible acceptance check. Separate the observed action, display and stored result from your suspected cause. For repository assistance such as Cursor, provide the relevant view, styles and execution conditions without requesting an unrelated redesign. Repeat the original journey on the same device after the fix and retain necessary desktop checks. Accessibility and performance have additional requirements, so one device journey does not establish complete conformance or speed. The useful result is a specific corrected interaction with a clear record of what remains untested.

Preserve the release evidence

Decide on extra agent capacity using retries and verification effort for the same defect. More allowance cannot supply missing device evidence or reproduction steps. Handoff should retain the device list, deployed revision, checked journeys, failure samples and untested conditions. Inspect screenshots and logs before sharing them when they may contain private information. Repeat the same journeys in a destination when changing the builder or operating arrangement. This distinguishes recreating an appearance from preserving a service users can actually continue operating on the devices the team has agreed to support.

Official sources

Pricing, availability and feature limits can change. Check the linked official pages before subscribing.

How we compareAdvertising disclosure