Mobile app testing & QA
Mobile app testing services that catch problems before your users do
Our mobile app testing services cover the whole release: a test strategy matched to your risk, a real-device matrix, automated regression, security checks against OWASP MASVS, performance runs and accessibility testing to WCAG 2.2. We test apps we build and apps other teams built, for product teams in the USA, UK, UAE, Europe and Australia. You get clear release gates, not a spreadsheet of 400 low-priority bugs.
- Testing on real iOS and Android devices
- Automation in your CI, owned by you
- Security checks mapped to OWASP MASVS
- Accessibility tested against WCAG 2.2
What our mobile app testing services cover
Most app bugs that reach users are not exotic. They are a login that fails after a password reset, a checkout that breaks on a small Android screen, a crash when permission is denied, or a release that worked on Wi-Fi and times out on 4G. Good QA finds these cheaply by deciding up front which risks matter most and testing those hardest.
We work in two modes. Embedded QA sits inside a delivery team, writes acceptance criteria with the product owner and tests every two-week sprint build. Independent QA reviews an app another team built, often before a launch, a funding round or an acquisition. Both are part of our wider app development services and follow the same standards.
Either way, the output is the same: a test strategy, a device matrix, automated tests that live in your repository, bug reports with steps and video, and a go or no-go recommendation for every release.
Test strategy: the mobile testing pyramid
The cheapest test is the one that runs in milliseconds on every commit. The most expensive is a person tapping through the app on ten phones. A healthy test suite has many of the first and few of the second.
Unit tests cover business logic: pricing rules, validation, date handling, state changes. They should cover any logic that costs money if wrong.
Integration and API tests check that the app and backend agree: authentication, error codes, pagination, timeouts. Many “app bugs” are really contract mismatches these tests catch early.
UI tests (see automated app testing) automate the handful of flows that must never break, such as sign-up, login, checkout and the core action of your app. We keep them few, because UI tests are slow and break when the design changes.
Exploratory and manual testing sits on top: a tester trying to break the app the way users do, with interruptions, odd inputs and poor networks.
Signs your pyramid is upside down
- Every release needs days of manual regression
- UI tests fail randomly and get ignored
- Backend changes break the app in production
- No one can say what is covered
- Hotfixes go out without any automated check
Building a device matrix that reflects your users
You cannot test every phone, and you do not need to. We build the matrix from your analytics (or market data for a new app) and cover the combinations that carry the most risk.
| Tier | What it includes | When it runs |
|---|---|---|
| Tier 1: core | Current and previous iOS versions on a recent iPhone and a small-screen iPhone; a recent Pixel or Samsung on the latest Android; one mid-range Android on an older supported version | Every sprint build and every release candidate |
| Tier 2: breadth | iPad if supported, a low-memory Android, a large-screen or foldable device, a manufacturer skin with aggressive battery management | Every release candidate |
| Tier 3: edge | Oldest supported OS, accessibility settings at maximum text size, right-to-left languages, unusual locales | Before major releases and after OS updates |
| Cloud device farm | Wider coverage through BrowserStack or a similar device farm for automated runs (Firebase Test Lab is deprecated and shuts down on 30 September 2027) | Nightly or per pull request, as budget allows |
Device share differs sharply by market. According to StatCounter, iOS holds 53.6% of US mobile OS share but Android leads worldwide at 69.2%, so a US-first app and a global app need different matrices.
Test automation tools we use
We pick tools that fit your stack and that your future team can maintain. Tests live in your repository and run in your CI, so they do not leave with us.
Native iOS: XCTest and XCUITest
Apple’s own frameworks for unit and UI tests, run in Xcode Cloud, GitHub Actions or Bitrise. Our iOS app development team writes these alongside features.
Native Android: JUnit, Espresso, Compose testing
Fast JVM unit tests, plus Espresso or the Compose testing APIs for UI.
Flutter and React Native
Flutter’s widget and integration tests; Jest and React Native Testing Library, with Detox for end-to-end runs on React Native.
Cross-platform E2E: Maestro and Appium
Maestro for readable, quick-to-write flow tests; Appium when a client already has a suite or needs one framework across many apps.
API and contract tests
Postman or code-based API suites run in CI against staging, so a backend change that breaks the app fails the build, not the release.
CI and distribution
GitHub Actions, Fastlane and Codemagic to build, test and ship to TestFlight and Play internal testing automatically on every merge.
Security testing with OWASP MASVS and MASTG
Security testing should follow a published standard, not a tester’s instinct. We use the OWASP Mobile Application Security Verification Standard (MASVS) to define what a secure app must do and the Mobile Application Security Testing Guide (MASTG) for how to test it. Together they are the industry baseline for mobile app security testing.
In practice that means checking how the app stores data on the device (tokens in the Keychain or Android Keystore, not in plain preferences), how it talks to the server (TLS everywhere, certificate pinning where the risk warrants it), how authentication and sessions are handled, what the app leaks in logs and backups, and how easily the binary can be reverse-engineered or tampered with. We also review third-party SDKs, since an analytics or ads library can collect more than your privacy policy says.
For apps handling payments or health data, we agree the level of testing with you during discovery and map findings to MASVS controls, so your compliance team or auditor can trace each one. Our mobile app security testing report is a technical assessment, not a legal opinion; regulated products still need sign-off from your own advisers.
Security checks in every release
A short list that runs every time, on top of deeper MASVS reviews before major launches.
- No secrets, API keys or test credentials in the app binary or repository
- Tokens stored in Keychain or Keystore, cleared on logout
- All traffic over HTTPS; no cleartext exceptions left from development
- Server rejects expired and tampered tokens
- Personal data absent from logs, crash reports and screenshots in the app switcher
- Third-party SDK list reviewed against the privacy policy and store privacy labels
- Account deletion works end to end, as Apple requires for apps with sign-up
Need a test plan before launch?
Send us your app or build link. Within one business day you get our view on the biggest risks, the device matrix we would use and the next step toward a fixed QA quote.
Performance testing on real devices
A flagship phone on office Wi-Fi hides most performance problems, so app performance testing starts on modest hardware. We test on mid-range and older devices with throttled networks, because that is where users uninstall.
We measure cold start time, screen transition smoothness (dropped frames), memory growth over a long session, battery drain during background work, app size and API response times under load. Tools include Xcode Instruments, Android Studio Profiler, Firebase Performance Monitoring and load tests against the backend with k6 or JMeter.
Often the performance problem is not slow code. It is the app making ten API calls where one would do, or downloading full-size images for thumbnails. Those fixes span the app and the server, which is why we test them together with our mobile app backend development team when we own both.
Accessibility testing to WCAG 2.2 and the EAA
In a growing number of markets, accessibility is a legal requirement for some apps, not only good practice. WCAG 2.2 became a W3C Recommendation on 5 October 2023, adding nine new success criteria over WCAG 2.1, according to the W3C announcement. In the EU, the European Accessibility Act applies from 28 June 2025 to covered products and services placed on the market after that date, including e-commerce, consumer banking and transport services delivered through websites and apps.
In the US, Department of Justice guidance says the ADA’s effective-communication requirements apply to businesses’ online goods and services, though it does not mandate a specific technical standard for private businesses. Whether a rule applies to your app is a question for your lawyer; testing against WCAG 2.2 AA is the practical way to be ready either way.
What we test
- Screen readers: VoiceOver on iOS and TalkBack on Android, through every core flow.
- Dynamic Type and font scaling at the largest sizes, without clipped or overlapping text.
- Colour contrast, focus order, labels on every icon button and touch targets large enough to hit.
- Alternatives to drag gestures and no reliance on colour alone to convey state.
- Automated checks with Xcode Accessibility Inspector and Android’s Accessibility Scanner, backed by manual review.
Accessibility is cheapest when designed in, so we raise issues at prototype stage with our UI/UX design team rather than after release. Our mobile app accessibility guide includes a checklist you can run yourself.
Release gates: how a build becomes a release
Every build passes the same gates before it reaches users. If a gate fails, the release waits; we do not argue with the data.
Automated gate on every merge
Unit, integration and core UI tests pass in CI. Static analysis and dependency vulnerability scans show no new high-severity issues.
Sprint build gate
The build goes to TestFlight and Play internal testing. New features are tested against acceptance criteria on Tier 1 devices and demoed to you.
Release candidate gate
Full regression on Tier 1 and 2 devices, security checklist, accessibility pass on changed screens and a performance comparison with the previous release.
Store readiness
Store listing, privacy labels, demo account and review notes checked against the most common rejection reasons. Our app store submission team owns this step.
Staged rollout and monitoring
Phased release on the App Store and staged rollout on Google Play, watching crash-free sessions in Crashlytics or Sentry before widening to all users.
When independent QA makes sense
If your app was built by another agency or a freelancer and you are not sure what you have, an independent test pass is the cheapest way to find out. We run a structured review: smoke tests on the device matrix, a security baseline against MASVS, an accessibility sample and a look at crash data. You get a prioritised list of what must be fixed before launch and what can wait.
If the findings point to deeper problems in the code itself, our app modernization and rescue service picks up from there with a full code audit. After launch, testing continues as part of app maintenance and support, re-running regression against each new iOS and Android release.
Mobile app testing services: FAQs
Do you test on real devices or emulators?
Both, for different jobs. Emulators and simulators are fine for fast automated checks in CI. Real devices are essential for performance, camera, push notifications, biometrics, battery behaviour and manufacturer quirks. Every release candidate is tested on real iOS and Android devices from the agreed matrix, with a cloud device farm for wider automated coverage.
Can you test an app another company built?
Yes. Independent QA is a common starting point. We need a build (TestFlight or an APK/AAB), test accounts and, ideally, read access to the repository and crash reporting. You get a prioritised findings report with reproduction steps and video, plus a recommendation on what to fix before launch. Code access lets us explain causes, not just symptoms.
How much of our testing should be automated?
Automate what runs often and rarely changes: business logic, API contracts and a small set of critical user flows. Keep exploratory testing manual, because people find the problems scripts were never written for. A common mistake is automating hundreds of fragile UI tests that break with every design change and end up ignored.
What is OWASP MASVS and do we need it?
MASVS is the OWASP standard that defines security requirements for mobile apps; MASTG is the companion guide for testing them. Every app benefits from the baseline checks. Apps handling payments, health or other sensitive data should be tested more deeply against it, and the mapped findings help when a partner, investor or auditor asks how security was verified.
Does our app need to meet WCAG 2.2?
It depends on your market and sector, so confirm with your lawyer. The European Accessibility Act applies from 28 June 2025 to covered services such as e-commerce and consumer banking, including their apps. In the US, the ADA applies to online services without naming a standard. Testing to WCAG 2.2 AA is the practical benchmark in both cases.
Who owns the test scripts and reports?
You do. Automated tests live in your repository and run in your CI pipeline from the start, and test plans, bug reports and release reports are shared in your tools. If you later move QA in-house or to another vendor, everything stays with the code, consistent with our policy that clients own all code and project artefacts.
Ship your next release with confidence
Book a 30-minute call. We will review your current testing, device coverage and release process, and recommend the smallest set of changes that would cut the most risk.