Mobile App Testing: The Complete Guide

An app that works on your phone can still crash on someone else's. Mobile app testing is checking that an iOS or Android app works, performs and stays usable on the devices, OS versions and conditions your users have, before each release reaches the App Store or Google Play. It combines testing by hand with automated tests that run on emulators, simulators and real devices.

Mobile is less forgiving than the web. Your app has to keep working on every Android phone and iPhone your users still carry, across many manufacturers, models and screen sizes. Even two people with the same phone can be on very different OS versions, because people install updates when they get around to it. And you can't fix a mobile app on the fly the way you can a website: every change goes through App Store or Google Play review, so a bug that ships means another full review cycle before the fix reaches anyone. The cheapest place to catch a mobile bug is before the release goes out for review.

Need mobile coverage without building a device lab? Nutrition app Lifesum went from more than two days of manual regression testing per release to automated feedback in 30 to 45 minutes with QA Wolf. Book a demo to see it on your app.

What is mobile app testing?

Mobile app testing is the work of checking a mobile app's behavior before users see it. It covers whether features work, whether the app runs on the phones and OS versions people use, how fast it is, whether it's easy and accessible to use, and whether it keeps data safe. Teams do it by hand, with automated tests, or, most often, both.

How does testing differ for native, hybrid and mobile web apps?

How an app is built decides which tools can drive it and what its tests have to handle.

• Native apps are built for one platform, usually in Swift for iOS or Kotlin for Android. They need mobile test frameworks that can drive the app and the operating system around it.
• Hybrid apps share code across platforms, either web content inside a native shell or a cross-platform framework such as React Native or Flutter. Tests have to handle native screens and web views in the same flow.
• Mobile web apps run in the phone's browser. Browser tools such as Playwright can test most of them, and real devices matter only for behavior tied to the phone itself.

Why is mobile app testing harder than web testing?

Mobile app testing is harder because it's hard to run at scale, you don't control where the app runs, and you can't fix a bug as fast once it ships.

• Scale. A phone or emulator runs one test at a time, and each emulator needs a lot of CPU, GPU and memory. A web suite can run many browser sessions at once on one machine, but a mobile suite needs a device for every test it runs in parallel. A hundred five-minute tests take 500 minutes of device time per run, so finishing in five minutes takes 100 devices at once: your own device farm, or devices rented from a cloud such as AWS Device Farm, Firebase Test Lab or Sauce Labs. Parallel testing on that many devices is what keeps a mobile suite fast enough to run on every build.
• Devices. Android phones come from many manufacturers, which each change Android in their own ways, and Apple supports several generations of iPhones and iPads with different screen sizes. Your app has to stay compatible with all the ones your users still have.
• OS versions. People update when they get around to it, so several Android and iOS versions are in use at once, even on the same model of phone. Every version you still support is one more to test.
• Slow fixes. A web fix can ship in minutes. A mobile fix goes through another full App Store or Google Play review, and then each user has to install the update, so a bug can stay on phones long after you've fixed it.
• The operating system keeps state. Permissions granted in one session, system settings, the device language and data the app saved can all carry over and change what the next session sees.
• Hardware and interruptions. The camera, GPS, Bluetooth, push notifications, phone calls, low battery and a dropped signal all change how an app behaves, and most are hard to reproduce at a desk.

What are the types of mobile app testing?

The main types of mobile app testing are functional, end-to-end, regression, compatibility, performance, usability, accessibility, security, interruption, and installation and update testing. Most teams start with the first three and add the others as the app grows.

• Functional testing checks that each feature does what it should: the login accepts valid credentials, the cart adds the right item.
• End-to-end testing follows a whole user journey through the app, its backend and anything else it touches, such as sign-up through to a first purchase.
• Regression testing re-runs existing tests after each change to catch features that used to work and now don't.
• Smoke testing is a quick check that a new build installs, launches and reaches its first screen before anyone spends time on deeper tests.
• Compatibility testing runs the app across the device models, screen sizes and OS versions your users have.
• Performance testing measures launch time, scrolling, memory and battery use, and behavior on slow networks.
• Usability testing watches real people use the app to find where they get confused or stuck.
• Accessibility testing checks that people using screen readers such as VoiceOver and TalkBack, larger text or other assistive settings can use the app.
• Security testing looks for weaknesses in how the app stores data, signs users in and talks to its servers.
• Interruption testing checks what happens when a call, notification, low-battery warning or lost connection cuts into a flow, and when the app goes to the background and comes back.
• Installation and update testing covers a fresh install, an upgrade from the previous version with existing data, and an uninstall.

