What a mobile app audit actually checks (with a real example)

When people hear “audit” they picture a checklist and a pass or fail stamp. That is not what this is. A mobile app audit is a senior engineer reading your actual code and using your actual app, then writing down what is strong, what is risky, what it is costing you, and what to do about it in order.

I score every audit across five lenses. Here is what each one means and what I am looking for, with real findings from a public audit I did on Wikipedia’s iOS app so you can see the shape of it.

Architecture

This is about how the app is put together. Are responsibilities split in a way that lets people work without stepping on each other, or is everything tangled so that one change ripples everywhere?

In the Wikipedia app, the five most important screens were each a single class of 1,500 to 2,600 lines. When a screen gets that big, every change becomes a search problem and no one can hold the whole thing in their head. That is a concrete architecture cost, not a style opinion.

Code quality

This is the day to day readability and safety of the code. Clear names, small functions, sensible patterns, and the absence of traps that bite you later.

I am only looking at what the code shows me, so I count real things. Duplicated logic, dead code, places where the app makes assumptions that will not always hold. I do not guess at intent. I report what is there.

Performance

This is why the app feels slow, and where. Slow launches, janky scrolling, work happening on the main thread that should not be, memory that grows until the app is killed.

Performance problems are usually caused by a small number of decisions doing most of the damage. The value of the audit is telling you which few, so you fix the ones that matter and skip the ones that do not.

Stability

This is what makes the app crash or lose data, and how well it recovers when something goes wrong.

In the Wikipedia app I found 144 places where the code chooses to crash on purpose instead of recovering. Most of those were safe compiler boilerplate, and I said so plainly in the report, because an honest audit separates the scary looking count from the real risk. A handful were real crash decisions in shipping code paths, and those are the ones worth acting on.

Delivery pipeline

This is everything between a finished change and a release in your users’ hands. The build, the tests, the automation, the release process.

Not every finding is bad news. The Wikipedia app had one of the best continuous integration setups I have seen, and their Swift 6 migration was managed better than most commercial teams manage theirs. I put that in the report too. You want to know your strengths as much as your risks, so you do not spend money fixing something that already works.

What you get at the end

The report gives every lens a score out of 10 with the reasons for it, then a single overall score. Wikipedia came out at 6.6, which I would describe as a mature codebase with concentrated risk that is fixable.

Then comes the part that actually saves you money: a prioritized fix plan. Not a wish list. An ordered set of changes, each with an estimated effort, sorted so the highest pain for the lowest cost comes first. Your own team can pick it up and start on Monday. There is no lock-in.

The audit is a fixed price of €790 and takes one to two weeks. You can read the full nine page Wikipedia report on the audit page. It is the exact format you would get for your app.

If your app is slow, crashing, or expensive to change, an audit is the cheapest way to find out why before you spend real money on the fix.