WhatsApp
iOS
Android
Flutter
React Native
FirebaseWhat makes mobile app testing different
Mobile apps run in far more varied conditions than websites: thousands of Android device models, several iOS versions, different screen sizes, unreliable networks, interruptions from calls and notifications, limited battery and strict app store rules. An app that works perfectly on a developer’s phone can fail for a large share of real users.
Mobile testing covers this variety deliberately, using real devices chosen from your user data and scenarios that reflect how people use phones on the move.
Problems we solve
- Crashes on specific devices or OS versions
- Problems when the network drops or switches from Wi-Fi to mobile data
- Store rejections close to launch
- Battery drain or overheating complaints
- Push notifications, deep links or payments failing intermittently
What’s included
Functional testing
Every feature and flow on iOS and Android.
Device & OS compatibility
A device matrix based on your analytics plus cloud device labs.
Network & offline testing
Slow, unstable and offline conditions, including sync recovery.
Performance testing
Startup time, memory, battery and frame rate.
Store readiness
Review guidelines, privacy declarations and listing checks.
Automation
Appium, Espresso, XCUITest or Detox for regression.
Real-world scenarios we test
- Interruptions: incoming calls, notifications, switching apps mid-flow
- Permissions denied, then granted later in settings
- Rotations, split screen, dark mode and large text
- Low storage and low battery modes
- Upgrading from an old app version with existing data
- Payments, subscriptions and restores in sandbox environments
Choosing devices to test on
Testing on every device is impossible, so we choose a matrix from your analytics: the most common models, OS versions and screen sizes among your users, plus a few older or low-memory devices to catch performance problems. For new apps without data, we use market share for your target countries. The matrix is reviewed every few months as your audience changes.
Real devices, emulators or cloud device farms?
| Option | Strengths | Limitations |
|---|---|---|
| Emulators and simulators | Fast, free, easy to automate | Miss hardware, performance and some OS behaviours |
| In-house real devices | True behaviour, good for exploratory testing | Limited range; devices age and need management |
| Cloud device farms (BrowserStack, Sauce Labs, Firebase Test Lab, AWS Device Farm) | Wide device coverage, automation at scale | Ongoing cost; less hands-on for some tests |
Most teams combine all three: simulators during development, a small set of real devices for daily checks and a device farm for broad regression before release.
Pre-release checklist for mobile apps
- Fresh install and upgrade from the previous version
- Login persistence after update, logout and token expiry
- Permission prompts accepted and denied
- Push notifications in foreground, background and when the app is closed
- Dark mode, large text and screen-reader basics
- Poor network, no network and switching between Wi-Fi and mobile data
- Interruptions: calls, backgrounding, low battery
- Deep links and universal links
- In-app purchases in sandbox
- Store metadata, screenshots and privacy disclosures
Running this checklist on every release — partly automated, partly manual — prevents the most common causes of one-star reviews.
Automating mobile tests sensibly
Mobile end-to-end automation is valuable but more fragile than web automation, because of device variety, animations and system dialogs. We automate a compact set of critical journeys — onboarding, login, the core task, purchase — using stable test IDs rather than on-screen text, and run them on a small device matrix for every build. Broader device coverage runs nightly on a device farm. Everything else is covered by unit and widget tests, which are faster and far more reliable than driving the full app.
Mobile testing tools we use
| Tool | Use | Notes |
|---|---|---|
| XCTest / XCUITest | Native iOS unit and UI tests | Fast and reliable for Swift apps |
| Espresso | Native Android UI tests | Tight synchronisation with the app reduces flakiness |
| Appium | Cross-platform UI automation | One approach for iOS and Android; slower than native frameworks |
| Maestro / Detox | Flow-based UI tests | Popular for React Native and simple, readable flows |
| Flutter integration_test | Widget and integration tests for Flutter | Runs on devices and emulators |
| Firebase Test Lab, BrowserStack, AWS Device Farm | Cloud real-device testing | Broad device coverage without owning hardware |
Our mobile testing process
-
Device and OS matrix1–2 days
Choose devices and OS versions from your analytics, target markets and minimum supported versions.
-
Test design2–5 days
Write scenarios for core journeys, interruptions, permissions, offline behaviour and upgrades.
-
Executionper release
Manual exploratory testing on real devices plus automated smoke and regression runs.
-
Store readiness1–2 days
Check store guidelines, privacy declarations, screenshots and release notes before submission.
-
Post-release monitoringongoing
Watch crash reports and reviews, and turn production issues into new test cases.
Areas that often break in mobile apps
- Upgrading from an older app version with existing data on the device
- Permission prompts denied, then granted later from system settings
- Push notifications opening the correct screen from a cold start
- Login sessions expiring while the app is in the background
- Deep links and universal links on both platforms
- Large text, dark mode and screen readers
- Payments and subscriptions in sandbox and production-like environments
Metrics to watch
| Metric | What it tells you |
|---|---|
| Crash-free sessions and users | Overall stability as reported by your crash tool |
| App start time | How quickly users can do something useful |
| ANR rate (Android) | Whether the app freezes on the main thread |
| Store rating trends | Whether users notice quality changes after releases |
| Escaped defects per release | How well testing catches problems before users do |
Stable apps also need ongoing care after launch — see mobile app maintenance — and a team that tests while building, as in our mobile app development service.
Questions to settle before testing starts
- Which devices and OS versions must be fully supported, and which only checked briefly?
- Do we have a staging back end with realistic test data?
- How will testers install builds — TestFlight, Firebase App Distribution or similar?
- Which flows involve money, health or personal data and need the deepest testing?
- Who decides whether a release goes to the stores?
Testing real-world conditions
Mobile users rarely sit on fast office Wi-Fi with a full battery. We deliberately test the conditions that cause real complaints:
- Slow, unstable and switching networks, including moving from Wi-Fi to mobile data mid-request
- Low battery and battery-saver modes that restrict background work
- Low storage that prevents downloads or caching
- Incoming calls, notifications and app switching during critical steps such as payment
- Older, lower-memory devices still common among your users
- Different regional settings for dates, currencies and right-to-left languages
Each condition gets clear expected behaviour — a retry, a saved draft, a helpful message — so the app degrades gracefully rather than losing work.
Beta testing and staged rollouts
Testing does not stop at submission. We help you run beta programmes through TestFlight and Google Play testing tracks, collect structured feedback from early users, and use staged rollouts so a new version reaches a small percentage of users first. If crash rates or reviews worsen, the rollout is paused before most users are affected, and the issue becomes a new regression test.
Related services
Part of QA & testing. Often paired with mobile app development and app maintenance.
This page is part of QA & Software Testing Services — see the full overview for related services, approach and pricing.