Should you test on real devices, emulators or simulators?

Use the iOS Simulator for fast feedback while you build, but not for regression or release testing. Android emulators run the real Android operating system on virtual phone hardware, so they're as good as real phones for regression and release testing, and they let a test control things a real phone can't. iOS has no emulator, so iOS regression and release testing belongs on real iPhones.

• Real devices are the phones and tablets your users have. For iOS, they're how you test a release, since the Simulator runs on a Mac's hardware. They cost money to buy, and time to keep charged, updated and reset between tests.
• Emulators run a complete copy of a phone's operating system on a virtual machine that imitates the phone's processor, memory and network. Android Studio's emulator is the standard one for Android. They're free, quick to start and as good as a real phone for regression and release testing. A test can also set an emulator's GPS location, put a barcode in front of its camera, play audio into its microphone and change its motion sensors, which a real phone doesn't allow.
• Simulators imitate a phone's software on your computer's own hardware. Apple's iOS Simulator, part of Xcode, is the common one. It's fast for development, but because it borrows the Mac's processor and memory, it can hide performance problems, and it can't reproduce hardware such as the camera or NFC. That makes it good for fast feedback, not for regression testing.

A common split: the Simulator while you build, then Android emulators and real iPhones for regression and release testing on every commit and before each release.

If you don't want to buy and maintain phones, device clouds such as BrowserStack, Sauce Labs, AWS Device Farm and Firebase Test Lab rent access to real devices and emulators. Ask each one how it resets a device between sessions, since state left behind by the last session is a common source of flaky tests. QA Wolf runs tests on its own mobile testing infrastructure: real iPhones and iPads, Android emulators and real Android phones, with a clean device for every test.

Should mobile app testing be manual or automated?

Both, in that order. A person checks a new feature first, for what a script can't judge: whether a new screen makes sense and feels right to use. Once it passes, build an automated test for it. Automated mobile testing then repeats that check on every build, so you can keep shipping without testing the feature by hand again.

• Check by hand first: new features, usability, the first look at a new design, and exploratory testing to find what nobody thought to test.
• Then automate: every flow that passed that check, critical flows first, so regression checks and smoke tests run on each build and across the devices and OS versions you support. Automated tests can also compare each screen with an approved screenshot, so a visual change fails the test the same way a broken flow does.

How do you do mobile testing manually?

1. Get the build onto devices. Use TestFlight for iOS or an internal testing track in Google Play Console for Android, or install it directly from Xcode or with adb, the Android Debug Bridge.
2. Work through written test cases for your critical flows, so every tester checks the same things.
3. Go past the happy path. Rotate the phone, send the app to the background and reopen it, trigger a notification, turn on airplane mode, deny a permission, and upgrade from the previous version.
4. Repeat on your edge devices: the oldest OS version you support, the smallest screen, and a lower-end phone.
5. Report each bug with the device model, OS version, build number, steps to reproduce and a screen recording.

What tools do you need for mobile app testing?

Mobile testing tools fall into two groups: frameworks that drive the app in a test, and the devices the tests run on.

The main frameworks:

• Appium is open source and drives iOS and Android through one WebDriver API, using each platform's own automation underneath (XCUITest on iOS, UIAutomator2 or Espresso on Android). It runs outside the app, so tests can handle system dialogs, notifications and other apps. You can write tests in most languages; WebdriverIO is a common JavaScript client for it.
• XCUITest is Apple's UI testing framework, built into Xcode. It's fast and stable for in-app checks on iOS, with tests written in Swift or Objective-C.
• Espresso is Google's UI testing framework for Android. It runs inside the app and waits for the app to be idle before each step, which keeps tests fast and steady, but it can't reach system screens or other apps. Google's UI Automator covers those.
• Maestro is open source and describes tests as YAML flows for iOS and Android. It's quick to start with for simple flows.
• Detox is a gray-box framework for React Native apps, maintained by Wix, that tracks what the app is doing and waits for it to be idle.
• integration_test is Flutter's own framework for testing Flutter apps.
• Playwright tests mobile web apps and progressive web apps by emulating mobile browsers. It doesn't drive native apps.

For the devices, you have Android Studio's emulator, Xcode's iOS Simulator, your own phones, a device cloud, or a service that provides devices with the testing. QA Wolf's comparison of mobile testing frameworks covers each framework's strengths, tradeoffs and costs.

How is testing iOS apps different from testing Android apps?

iOS testing is constrained by Apple's tools and security model; Android testing is constrained by the number of devices and versions you have to cover.

How do you test an iOS app?

