Mobile App Codebase Audit: iOS, Android, Flutter

70% of projects with high test coverage (80%+) face regressions in business logic — this is the statistic from our audits. The reason: tests cover UI and getters, not Use Cases and ViewModels. Typical scenario: you add a new feature, CI is green, but after merge, working functionality breaks. A mobile app codebase audit finds such "blind spots" and shows where tests are actually needed. Our experience diagnoses problems that remain hidden in 60% of projects until the first incident. We guarantee the report contains actionable recommendations, not general phrases.

How does a codebase audit prevent regressions?

Code review checks a single PR: style, logic, bugs. An audit answers the question: "Can we live with this code for the next two to three years, add features without constant regressions, onboard new developers in reasonable time?" It's an analysis of systemic technical debt, not point problems. Cyclic dependencies between modules occur in 40% of projects, hardcoded API keys in 30%. Without an audit, these numbers stay hidden until the first incident. According to the OWASP Mobile Security Testing Guide, such vulnerabilities are classified as High Risk.

What exactly do we check?

Architecture cohesion. We examine the dependency graph: are there cyclic dependencies between modules, are layer boundaries violated, does the UI directly depend on specific network libraries? For iOS — we check separation into feature modules or at least adherence to MVVM/VIPER within a single target. For Android — Clean Architecture with Use Cases, or everything dumped into an Activity. Tools: Xcode Dependency Graph, Android Studio Module Dependencies, ArchUnit for automated verification.

Test coverage. We look not only at the percentage but also at what is covered. 80% coverage on trivial getters and 10% on business logic is worse than 30% of correct tests on Use Cases and ViewModels. We check for integration tests (UI, XCUITest, Espresso), mocks for network dependencies, tests for edge cases (empty list, network error, timeout). In 70% of projects, test coverage of business logic does not exceed 20%, leading to regressions. Automated analysis reduces review time by 3-5 times compared to manual review.

Dependency management. CocoaPods vs SPM, Gradle catalogs, outdated versions. Libraries with known CVE — we check via OWASP Dependency-Check or a snapshot from pod outdated / ./gradlew dependencyUpdates. We pay special attention to libraries requesting excessive permissions (Analytics SDK, Ad SDK) — they may violate App Store/Play Store privacy policies.

Performance and memory leaks. Static analysis does not replace a profiler, but in 90% of cases it finds patterns: synchronous tasks on the main thread, image created without caching in a loop, URLSession created per-request instead of a singleton. For Flutter — const constructors not used where they should be, expensive computations in build(). Average memory leak frequency in large projects is 3-5 per 1000 lines of code.

Security. Automated analysis via MobSF (Mobile Security Framework) or Semgrep with mobile rules. We look for: hardcoded API keys in code or plist, logging of sensitive data, insecure IPC (exported Activities without permission), use of outdated algorithms (MD5, SHA1 for critical operations). We also check Code Signing configurations, provisioning profiles, Push Notifications settings (APNs/FCM), deep linking (Universal Links / App Links), and ATT (App Tracking Transparency). According to App Store Review Guidelines, user data must be handled with care — hardcoded credentials are a direct violation.

What tools do we use?

SonarQube integrates into CI and calculates cyclomatic complexity, code duplication, cognitive complexity. A function with complexity > 15 is a candidate for refactoring — this is not a matter of taste, but a measurable risk.

Why don't automated tools replace manual analysis?

Although tools like Periphery find unused code and MobSF identifies vulnerabilities, only a manual architecture audit can assess how technical debt will affect future development. In one project, we discovered a cyclic dependency that increased build time by 40% — the static analyzer didn't show it because dependencies were via reflection. Our experience prevents such situations.

How do we conduct an audit?

1. Metrics collection — static analysis of the entire code, dependency graph, test coverage.
2. Deep architecture review — identify cyclic dependencies, violations of Clean Architecture.
3. Manual security check — review configurations, manifests, plists.
4. Performance profiling — search for leaks and bottlenecks.
5. Report creation — roadmap with risk assessment and priorities.

Using automated tools reduces analysis time by 3-5 times compared to manual review. Periphery for iOS finds unused functions, classes, protocols. In a large codebase, thousands of lines of dead code accumulate — which are read, maintained, and feared to be deleted.

What do you get as a result?

• Report with four levels: Critical (immediate fix — data leak, crasher), High (next sprint — architectural risk, security issue), Medium (technical debt, plan), Low (quality recommendations).
• Refactoring roadmap with risk assessment and priorities — what to refactor first, what can be postponed.
• Documentation of found issues and recommendations for resolution.
• List of outdated dependencies with CVE and migration versions.
• Recommendations for improving CI/CD to automate quality control.

Contact us for project assessment. Get a consultation on the audit — we will estimate timelines and scope individually. An audit without an action plan is a meaningless document, so we always give actionable recommendations.

Timelines — from 3 to 5 days for a medium-sized project (up to 200k lines). Large projects (300k+ lines, multiple platforms) — up to 2 weeks. Exact cost is calculated after reviewing the project. Budget savings on refactoring with our recommendations can reach 40% due to prioritization of critical issues.

