What is a mobile app audit?

A mobile app audit of your own app is a process that establishes what the shipped build actually contains, collects and sends, independent of the app's documentation. It covers the SDK and library inventory, the runtime data collection and network behaviour, the permissions used, the tracking behaviour and the cryptographic implementation on the wire. It is not a security audit or a compliance audit. It is the owner's version of the same observable-evidence work, applied to the product you ship.

How do I find out what SDKs are in my own app?

Extract the SDK and library inventory from the shipped app bundle directly, rather than relying on your team's documented list. Every mobile app bundle carries evidence of what is inside it: native libraries, embedded frameworks, resource files, and metadata that reveals third-party components. A serious inventory step often surfaces SDKs that no one on the current team remembers adding, plus the fourth-party dependencies those SDKs pull in.

We inherited an app from an agency. What should we check first?

Establish the inventory (what SDKs and libraries are present), the runtime behaviour (what the app actually collects and sends), and the version-over-version history you can reconstruct from previous store releases. That gives you a baseline that does not depend on the previous agency's cooperation. From there, you can decide what needs source-code investigation, what needs a full refactor, and what is fine as it stands.

How do I audit a mobile app without the source code?

Work from the shipped binary. Modern mobile app audit techniques can extract the SDK inventory, map runtime data collection, capture network endpoints and geographies, audit permission use, and identify tracking behaviour, all from the app bundle and its behaviour on a real device. Source code accelerates the audit and answers questions about intent and architecture. Its absence is not a blocker for the majority of what most teams actually need to know.

What data does my app actually send, and how can I check?

The reliable way is dynamic analysis: run the app on a real device, capture the network traffic, identify each endpoint, and record what data is being transmitted and under what conditions. This produces evidence of actual behaviour rather than intended behaviour, which is what regulators, users and your own compliance team ultimately care about.

Is a mobile app audit the same as a security audit?

No. A security audit tests whether the app can withstand attack, typically using frameworks like OWASP MASVS, penetration testing and threat modelling. A mobile app audit of your own app establishes what the app does when it runs normally. The two are complementary, and larger organisations run both.

What does "legacy code" actually mean?

Michael Feathers' working definition, from his 2004 book Working Effectively with Legacy Code, is code without tests. It is not about age. It is about whether the current team has the tools to understand and safely change what is there now. By that definition, code becomes legacy the moment its author leaves without adequate test coverage, whether it was written last decade or last month.

What is bus factor, and why does it matter for mobile apps?

Bus factor is the software engineering term for the number of people who would have to leave a project before it became unmaintainable. A bus factor of one means only one person understands a specific area of the code, and losing that person breaks the team's ability to work on it. Mobile apps concentrate bus-factor risk because specialist areas (rendering, low-power radio, cryptography, hardware-specific tuning) are often understood by a single engineer, and the mobile industry's mobility means those engineers move on.

What is legal debt in a mobile app?

Legal debt is what accumulates when the shipped app drifts away from the legal, contractual and regulatory position the organisation believes it holds. Common examples in mobile: open-source licence contamination from transitive dependencies, privacy policies that no longer match actual data collection, vendor contracts that no longer match how the SDK is being used, regulatory obligations bolted on to a pre-existing codebase (GDPR, ATT, DSA), and accessibility standards drift on legacy UI paths. It is the cousin of tech debt on the compliance side, and it is often invisible until an audit or a regulator surfaces it. Observable-evidence audits find legal debt effectively because they compare what the app actually does against what the paperwork says it does.

Mobile App Audit: What's Really In Your Own App

A mobile app audit of your own app establishes what the shipped build actually contains, collects and sends, independent of documentation. It is not a security audit. It is not a compliance audit. It is not a third-party risk assessment. It is the owner's version of the same evidence work: knowing what is in the app you ship, when the people who built parts of it are no longer available to explain it.

This closes the Appnalysis /insights cluster. The eleven articles before it looked outward: at competitors, at agencies, at vendors and SDKs, at the wider software institutions arriving to hold the industry accountable. This one turns the observable-evidence lens inward. The app you own is a third party to itself, in ways most teams underestimate, and the shipped binary is the source of truth that survives every handover, every departure and every relationship breakdown.

Why teams often do not know their own app

