A mobile app audit answers one plain question: what state is the app really in, and what should be fixed first? It usually comes up at a moment of change: a team leaving, a new supplier taking over, a funding round, an update the stores reject, or an app that crashes more and more without anyone knowing why.
Here is what I check, in the order I check it.
1. Does the app still build?
The first test tells you more than it seems: take the code onto a clean machine and produce a build. If that needs half a day of help, settings only a former developer knew about, or an Xcode version nobody can find, that is already a finding. An app you cannot rebuild is an app you cannot fix quickly.
2. Architecture and dependencies
- How the app is split up, and which parts will fight you at the next feature.
- Abandoned libraries with no version that works on current iOS or Android.
- Duplicated libraries doing the same job in two places.
- Dead code, and the areas nobody dares to touch any more.
The point is not to judge coding style, but to find what will make the next change expensive.
3. Stability
I start from your own crash data, in Firebase Crashlytics, Xcode Organizer or the Play Console. The questions are concrete:
- which crashes hit the most users;
- on which devices and system versions;
- what they mean in the code, and whether they share a cause.
A handful of causes often explains most of the crashes. Finding them is usually the best value fix in the report.
4. Performance
- Cold start: the time from tapping the icon to a usable screen.
- Screens that stutter, long lists in particular.
- Memory that keeps growing as the app is used.
- The network and battery cost of the app in normal use.
5. Security and data
The app side, not a penetration test: that is a different job. I look at:
- where keys, tokens and secrets live, and whether any sit in the code;
- how data is stored on the phone and sent to the server;
- sign-in, sessions and when they expire;
- the permissions the app asks for, and whether each one is still needed;
- the personal data the app actually collects, against what it declares.
6. Store compliance
This is often where the urgent item hides. I check whether builds still meet Apple's and Google's current requirements: the targeted Android version, the SDK used for iOS, privacy declarations, and anything that would block the next release. In 2026 two deadlines have already changed the picture: Xcode 26 for the App Store and API 36 for Google Play.
7. Release pipeline
- Who can ship a release today, and with which access.
- Signing certificates and keys: where they are, and who owns them.
- Tests, where they matter.
- How long it really takes to ship a fix, from commit to the app on the store.
What you get
A ranked report: every finding with its impact and the effort to fix it, ordered so you can stop reading once the budget runs out. Then a one-hour call to walk through it with your team.
I do not fix anything during the audit, so the report stays honest. Fixes are a separate piece of work, with your team or with me.
What to have ready
- Read access to the repository and to any build configuration.
- Read access to App Store Connect and the Play Console, or exports of the crash and release data.
- One person who can answer product questions during the week.
With that in place, five days is enough for native iOS and Android apps, and for Kotlin Multiplatform and Flutter apps too.
If you want an audit
The day-by-day plan and the terms are on the Mobile App Health Check page. The price is fixed, agreed after a 20-minute call and before anything starts. If your app does not need an audit, I will tell you on the call.