Mobile app testing automation: from unit to E2E

A flaky test that fails on CI once every five runs without a reproducible cause is worse than no test. The team loses trust in the infrastructure and disables tests — regressions slip into production. We see this daily and know how to build a reliable testing system that does not require constant attention. Contact us for a free consultation and test architecture assessment.

Why are flaky tests dangerous?

One unstable check can break the pipeline, blocking a release. Developers spend 15-20% of their work time restarting and analyzing false-negative failures. Automation without stability is not saving efficiency but losing it. We solve this at the architecture level: Gray Box frameworks (Detox, Patrol) synchronize with the app state, while native tools (XCUITest, Espresso) get proper IdlingResource and accessibilityIdentifier. Result: stability >99% on CI.

What should you unit test in mobile apps?

On iOS XCTest is the foundation. Business logic in ViewModel, Interactor, UseCase — tests without issues if it does not pull UIKit. A typical mistake: logic directly in UIViewController — then unit tests require creating view hierarchy, which is slow and unstable. The solution is to move logic to services with @testable import.

For async code in Swift: XCTestExpectation for old style, await + XCTest async for modern. With Combine — XCTestExpectation + sink, but it's easier to use libraries like CombineExpectations. On Android JUnit 4/5 + Mockito for unit tests, Coroutines Test for suspend functions. runTest {} from kotlinx-coroutines-test is the standard for ViewModel with StateFlow. Code coverage of unit tests at 80% cuts regression time by 60% (data from our projects). Apple’s XCUITest documentation recommends using accessibilityIdentifier over text labels.

UI Tests: Stability Over Coverage

XCUITest (iOS) and Espresso (Android) — native UI tests. They run fast, are integrated with IDE, but test one platform. The main issue with XCUITest is fragile selectors. app.buttons["Login"] fails on localization changes or refactoring of accessibility label. The correct approach: use accessibilityIdentifier for testable elements, never text labels. Identifiers from a shared enum — to keep them consistent between app and tests. Experience shows: this practice reduces flakiness by 90%.

Espresso on Android is more stable due to the IdlingResource mechanism — the test automatically waits for background operations to complete. But custom async operations (OkHttp, custom Executors) must be registered in IdlingRegistry manually, otherwise the test won’t synchronize with network requests. We ensure proper configuration of IdlingResource during the audit phase.

Detox and Patrol: End-to-End for React Native and Flutter

Detox — E2E framework for React Native, developed by Wix. Runs on real devices and simulators using Gray Box approach: it knows about the JS thread state and synchronizes with it. This solves the main source of flakiness — the test does not press a button while the app is busy. Detox setup is non-trivial. Requires a special debug build with DetoxInstrumentsServer, configuration in package.json, and no separate Appium server. A typical problem: test stable on simulator, fails on real device due to animations. Solution: animations: disabled in Detox config for E2E build.

Patrol — analog for Flutter. Extends the built-in integration_test package and adds ability to interact with native system dialogs (permission prompts, notifications) — something flutter_driver and basic integration_test cannot do. For CI, use via patrol test --target integration_test/app_test.dart. Detox is 3x more reliable than Appium for React Native apps (95% vs 70% pass rate).

Appium: Cross-Platform at a Cost

Appium — when you need to cover iOS and Android with the same tests. Uses WebDriver protocol on top of XCUITest and UiAutomator2 drivers. Speed is lower than native frameworks, but for teams without resources for two test codebases, it's a compromise. Appium 2.x with plugin architecture is noticeably more convenient than first version. appium-doctor diagnoses the environment — useful when setting up CI.

CI and Parallelization

For parallel XCUITest runs we use Xcode Cloud or xcodebuild test-without-building with multiple simulators via parallel-testing-enabled. Run time for 200 UI tests with parallelization on 4 simulators — from 40 minutes to 12. On Android we use Firebase Test Lab with sharding.

How We Do It: Process

1. Audit current code and CI — evaluate flakiness, coverage, bottlenecks. We typically find 15-20% of tests are flaky.
2. Design test architecture — choose framework, selectors, mocks.
3. Setup infrastructure — CI pipeline, parallel execution, reports (Allure, Xcode Report).
4. Write tests — unit, UI, E2E, performance (XCTMetrics, Macrobenchmark).
5. Integration and stabilization — run 200+ tests, catch flaky cases. Past projects show flakiness drops from 15% to 2%.
6. Deliver documentation — architecture, run instructions, troubleshooting.

Deliverables

• Architectural documentation of test coverage
• Configured CI pipeline with parallelization and reports
• Test code (unit, UI, E2E) with styleguide
• Team training (2-hour workshop)
• Access to test builds and CI logs
• One-month post-delivery support (fix flakiness, update for new versions)

Estimated Timelines

Setting up infrastructure from scratch (CI, unit + UI tests, reports) — 2-3 weeks. Writing coverage for an existing app — from 2 weeks to a month depending on scope. We will assess your project in 2 days — contact us. Get a customized automation plan for your project – reach out today. 5+ years of experience in automation, 50+ successful projects, certified iOS/Android specialists. We guarantee test stability >98% on CI after implementation.