Code Audit · May 2026 · 8 min read

What an App Code Audit Actually Looks For

The six areas a real audit covers, when to commission one, and what the report should tell you.

A code audit is not a bug hunt. Bugs are the problems you already know about. An audit is for the ones you do not: the structural decisions that work fine at your current size and stop working at the next one.

Here is what a serious audit covers, when it is worth commissioning, and what you should expect to get back.

When an audit is worth doing

Most of the time, you do not need one. There are four situations where skipping it is a false economy.

You are inheriting a codebase - from an agency, a contractor, or a departing developer - and need to know what you actually own.
Something is wrong and nobody can say why. Intermittent crashes, slow screens under load, behaviour that differs across devices.
Diligence is coming. An investor, an acquirer or an enterprise customer is about to look at your technical setup.
You are about to spend significantly on new features and want to know whether the foundation will take them.

The common thread is that the cost of being wrong is about to rise. An audit is cheapest exactly when it is least urgent.

The six areas a real audit covers

1. Security and data handling

Where do credentials live, and are any of them in the repository? How are tokens stored on the device, and what happens when one expires? Is authorisation enforced on the server, or only hidden in the UI? Is anything sensitive being logged?

The most common serious finding is not an exotic vulnerability. It is an API that trusts the client - endpoints that return data the logged-in user should not be able to see, because the check only ever happened on the screen.

2. Architecture and structure

Does the code have a shape someone new could learn, or does every change require knowing the whole thing? Is business logic separated from the UI, or scattered through view code where it cannot be tested or reused?

The practical question an auditor is answering: if you hired two engineers tomorrow, how long before they could ship safely? When the answer is months, that is a finding, even if nothing is currently broken.

3. Dependencies

Every third-party package is a bet on someone else's maintenance. An audit checks which are unmaintained, which are pinned to versions with known vulnerabilities, and which are doing something load-bearing that would be painful to replace.

Particularly worth flagging: dependencies that are a single maintainer away from being abandoned, sitting in a critical path like payments or authentication.

4. Performance under real conditions

Not "is it fast on a new phone on office wifi". Where are the queries that get slower as data grows? What happens on a mid-range Android device on a poor connection? Are there memory leaks that only appear after twenty minutes of use?

Performance problems are usually architectural. A screen that fetches everything and filters on the device is fine with a hundred records and unusable with fifty thousand.

5. Tests, builds and release process

Is there a test suite, does it run automatically, and does anyone look at it? Can a new engineer build and release the app from a clean machine using written instructions, or does it only work on one laptop?

A build process that lives in one person's head is a genuine business risk, and one of the easier findings to act on.

6. Store and platform compliance

Permissions requested but never used, privacy declarations that do not match what the app actually collects, deprecated APIs with a deadline attached, missing account-deletion flows. These are the findings that turn into a rejected release at the worst possible moment.

What the report should look like

A useful audit ends with decisions, not a list. Every finding should carry three things: what it is, what it costs you if nothing changes, and what fixing it involves.

Severity	What it means	What to do
Critical	Actively exposing data, losing users, or blocking release	Fix before shipping anything else
High	Will cause a serious problem at the next growth step or milestone	Schedule deliberately, within weeks
Medium	Slows the team down and compounds quietly	Fold into normal feature work
Low	Worth knowing, not worth stopping for	Note and move on

Be sceptical of a report that grades everything as critical. That usually means the findings were generated by a tool rather than judged by an engineer, and it makes the report useless for prioritising - which was the entire point.

You should also expect an honest answer to the uncomfortable question: is this worth repairing, or would rebuilding the weak part cost less than maintaining it? Sometimes the answer is rebuild, and a report that will not say so is not serving you.

If you want a read on a codebase you have inherited or are worried about, that is exactly what our audit and takeover service.

Frequently asked questions

How long does an app code audit take?

For a typical mobile app, a focused audit is a matter of days rather than weeks - enough time to build and run the app, read the critical paths, check dependencies and write up findings. Very large or unusually tangled codebases take longer, and a good auditor will tell you that after an initial look rather than committing blind.

What do you need to run an audit on my app?

Read access to the repository, whatever build and environment setup exists, and ideally the ability to run the app against a non-production environment. Access to crash reporting and analytics helps, because it shows what is failing for real users rather than what looks fragile on paper.

Is a code audit the same as a security audit?

No. Security is one part of a code audit, alongside architecture, dependencies, performance, tests and platform compliance. A dedicated security audit or penetration test goes far deeper on threat modelling and active exploitation. If your primary concern is regulatory or a specific compliance requirement, you likely want both.

Should I audit an app before buying or investing in it?

Yes, and it is one of the highest-value times to do it. The things that change a valuation - an unmaintainable architecture, a dependency on one departing engineer, undisclosed data handling - are not visible in a demo. An audit before the deal closes is considerably cheaper than discovering them afterwards.

What if the audit says the app should be rebuilt?

That is a legitimate outcome, and a good report will show its reasoning rather than just asserting it. Usually the honest answer is partial: a specific subsystem is beyond economic repair while the rest is fine. A rebuild recommendation should always come with what it would cost to maintain the current version instead, so you can compare.

View All