How much does an iOS code audit cost?

An iOS code audit is scoped around the codebase and the decision it needs to support. A focused review, a full architecture assessment and a review of a large regulated app involve different amounts of work, so I agree the scope with you before preparing a proposal.

This guide explains what affects that scope, what a useful report should include and how to compare proposals. For your app, start by sharing its size, whether it builds and the decision you need to make.

Typical scope bands

Most audits fall into one of four shapes.

A focused question, or a small MVP. One specific concern — “is this safe to ship?”, “why is our release process so painful?”, “is this codebase maintainable by the team we are about to hire?” — or a small app of a few thousand lines. Usually two to three consulting days.

A standard production audit. A real, shipping app with a handful of modules, a backend, some third-party dependencies and real users. Architecture, code quality, concurrency, dependencies, testing, delivery and production evidence. Commonly five to eight consulting days.

A large, regulated or multi-module codebase. Several packages, a mixed Swift and Objective-C history, a substantial dependency surface, or compliance-sensitive data handling. Scoped individually around the systems and risks involved.

Audit plus remediation. The audit as above, followed by implementation work. These should be quoted and contracted separately, for reasons covered further down.

What drives the cost

Two apps of the same line count can differ by a factor of three. The variables that matter most:

Size and age. Not just lines of code but how many years of accumulated decisions are in there, and how many different people made them.

Number of targets and modules. Each one adds surface area and interfaces to understand.

How hard the app is to build. A project that builds from a clean checkout in twenty minutes costs materially less to audit than one that takes two days to get running. If the build is genuinely broken, that recovery is usually separated out and time-boxed rather than absorbed silently into the audit price.

The Objective-C and Swift mix. Interop boundaries, nullability and legacy patterns take longer to read carefully.

Backend and SDK surface. How much of the risk lives outside the app, and how much of it the audit is expected to reach.

Available production evidence. Access to crash reporting, performance data and analytics makes findings sharper and the work faster. No instrumentation means more time spent inferring.

Required security depth. A code-level review of data handling is part of a normal audit. Anything deeper is a different engagement.

Documentation quality. A README, a runbook and some architecture notes can save a day on their own.

Urgency. Compressed timelines cost more, as they do in any professional service.

What a useful audit actually includes

If a proposal does not describe most of this, be cautious about the price regardless of what it is.

• A context interview, so that findings are tied to your product and roadmap rather than to a generic standard.
• A reproducible build on the auditor’s own machine.
• Direct review of the source, not just tooling output.
• Review of production evidence where it exists.
• An executive summary a non-iOS decision-maker can act on.
• A risk-ranked technical report with evidence for each finding.
• A roadmap that sequences the work: fix now, plan next, monitor, leave alone.
• A debrief call and a window for follow-up questions.

What is normally excluded

Being clear about exclusions is a sign of a good proposal, not a weak one.

A code audit is not a penetration test. It is not a legal or regulatory compliance certification. It is not an exhaustive line-by-line review of every file, which for most codebases would be neither affordable nor useful. It cannot guarantee the absence of defects. And it does not include remediation unless that has been separately agreed.

If a proposal implies otherwise, that is worth questioning closely, particularly if the report is going in front of an investor, an acquirer or a board.

Fixed price or day rate?

Fixed price suits a defined audit. When the scope can be described precisely and the code builds, a fixed price gives you certainty and puts the estimation risk on the person best placed to carry it.

Time-boxing suits unknowns. When the code will not build, when access is partial, or when the question itself is exploratory, a time-boxed engagement with an explicit checkpoint is more honest than a fixed price padded to cover the uncertainty.

The important thing is to agree in advance what happens if the app will not build. A good proposal says so explicitly: either the recovery is inside the scope up to a stated limit, or it is a separate first phase with its own checkpoint. Discovering that ambiguity halfway through is unpleasant for everyone.

How to compare proposals

Price is the easiest thing to compare and the least informative. These questions separate proposals more usefully:

Who is actually doing the work? Ask for the name and background of the person reading the code. In some organisations the person who sells the audit is not the person who performs it, and the difference in outcome is substantial.

Will you have direct access to them? Being able to ask the reviewer a question during the work is worth a great deal.

What relevant native iOS work have they done? Auditing a native iOS app requires having built and shipped native iOS apps. Cross-platform or general software experience is not a substitute for knowing how StoreKit fails, what App Review rejects, or why a particular concurrency pattern crashes only on older devices.

What standard of evidence will findings meet? “The architecture is poor” is not a finding. “This shared cache is written from three queues without synchronisation, which matches the crash cluster in the report attached” is.

Who owns the deliverable? You should own the report outright and be free to share it with your team, your investors or another supplier.

What are the confidentiality terms? A mutual NDA before access is normal and should not be difficult.

Is there a sales bias? If the same party wants to sell you the remediation, the audit’s independence is compromised. Keeping the two contracts separate protects the value of the findings.

When an audit pays for itself

An audit is a cheap way to de-risk an expensive decision. It tends to pay for itself when:

• You are acquiring a company, or taking over an app from a supplier.
• A new CTO or engineering lead has just arrived and needs an independent picture.
• A significant migration or rebuild is being considered.
• Delivery has slowed and nobody can articulate why.
• An AI-generated MVP is approaching launch. That is a specific enough case that I have written about whether AI-generated Swift is safe to ship separately.
• There is a dispute with a supplier and you need an independent technical view.

In each of those, the sum at stake is usually an order of magnitude larger than the audit.

Discussing your audit

My iOS Code & Architecture Audit page sets out what the work covers and what you receive. Telling me the codebase size, whether it builds and what decision is waiting on the answer is enough to start a conversation about scope. If you are still working out what you have inherited, the framework in how to assess an inherited iOS codebase covers what a thorough assessment should examine.