The buyer situation for a mobile app audit is broader than the "we bought this and inherited it" case. Seven inheritance patterns show up repeatedly in practice, and most product owners recognise more than one of them.

Inheritance pattern	What happened	Handover reality	Where the evidence lives now
Agency friendly handover	Agency delivered, moved on to other work	Documented handover, some post-launch support, then silence	Repo, patchy docs, shipped binary
Agency relationship breakdown	Commercial dispute, scope war, acquisition mid-project, or in-housing without notice	Minimum viable handover, sometimes actively obstructive	Sometimes a repo of unknown completeness, always the shipped binary
Contractor-built	Individual contractors delivered pieces of the app	Source handover of variable quality, contractor may or may not be reachable	Repo of uneven state, shipped binary
Historical team	Original engineers have left over time	Institutional knowledge dispersed, documentation drifted	Repo, outdated docs, shipped binary
Acquisition-inherited	Company bought the product mid-life	Transition period ended, key people may have exited	Everything in principle, comprehension of it in practice varies
Bus factor	One person understood a specific area, and they left	Repo intact, but the theory is gone	Repo, and the shipped binary
LLM-generated	Vibe-coded or heavily AI-assisted development	Code shipped, no human owns the internals line by line	Repo, and the shipped binary

The common thread across all seven is not that documentation is bad, though it often is. It is that the shipped binary is the artefact that always remains. It is what users experience, what regulators can inspect, and what a serious audit can work from even when nothing else survives.

For the acquisition case specifically, Technical Due Diligence for Mobile Apps covers the pre-transaction assessment that sits alongside legal and financial due diligence. This article is the everyday-ownership version of the same evidence work, applied after the deal or without a deal being involved.

The 90/10 pattern, from hand-tuned assembly to LLM-generated prototypes

Software has always had a specialist minority. Most application code is written at whatever the productive abstraction of the day happens to be, and a small percentage is hand-crafted for reasons the abstraction cannot address.

In the 1990s and early 2000s, high-level languages (C, C++, Java) covered the 90% of general application code. The 10% that did not was hand-tuned assembly: graphics inner loops, DSP routines, game engine primitives, embedded firmware timing paths, and CPU-specific instructions (MMX, SSE, AltiVec) the compiler could not yet emit. Further back, FORTRAN with assembly hot loops served the same shape for scientific computing.

The pattern continues in modern form. SIMD intrinsics in performance libraries. Hand-tuned CUDA kernels. Cryptographic primitives written and reviewed at instruction level for constant-time guarantees. Safety-critical automotive and medical code. Mobile has its own version, covered below in the FAQ.

Vibe-coded and heavily AI-assisted development is the same shape at a new abstraction layer. Most application code becomes LLM-generated. The 10% that does not, where correctness, performance, safety, licensing, cryptographic strength or a specific hardware paradigm matters, remains hand-crafted or heavily reviewed by someone who can read what the LLM produced at that level of scrutiny. The abstraction shifts. The specialist minority does not disappear.

What does change is the ownership of understanding. Peter Naur's 1985 paper "Programming as Theory Building" argued that a program is not just its source code. It is the theory in the developer's head about how the code works and why it is shaped the way it is. When the developer leaves, the theory dies. The code still runs. The ability to change it safely goes with the person.

Vibe-coded code makes the same point more starkly. If no human wrote it line by line, no human holds the theory of it either, even at the moment it ships. The shipped binary is what remains, more clearly than ever. For the fuller pattern of why this changes what agencies and teams need to check, The Vibe-Coded App: Here's What You Actually Shipped covers the vibe-coded angle directly.

When knowledge concentrates in one person

The bus factor is the software engineering shorthand for the risk that concentrates when one person is the only one who understands a given piece of the system. A bus factor of one means the loss of one person breaks the team's ability to work on that area.

One compliance manager at an insurance company described a piece of software where only one person in the organisation understood what it did. When that person left, the software continued to run. It continued to be relied on. But every subsequent question about what it did, whether it was still compliant, whether it could be safely changed, had no confident answer.

Michael Feathers' 2004 book Working Effectively with Legacy Code offered a working definition that has held up: legacy code is code without tests. It is not about age. It is about the tools you have to understand and safely change what you have now. By that definition, a lot of code becomes legacy the moment its author leaves, whether it was written last decade or last month.

