App problems:
test and fix

Start with a reproducible symptom

A mobile app problem may lie in the interface, backend, integration or the process definition itself. “The app is slow” does not identify a fix. You need the device, operating system version, build number, network conditions and sequence of actions.

Investigate using agreed test accounts and data. For each issue, record the expected and actual results, time and a screen recording. Do not post access tokens, personal data or the contents of work documents in a shared chat. If only a customer sees the problem, first obtain a safe description of the conditions.

This table guides the investigation; it does not establish the cause automatically. The same symptom can have different causes. After a fix, reproduce the original conditions or the check will be merely a formality.

Mistake: estimating development from pictures alone

The design has a “Save” button, but nobody has defined where the data goes, who may edit it or what happens offline. These decisions then have to be made during development. The result is scope disputes and constant changes to screens that were already finished.

How to check: choose three main workflows and ask for each to be demonstrated from start to actual outcome. Specify roles, fields, data sources, alternative states and acceptance criteria. If people describe different outcomes for the same feature, the requirement is not yet agreed.

How to fix it: document the first version’s boundaries and keep a change log. Each new feature needs an estimate, priority and decision from the client’s authorized representative. Do not remove error handling simply to deliver more screens: safely retrying an action can matter more than an extra section.

In the illustrative field engineer app, “close ticket” could mean saving a report locally, sending it to a dispatcher or receiving acceptance confirmation. These are three different states. The detailed requirements process is in the app development guide.

Mistake: testing only the ideal screen

A design with short labels looks tidy, but a long address in a real record covers the button. The keyboard hides a field, enlarged text is cut off and an empty list looks like a frozen app. Users cannot tell whether the app is working.

1. Populate the screen with long and empty values allowed by the real process.
2. Increase the system text size and repeat the main workflow.
3. Open the keyboard in the last field and check that the error and button remain visible.
4. Go back using both the system navigation and the app’s own controls.
5. Check screen-reader output for important elements and clear action labels.

The fix should cover wrapping, scrolling, labels and states, not just smaller text. Also check protection against accidental deletion and recovery from input mistakes. Red alone does not explain what needs to change.

A satisfactory result means users understand the current state, see the next step and can correct input without losing completed fields. Repeat the check on small and large screens, including system accessibility settings.

Mistake: losing connectivity means losing data

Phones move between networks, apps go into the background and the operating system may terminate their process. If the team tested only on stable Wi-Fi, drafts and submissions may behave unpredictably. Not every app must work entirely offline, but every app should explain its limits clearly.

1. Start filling in a ticket, then disconnect the network.
2. Save using the intended method, then restart the app.
3. Check that the agreed fields and attachments were retained.
4. Restore connectivity and wait for confirmation of the data transfer.
5. Repeat with a connection failure after sending, when the outcome is unknown.

Users must be able to see the send queue. If a record conflicts with a change on the server, current data must not be silently overwritten by an older copy. Agree on conflict-resolution rules with the process owner.

Mistake: enforcing permissions only by hiding buttons

If the app hides another person’s ticket from a list but the server returns it on request, access control is incomplete. Another risk is leaving the previous user’s data on a shared device after sign-out.

Create two roles and records with different owners in a test environment. Check lists, search, direct links from notifications and account switching. Ask a developer or security specialist to confirm server-side checks on the same records. Do not test other people’s systems or real accounts without permission.

Separately test denying camera, location or notification access. The app should explain which feature is unavailable and retain other capabilities where the workflow allows it. Request permissions in connection with a clear action instead of asking for everything on first launch.

Use the following standard to define technical checks: OWASP MASVS. Discuss the applicable requirements for storage, authorization, communication and privacy. Citing a standard in a report does not replace a description of the checks performed and the limitations found.

Mistake: treating a success screen as a successful operation

The button responded, but the order never reached the CRM. A notification arrived, but opens a different record. A payment status is unknown and the user tries again. Investigate these problems across the entire chain of systems.

Test payment workflows first in the provider’s designated test environment. Agree separately on testing in production. The client-side screen must not be the sole basis for confirming payment.

Every data exchange needs an owner and a way to find the operation by its identifier. If only the code’s author can investigate a missing ticket, add the necessary diagnostics and support instructions. Related work includes CRM and integration setup.

Mistake: “It works on our phone”

One model does not represent the entire device fleet. Performance depends on memory, data volume, connectivity and the workflow. A test with five records does not validate a catalog with thousands of items, and a clean install does not cover an existing usage history.

Agree on a device matrix based on the audience: supported operating systems, typical screen sizes and a lower-powered device. Test a cold start, a long list, an attachment upload and returning from the background. Record duration, conditions and outcome; compare the same operation after changes.

In the Google Play pre-launch report, expand the issue and select a device. The diagnostic material helps distinguish a crash, a freeze and an interface problem. Give the developer the build number and available details, then retest the fixed version.

Do not improve a metric by removing functionality: hidden photos, disabled synchronization or a missing screen require an assessment of the product impact.

Mistake: testing installation but not upgrades

A new version may work on an empty device yet lose data when upgrading an old installation. The backend must not unexpectedly break older supported versions either: users do not all update at once.

1. Install the previous supported build on a test device.
2. Create the records, drafts and states that must be preserved.
3. Update the app through the normal intended procedure.
4. Check sign-in, data, submissions, notifications and compatibility with the current backend.
5. Agree on failure procedures: pause distribution, issue a fix or disable the affected feature if such a mechanism exists.

Rolling back the backend is not always compatible with data that has already been updated. Test the recovery plan in advance. For iOS, TestFlight lets you distribute builds to groups and collect feedback from testing.

Investigate store rejection against the specific review comment. Compare actual behavior, the description, reviewer access and data disclosures with the App Store Review Guidelines or the chosen store’s rules. Fix the cause, provide an explanation and retest the build. Approval cannot be guaranteed.

Mistake: measuring installs instead of completed tasks

An app can run without crashing and still be unhelpful: users cannot find the action they need, do not understand registration or return to a familiar channel. First ensure analytics events reflect actual outcomes.

Complete one test workflow and compare its event sequence with the backend record. Check repeated taps and failed attempts: they must not automatically increase the success count. Then segment the data by version, device and new or returning users.

If the flow stops at a particular step, observe users and check their circumstances. Changing a button color will not fix a required field whose answer they do not know. Remove the obstacle first, then measure changes in completed actions and support requests.

Do not collect unnecessary form contents in analytics. Research often needs only the event name, version and technical result. Link user acquisition plans to measurable marketing after validating the path to a useful action.

Address the cause and retest the outcome

Collect issues in one register. Distinguish confirmed defects, new requests and questions about requirements. For each item, record its priority, owner, fixed build and retest result.

After a fix, check adjacent features. Changing sign-in can affect notifications, and updating local storage can affect drafts. “Fixed in the code” does not replace testing the delivered build.

Also check readiness for ongoing support: owner access, source code, build instructions, service inventory and responsible people. Another specialist should be able to build and run the project from the documentation. Discuss recovery and further development as part of your mobile app project; costs after release are covered in the budget guide.

What to check before closing an issue

Frequently asked questions about app problems