Mobile App Audit: UX, Technical and Security Review

Use a mobile app audit to decide what to fix, keep or rebuild based on evidence you can observe. Before committing to a redesign, examine how users complete their tasks, how reliably the app works, who can access the data and what your team needs to maintain it. Ask for a list of findings you can verify, each with a priority, an owner and a test to confirm the fix.

A collection of annotated screenshots is not enough if nobody can reproduce the problems. Equally, a code review alone cannot answer the business question: can users complete their task? Use this framework to bring both perspectives together while keeping a product audit, security testing and legal advice distinct.

Decide what question your audit needs to answer

Start with a specific question: should you fix the existing app, rework a user flow or replace a dependency that has become difficult to maintain? Record the symptom, who it affects and what information you still need. Do not assume that you already need a complete rebuild.

For example, users might abandon a form because they do not understand the final button, cannot save their entries or cannot find the result afterwards. You may see the same outward sign in each case. Yet you need different checks and fixes to address each problem.

Define the scope as well: the app version, platforms, devices, test accounts, server environment and user flows you will examine. Keep each finding tied to that scope. A finding does not prove that users encounter the same problem across every version or that it affects everyone.

Copy this audit checklist

Area	Question to check	Evidence to keep	Possible decision
Core user flow	Can the user complete their task and understand the result?	Test scenario, recording and final state	Clarify a step or fix a blocker
Reliability	What happens after a network outage or an interruption?	Steps to reproduce the issue, relevant logs and version details	Fix how users resume their work or how the app stores it
Access	Can users in each role access only the functions intended for them?	Test accounts and server-side authorisation checks	Review access permissions
Data	Does the data processing you observe match the explanations users receive?	Data inventory, processing purposes and permission request flows	Clarify, limit or investigate the processing
Accessibility	Can users still complete the flow with the settings and assistive technologies you are testing?	Device, settings, screen reader and barriers encountered	Fix labels, focus behaviour or presentation
Maintenance	Can someone else build and operate the product?	Authorised access, documented procedure and an attempt to build the app	Complete the handover or isolate a dependency

Keep one row per problem. Do not write “redo the UX”: describe what triggers the problem, what the user observes and what should happen instead. With that level of detail, you can later check whether the fix addresses the original problem.

Limit access and make the test conditions reproducible

Use test accounts that match the roles you plan to examine. Prefer fictional data or data you have prepared for the exercise whenever you can reproduce the behaviour that way. Do not share production credentials in a shared document. Define who receives access, how long they need it and how you will revoke it.

Gather the available code and documentation, released versions, priority user flows and known incidents. Record missing documentation as a maintenance finding in its own right; do not invent explanations for how the product works. If you cannot check server-side behaviour, mark that point as unverified.

To prepare what you will hand over to your provider, use the app handover audit (French). Alongside your functional review, use it to check accounts, source code and operational requirements.

Follow a complete user flow before counting screens

Choose a common task and follow it from the starting point through to the result. Test the normal case, a permission refusal, incomplete input and a relevant interruption. Record the messages users see, their options for going back and how they find their work again.

You can then compare your observations with the tests to run before accepting a mobile app release. Use this audit to diagnose an existing product and decide what work it needs. Use the acceptance testing checklist to check a version before you accept it. The two documents serve different purposes.

A fictional example of a finding you can act on

Imagine a field service tracking app called AtelierNord. A technician starts a report, loses their network connection and then closes the app. When they reopen it, they can no longer see the report. This example is fictional and does not describe any client engagement.

Field	Example entry
Trigger	Create a test report, disconnect from the network, then close and reopen the app
Observation	The technician cannot see the report in the local list
Uncertainty	The technician's inability to see the report does not yet prove that the app has deleted the stored data
Next check	Examine local data storage with the technical team and reproduce the scenario
Acceptance criterion for the fix	The technician can find the draft and see its synchronisation status after reopening the app
Evidence that the fix works	Record the same scenario on the corrected version and carry out the associated technical check

By writing the finding this way, you separate the symptom, the hypothesis and the evidence. You avoid immediately commissioning a new app when a targeted fix may be enough. You also avoid declaring the problem solved after changing only the wording.

Assess security, data protection and usability separately

Use OWASP MASVS to structure your mobile app security requirements. It provides a framework for checks, not automatic security certification. For a specialist assessment, agree on the relevant checks and the evidence you expect with a qualified professional.

In France, you can use the CNIL's recommendations on mobile applications to examine responsibilities and data protection. Granting a technical permission on a phone does not, by itself, establish a legal basis for processing. Ask the appropriate responsible specialists to review the processing activities and the obligations that apply.

For usability, check labels, contrast, navigation order and the assistive technologies the app actually supports. Use the W3C's WCAG as accessibility references for web content. Do not claim full accessibility compliance for a native app on the basis of a partial check.

Prioritise fixes by their observable impact

Address blockers in the essential user flow, confirmed loss of work and access problems that require intervention first. Then document recurring difficulties and opportunities to help users understand what to do. Do not judge a problem's importance by how large or prominent the affected screen looks.

For each fix, name an owner and specify the scenario that must pass. If a dependency prevents you from making the change, describe it. When several fixes affect the same part of the product, compare targeted rework with a broader redesign using the actual constraints. Do not claim a quantified benefit you have not measured.

Turn your findings into a clear scope of work

Once you have gathered the evidence, group fixes by user flow and distinguish essential work from changes that can wait. Use the mobile app requirements document to translate your decisions into acceptance criteria.

Bring Doved Studio one priority user flow, a finding someone else can reproduce and the constraints of your existing app. We bring together product scoping, design and development to define the work you need. Start by preparing that finding record so you can discuss a concrete problem instead of making a general request to “modernise” the app.

Frequently asked questions

Will an audit mean rebuilding the entire app?

No. You should use it to compare your options. You may solve the problem with a fix, a reworked user flow or better maintenance without a complete rebuild.

Can we start without access to the code?

You can examine the user flows you can see and document findings that others can reproduce. You will have limited grounds for conclusions about the architecture, server access or data storage until you have the necessary evidence.

What should we ask the auditor to deliver?

Ask for the scope, observations, evidence, uncertainties, priorities and tests to confirm each fix. You will find it harder to make decisions from a list of recommendations that nobody has linked to specific findings.

When should we repeat the checks?

Run the scenarios again after fixes and after any significant change to the user flow or its dependencies. Keep a record of the version you tested so you do not treat validation of an earlier version as validation of a new release.