Build and test in Xcode on a Mac. XCUITest runs UI tests on the iOS Simulator or a connected iPhone, and Appium drives the same devices from outside the app. To install a build on a real iPhone, it has to be signed for that device, and TestFlight gets beta builds to testers.

iOS limits what a test can control. There's no supported way to feed a real iPhone's camera or microphone a known image or sound, so teams either test those flows by hand or work from inside the app itself, as QA Wolf does.

How do you test an Android app?

Android Studio creates emulators for any device profile and Android version, and Espresso and UI Automator come with Android's testing libraries. Appium drives Android through UIAutomator2 for end-to-end tests that cross into system dialogs and other apps. adb installs builds and changes device settings from the command line, and Google Play Console's internal testing track gets builds to testers.

The hard part is coverage. Pick test devices and Android versions from your own analytics, and include phones from the manufacturers most of your users have, since each one changes Android in its own way.

How do you test a mobile app? A checklist to start

If you're testing without a platform like QA Wolf, your team can only build, run and maintain so many tests, on so many devices. Spend that capacity where it matters most: the flows that would cost you most if they broke, on the devices your users actually have.

1. Pick the flows that matter most. Sign-up, login, payments and your app's core task: the flows that would cost you most if they broke.
2. Choose devices from your own data. List the phones and OS versions most of your users run, then add the oldest OS version you support and the smallest screen.
3. Decide what runs where. Simulators while you build; Android emulators and real iPhones for regression and release testing on every commit.
4. Write test cases that include mobile conditions. For each flow, cover permissions, interruptions, backgrounding, poor network, rotation and upgrading from the previous version.
5. Automate each critical flow once it passes a manual check, in an open framework such as Appium, so the tests are code your team can read, change and keep.
6. Start every test from a clean state. Reinstall the app, reset permissions and seed fresh test data, so each failure comes from your app, with nothing left over from the last test.
7. Run tests in parallel on every build. Wire the suite into CI and spread it across devices, so results come back while the change is still fresh.
8. Fix flaky tests instead of retrying them. A test that passes on a retry is hiding a timing problem or a real bug. Wait for a clear sign that the app is ready before each step.
9. Add a test for every bug that escapes, so the same bug can't ship twice.

As the suite grows, the guide to automated mobile app E2E regression testing covers how to keep it fast and stable.

With QA Wolf, you don't have to make that trade-off. AI agents and QA engineers build and maintain the tests, so coverage isn't limited by your team's hours, and every test runs at once, each on its own device on QA Wolf's mobile testing infrastructure, so adding flows and devices doesn't slow down your releases.

How does QA Wolf test mobile apps?

QA Wolf runs mobile end-to-end tests on devices it manages itself: real iPhones and iPads for iOS, and Android emulators for Android, with real Android phones available. The tests are Appium code your team owns, and the whole suite runs in parallel, each test on its own clean device, so a run takes about as long as its longest test.

• Real iPhones and iPads. iOS tests run on physical devices in QA Wolf's own device farm. QA Wolf re-signs your app as it installs it, so tests can run unreleased builds, and each device is cleaned up between runs.
• Android emulators built for any combination. A test names a device and an Android version, and QA Wolf starts that combination when the test runs, each emulator in its own container with dedicated CPU, GPU and memory. A fresh emulator is created for each run and discarded when it finishes. Real Android phones are available on request.
• A clean device for every test. On iOS, the app is uninstalled and its data, caches and Keychain entries are cleared before the next test. On Android, the emulator itself is new, and real Android phones are reset between runs.
• Hardware and OS flows. On iOS, a test can put a photo or video into the camera feed, inject audio into the microphone, deliver a barcode scan and slow the network down, through an instrumentation library QA Wolf adds when it re-signs the app (iOS device controls). On Android, a test can scan a barcode or QR code, play audio into the microphone, set the GPS location and change motion-sensor readings. Tests on both can allow or deny permission prompts.
• Visual checks on iOS and Android. A test can compare a screen with an approved screenshot, so a layout break or a missing image fails the run like any other bug.
• Runs you can watch live. QA Wolf streams Android emulators and real iPhones to your browser over WebRTC, so you can watch a test as it runs.
• Tests you own, failures checked for you. Tests are standard Appium code, run through WebdriverIO, that your team can read and change. QA Wolf investigates every failure, so you're told about real bugs and broken tests get fixed. With Coverage-as-a-Service, QA engineers also plan, write and verify the tests.

Meow Wolf runs 1,300 automated tests across its iOS and Android apps with QA Wolf and saves more than 40 hours of testing per release cycle.