Mobile App Audit Checklist: What to Check Before a Redesign or Rebuild

When a full app audit is worth doing

An audit is useful before a redesign, a major feature expansion, a change of development partner, an acquisition or a rebuild estimate. It is also sensible when product metrics and customer complaints contradict each other. A healthy store rating does not prove that payment reconciliation works, while a noisy support inbox does not automatically mean the codebase must be replaced.

Define the decision and the time horizon first. A founder preparing a six-week rescue release needs a different level of detail from a buyer evaluating a platform for the next three years. Agree which apps, markets, user roles, backend services and release versions are in scope. Otherwise the audit grows into an open-ended exploration.

Start with questions, evidence and access

Before opening the repository, ask the product owner to name the three outcomes the app must produce. Then collect the evidence needed to test those claims: store listings, analytics, crash reports, support tickets, release notes, design files, repositories, API documentation and access to staging.

Use a dedicated access register. It should show who owns Apple and Google developer accounts, cloud infrastructure, domain names, source control, analytics, push notifications, payment providers and signing credentials. Missing ownership is not an administrative footnote. It can block a release or make a takeover impossible. Our app documentation and handover guide explains what a receiving team should obtain.

Audit the product before the interface

Map the current promise to observable behaviour. Who is the primary user? What useful result should they reach in the first session? Which transaction funds the product? A marketplace may depend on supplier fulfilment rather than the prettiness of buyer onboarding. A course app may have an elegant catalogue but lose customers when video progress is not saved.

Review support tickets, store reviews, cancellation reasons and sales objections together. Group them by journey and consequence instead of counting keywords. Ten complaints about a decorative detail may matter less than two reports of lost medical records or failed payouts. Note where evidence is absent; uncertainty itself belongs in the report.

Test critical journeys on real devices

Choose five to eight journeys that represent value and risk. Test clean installation, returning sessions, weak connectivity, denied permissions, expired sessions and interrupted payments. Use at least one smaller device and the oldest supported operating-system version. A happy-path walkthrough on a recent flagship phone is not an audit.

Record the starting state, action, expected result, actual result and evidence. Video is especially useful for intermittent issues. Separate usability friction from defects: a confusing label needs a design response; an order duplicated after a retry needs product, backend and payment investigation.

Accessibility belongs inside these journeys. Check text scaling, contrast, focus order, screen-reader labels, target sizes, motion and error messages. A native mobile accessibility audit should include assistive-technology testing, not only an automated scan. Accessible.org's mobile audit overview describes why manual checks remain necessary.

Verify analytics before trusting the funnel

Analytics can make a broken journey look healthy when events are missing, duplicated or fired at the wrong moment. Compare the event dictionary with the implementation. Run a known test account through onboarding, purchase or booking and verify each event and parameter. Reconcile completed transactions with the backend or payment provider.

Check that development traffic is separated, app versions are available, consent is respected and iOS and Android use the same definitions. If measurement is unreliable, label funnel conclusions as provisional and repair instrumentation first. The mobile app analytics setup guide gives a practical measurement baseline.

Measure stability and performance in context

Look beyond a single crash count. Segment by app version, device, operating system, market and journey. Android Vitals reports user-perceived crash and ANR rates and highlights bad behaviour that can affect discoverability on Google Play. The Android Vitals documentation explains its core and per-device metrics.

On Apple platforms, review App Store Connect App Analytics for acquisition, engagement and performance signals. Apple's analytics overview shows the available product-page and app metrics. Crash tools should also be checked for coverage: Firebase explains why crash-free users and crash-free sessions answer different questions in its Crashlytics metrics guide.

Add practical timing tests for launch, login, search, checkout, upload and sync. Include poor network conditions and a larger account. A median response can look acceptable while a small but valuable group waits ten seconds or loses work.

Inspect code, backend and data as one system

The code review should identify change risk rather than reward a particular framework. Inspect module boundaries, dependency age, duplicated business rules, test coverage, error handling, secrets, environment configuration and build reproducibility. Run the app from a clean machine if possible. A repository that only one developer can build is an operational risk.

Trace two or three critical journeys across mobile code, API, database and third-party services. Confirm where validation happens, how retries and idempotency work, what is cached, and how schema changes are deployed. Review logs and alerting against real incidents. A polished mobile layer cannot compensate for an API that silently creates duplicate orders.

Data needs its own questions: what is collected, where it is stored, how long it remains, who can export or delete it, and how migrations are tested. For sensitive products, involve security and legal specialists. The broad audit can reveal that a dedicated penetration test, privacy review or compliance assessment is required; it should not pretend to replace them.

Check the release and ownership chain

Ask the team to demonstrate a release. Can it create a signed build, run tests, promote backend changes, submit to the stores and roll back? Review continuous integration, environment separation, feature flags, secrets rotation and incident responsibilities. Compare written instructions with what actually happens.

Confirm ownership of source code, design files, fonts, media, paid libraries and third-party accounts. Check licence terms and contractor agreements where necessary. Account recovery details should belong to the business, with individual access granted through roles. A shared personal password is not a handover plan.

Turn findings into decisions, not a long defect list

Use severity and confidence separately. Severity describes the consequence and urgency; confidence describes the strength of evidence. A suspected payment defect with weak evidence deserves investigation, not a dramatic rebuild recommendation.

Group findings into five actions:

• Keep: the component works, is owned and supports the roadmap.
• Repair: a contained defect or configuration issue can be fixed directly.
• Refactor: behaviour stays, but internal structure must change to make future work safe.
• Redesign: the journey or interface fails users even if the technology works.
• Rebuild: accumulated constraints make replacement less risky than continued modification.

A rebuild should have a written reason: unsupported technology, unsafe data handling, irreproducible releases, structural performance limits or change costs that exceed replacement. "The code looks old" is not enough. Our comparison of app redesign and modernisation and the guide to mobile app redesign cost help frame the next step.

What the audit report should contain

The useful deliverable is short enough to act on and detailed enough to verify. It should contain the scope, evidence register, current architecture, journey findings, analytics confidence, stability baseline, ownership gaps, prioritised recommendations and a phased plan. Each major finding needs an owner, consequence, evidence, recommendation, dependency and rough level of effort.

Include a 30-day stabilisation plan and a separate medium-term roadmap. This prevents urgent crash or access fixes from disappearing inside a redesign programme. It also makes the estimate clearer: the team can price verified work rather than compensate for uncertainty with a large contingency.

At Appfyl, we use the audit to decide which parts of the existing product deserve investment. Sometimes the right result is a narrow repair release. Sometimes design and analytics can be preserved while the backend is strengthened. A complete rebuild is reserved for cases where evidence shows that gradual change would cost more or leave material risk.

Questions people ask