A mobile app audit of your own app is the direct counter to this specific failure mode. It does not restore the departed person's theory of the code. It does establish what the code actually does when it runs, which is often the answer the compliance manager, the QA team or the next engineer really needs.

two-column comparison of what a mobile app audit can establish from the shipped build alone versus what still requires source code or original team knowledge

What a mobile app audit can and cannot tell you from the shipped build

Honest limits matter here. Observable evidence from the shipped app answers many questions. It does not answer all of them.

Assessment area	From the shipped build alone	Still needs source or original team
SDK and library inventory	Yes, extracted from the app bundle	Not required
Runtime data collection	Yes, captured on a real device	Not required
Network endpoints and geographies	Yes, from network traffic capture	Not required
Permissions used and when triggered	Yes, from runtime observation	Not required
Tracking and identifier behaviour	Yes, from runtime observation	Not required
Cryptographic implementation on the wire	Yes, from network capture	Deeper crypto review needs source
Licence compliance surface	Largely yes, from component fingerprinting	Full audit of contamination needs source
Intent behind bespoke business logic	No	Yes, source and preferably the author
Architectural rationale	No	Yes, source and preferably the author
Historical decisions and trade-offs	No	Yes, original team knowledge
Developer's theory of the system	No	Yes, per Naur (1985)

The practical implication is that a mobile app audit produces an evidence base that closes most of the "what is happening in this app" questions without needing source access. Where source access is available, it accelerates the audit. Where it is not, the audit still produces a defensible answer to the majority of questions a product owner, compliance manager or incoming engineering team actually asks. This is a distinct category from a code audit or a source code audit, which start from the repo.

A five-step mobile app audit process

The process runs the same way whether the app is agency-built, contractor-built, historical, acquired, LLM-generated, or a mix of all five.

Inventory the shipped binary. Extract the SDK and library inventory from the app bundle. Identify third-party components, their versions, and the fourth-party dependencies they pull in. This is often the first surprise.
Map runtime behaviour. Capture what the app collects, which network endpoints it contacts, which permissions it requests and when, and how it uses device identifiers. This is the observable-evidence layer applied to your own product.
Compare against your public claims. Your privacy policy, your store listing, your marketing, your compliance attestations. Where the shipped behaviour matches, the claims are defensible. Where it does not, the gap is the finding, and it is better that you find it than a regulator or a journalist does.
Check platform and sector compliance. Apple's App Store review requirements, Google Play's Data Safety declarations, and whatever sector rules apply (GDPR, HIPAA, PCI, FCA operational resilience, DTAC, KCSIE). Verify the actual behaviour against the actual rules.
Establish a baseline for change tracking. The audit is more valuable as a starting point than as a one-off exercise. Once you have a baseline, every subsequent release can be compared against it, and the "what changed?" question becomes answerable.

For the underlying evidence layer this process runs on, What Is Product Intelligence for Mobile Apps covers the wider observable-evidence work this audit is one application of.

Handover to QA and compliance: black box or full disclosure?

A related question, often unasked until an audit forces it: should the QA team and the compliance team know exactly what is inside the build, or should they treat it as a black box?

Both positions have valid defence. Black-box QA is often better than full-disclosure QA because it tests what the user actually experiences, not what the developer intended. If the user sees the wrong screen, it does not help that the code intended the right one. Black-box compliance is often required because the compliance duty attaches to the shipped artefact, not to the intent behind it. A regulator inspecting the app sees what it does, not what the team meant it to do.

Full disclosure matters more in specific cases: safety-critical software where sign-off requires known provenance, regulated sectors where the compliance regime demands documented lineage, and situations where the QA or compliance team needs to design tests that a black-box view cannot generate.

The practical answer for most product teams is not either-or. The QA team benefits from a black-box test discipline supported by an evidence baseline they can trust. The compliance team benefits from a shipped-behaviour evidence base that they can defend to a regulator, alongside a documented account of intent from the developers. A mobile app audit produces the evidence artefact that makes both handovers work without requiring either team to reverse-engineer the code themselves.

Tech debt, legal debt, and the refactor-or-remediate decision

An audit of your own app almost always surfaces two categories of finding: tech debt and legal debt. Tech debt (or, spelled out, technical debt) is Ward Cunningham's 1992 metaphor for the interest paid on shortcuts taken in code. Legal debt is the less-established sibling, and often the more urgent finding: what accumulates when the shipped app drifts away from the legal, contractual and regulatory position the organisation thinks it holds. Both accumulate quietly, and most inheritance patterns produce both. A software audit, in the sense that legal and licensing teams use the term, covers a specific slice of this: which open-source and commercial components are present and under which licences. A mobile app audit is broader and includes the same evidence.

The observable-evidence layer is well suited to finding legal debt in particular, because legal debt is about what the app actually does versus what the paperwork says it does. That is the gap a shipped-binary audit is designed to close. For the operational side of remediating compliance drift once the audit surfaces it, Compliance Automation Software for Mobile Apps covers the continuous-compliance layer.

Findings from either category feed into a three-way decision. An audit is enough when the shipped code works, meets its requirements, and the primary problem is that no one on the current team confidently understands it. Targeted remediation is enough when the audit surfaces specific items that can be fixed in place. Legacy application modernization, in the sense of a full rebuild or re-platforming, is genuinely required when the code has architectural problems that block business needs, when the tech stack is at end-of-life, or when accumulated debt of either category can only be addressed structurally. Before any legacy application modernization, a mobile app audit establishes what you actually have to work with. An application modernization assessment often starts with the audit and then decides which of these three responses fits each finding.

For the deeper security-focused version of this work, a source code audit remains the right instrument. It sits alongside the shipped-binary audit rather than replacing it. The audit-of-shipped-behaviour is often the cheaper and faster first step, and sometimes it is the answer on its own. Legal debt as its own subject warrants deeper treatment than a section here can give it, and is worth a dedicated future piece.

version-over-version behaviour delta diagram for a mobile app audit, showing how baseline evidence enables what-changed questions across subsequent releases

Where audit-of-your-own-app fits with the other audits

For the avoidance of confusion, an audit-of-your-own-app is a distinct exercise from several other things called audits in mobile software.

It is not a security audit. Security audits (OWASP MASVS, penetration testing, threat modelling) test whether the app can withstand attack. A mobile app audit of your own app establishes what it does. The two are complementary.

It is not a compliance audit. Compliance audits verify against a specific regulatory framework. Compliance Automation Software for Mobile Apps covers the continuous-compliance work that runs on the evidence a shipped-behaviour audit produces.

It is not a third-party risk assessment. That looks at the vendors and SDKs inside your app as external risks. Third-Party Risk Management for Mobile Apps covers the outward-facing version of the work this article's process is the inward-facing counterpart to.

It is not technical due diligence. That is a pre-transaction exercise for acquisitions. Technical Due Diligence for Mobile Apps covers the deal-time version of similar work.

The audit-of-your-own-app is the everyday ownership version, applied to your live product on your normal release cadence, without a specific external trigger.

How Appnalysis fits

Appnalysis produces the observable-evidence layer that a mobile app audit of your own app needs. The SDK inventory, the runtime behaviour, the network and permission profile, the cryptographic surface, and the version-over-version delta across releases.

For an in-house product team, this is the evidence base that answers the questions the departed engineers, the completed agency contract, the acquired product line and the vibe-coded prototype leave unanswered. For an agency inheriting a client's app to work on, or a new engineering team taking over from a previous one, it is the starting point that replaces guesswork. For a compliance or QA team, it is the artefact that makes their handover workable without requiring them to reverse-engineer the code.

What it does not replace is the engineering team's judgment about what to change, the architectural work of deciding whether to refactor, or the specialist review of the 10% of hand-crafted code where the intent still matters as much as the observable behaviour. The evidence layer supports those decisions. The decisions still belong to the people making them.

The /product and /agencies pages cover how the platform is used by in-house teams and by agencies respectively.

Closing

The shipped binary is the source of truth. It survives every handover, every departure, every relationship breakdown and every abstraction shift from hand-written to LLM-generated. Knowing what is in the app you own is not an extra step. It is the ownership itself.

Every article in this cluster comes back to the same observable-evidence thesis. The competitor analysis version, the compliance version, the vendor risk version, the agency pitch version, the institutional version, the product intelligence version. This final piece applies the same thesis to the case that is often invisible until it is urgent: the app you own that you do not fully understand, and the audit that lets you understand it without waiting for the crisis to force the question.