Mobile App Testing Checklist for iOS and Android Releases (2026)

Before every iOS or Android release, test eight areas on real devices: install and update, permissions, interruptions and rotation, offline and slow networks, deep links and push, accessibility, performance, and the store rules that cause rejections. Run the money journeys, such as sign-up, login and payment, on each device in your matrix. A manual pass of this checklist on four devices takes one tester about two to four days.

If you would rather have it tested for you, see how RAITHub would test this below. RAITHub tests mobile apps on real devices and device clouds; it does not build them. Use the checklist as-is, or hand it to whoever runs your release.

Which devices should the checklist run on?

Pick devices from your own analytics first: the models and OS versions behind most of your sessions. Without data, start with this matrix and adjust after launch.

Slot	iOS	Android	Why
Current flagship	A recent iPhone on the latest iOS	A recent Pixel or Samsung Galaxy on the latest Android	Where most new features are first used
Older device	An iPhone three or four years old	A low-memory budget phone	Memory, speed and layout problems show up here first
Different screen	A small iPhone or an iPad if supported	A large phone or a foldable	Layout breaks at size extremes
Previous OS version	The previous major iOS	Two versions back from the latest Android	Behaviour and permission changes between versions

The split between platforms should follow your users. Worldwide, StatCounter puts mobile share at 69.17% Android and 30.81% iOS for September 2026 (StatCounter mobile OS share), while Apple reported iOS 26 on 79% of all its devices on 7 June 2026 (Apple App Store adoption). iOS users update quickly; Android users are spread across many versions, which is why Android usually needs more devices. Real devices versus emulators is its own decision, covered in real devices, emulators or a device cloud.

1. Install, update and first launch

• Fresh install from TestFlight or the internal track, then first launch with no network.
• Update over the previous store version: users stay logged in, local data migrates, nothing is lost.
• Uninstall and reinstall: the app does not assume leftover data.
• Onboarding can be skipped and resumed; the splash screen never hangs.
• Low storage: the install and first sync fail with a clear message, not a crash.

2. Permissions

• Each permission (camera, location, notifications, photos, contacts) is asked for at the moment it is needed, with a clear reason.
• Deny each permission: the feature degrades gracefully and explains how to enable it later.
• Grant, then revoke in system settings while the app is in the background: the app copes on return.
• On iOS, every permission prompt has an accurate purpose string. Apple asks apps to "clearly and completely describe how your app will use the data" (Apple App Review).

3. Interruptions, background and rotation

Mobile apps are paused, killed and resized all the time. Most mobile-only bugs live here.

• Incoming call, alarm or notification in the middle of a form or a payment.
• Switch to another app for ten minutes, then return: the screen and its input are still there.
• Process death: the system kills the app in the background and the user returns to it.
• Rotate the screen, change dark mode or font size mid-task. On Android, a configuration change destroys and recreates the activity, and "the recreation also clears out any state kept as fields in the Activity" (Android configuration changes). Typed text vanishing on rotation is the classic result.
• Lock and unlock the device during a long upload.

4. Network: offline, slow and switching

• Start the app in airplane mode: it shows a clear offline state, not a blank screen.
• Lose the network halfway through a submit: no duplicate orders or payments when it returns.
• Slow 3G-like speeds: loaders appear, timeouts are handled, nothing freezes.
• Switch from Wi-Fi to mobile data during a request.
• Captive portal (hotel or airport Wi-Fi): the app does not treat the portal page as an API response.

5. Deep links, push notifications and payments

• Every deep link and universal link opens the right screen, logged in and logged out.
• Push notifications arrive with the app in the foreground, background and killed, and tapping them opens the right place.
• In-app purchases and subscriptions work in the store sandboxes: buy, cancel, restore, and renew.
• Payment failures and cancelled 3-D Secure screens return the user to a sensible state.

6. Accessibility

• Every control has a label that VoiceOver (iOS) and TalkBack (Android) read correctly.
• Large text and display zoom do not cut off buttons or hide content.
• Tap targets are big enough and not crowded together.
• Colour is not the only signal for errors or status.

Our accessibility testing checklist goes deeper on WCAG 2.2. An accessibility audit reports issues and fixes; it is not a certificate of legal compliance.

7. Performance, battery and stability

• Cold start time on the oldest device in your matrix.
• Long scrolling lists and image-heavy screens stay smooth.
• Memory: an hour of normal use without a crash on the low-memory phone.
• Battery and data use during background sync and location tracking.
• Crash reporting works: force a test crash in a staging build and confirm it reaches your dashboard.

8. Store rules and release hygiene

• Google Play: from 31 August 2026, new apps and updates must target Android 16 (API level 36) (Google Play target API requirement).
• Apple: the common rejection reasons include crashes and bugs, broken links, placeholder content, and missing review information such as a demo account (Apple App Review).
• Support and privacy policy links work inside the app.
• Screenshots and store text match what the build actually does.
• Debug menus, test endpoints and verbose logging are off in the release build.

How do you make these checks repeatable?

Several checklist items can be triggered from the command line instead of by hand, which makes them easy to repeat on every build. These use adb for Android (Android Debug Bridge) and xcrun simctl for the iOS Simulator. Replace com.example.app and the link with your own.

# Android: network off and on
adb shell svc wifi disable
adb shell svc data disable
adb shell svc wifi enable

# Android: larger font and dark mode mid-task
adb shell settings put system font_scale 1.3
adb shell cmd uimode night yes

# Android: process death (send the app to the background first)
adb shell am kill com.example.app

# Android: open a deep link
adb shell am start -W -a android.intent.action.VIEW -d "myapp://orders/42" com.example.app

# iOS Simulator: open a deep link and send a test push
xcrun simctl openurl booted "myapp://orders/42"
xcrun simctl push booted com.example.app push.apns

Simulators and emulators are fine for these checks on every pull request. The hardware items, such as camera, sensors, real memory limits and real networks, still need real devices before release.

How long does this checklist take to run yourself?

As a rough guide for a mid-size app with ten to twenty screens: one experienced tester needs two to four days for a full manual pass on four devices, and about one day for a focused regression pass on later releases. A first-time tester should allow about double. The main risk of doing it yourself is not time but blind spots: the person who built a feature tends to test the path they built, not the interruption in the middle of it. Write bug reports others can act on; our bug report template shows the fields that matter.

Buy, build or hire?

Option	Choose this when	Trade-off
A tool or SaaS testing platform (device cloud plus a framework)	Your developers have time to run the checklist and automate the repeatable parts	Cheap devices, but the checklist is only as good as the time people give it
Freelancers or crowdtesting	You want many devices and fresh eyes for a launch	Coverage is wide, depth and report quality vary
An in-house QA hire	You release weekly and mobile is your core product	Strong product knowledge; months to hire and one person's device shelf
A managed QAaaS team	You want the checklist run and owned on each release without hiring	You depend on a vendor; check that test assets and reports are yours

For what each option costs, see mobile app testing cost. For web releases, the matching list is our pre-launch QA checklist.

Why RAITHub for this

• Real devices and device clouds. RAITHub runs this checklist on iOS and Android, combining hands-on exploratory testing with automated suites.
• Reports developers can act on. Each bug comes with steps, device, OS version, build, expected and actual results, and a recording.
• Engineering habits. RAITHub's own web products run large automated suites, for example 1,024 tests on PropDesk and 750+ on TheSkinProof, the founder's own venture. There is no published mobile case study yet.
• Clear buying options. A fixed-price pre-launch audit, a monthly QA plan, or a dedicated team that RAITHub manages. It is not staff augmentation.

When you don't need us

• Your app has a handful of screens and one platform, and a developer can spend a day on this list before each release.
• You need the bugs fixed in native code. RAITHub tests mobile apps but does not develop them.
• You need a regulated device or medical certification test. That needs a certified lab.

How RAITHub would test this

• Scope: confirm your device matrix from analytics, the money journeys and which checklist sections apply.
• Manual pass: run all eight sections on real devices, with exploratory sessions on the riskiest screens.
• Automation: script the repeatable checks and the core journeys, run them on emulators per pull request and on a device cloud before release.
• Release sign-off: a written go or no-go with open bugs ranked by severity.
• What you receive: the tailored checklist, bug reports, any automated tests in your repository, and a handover note. IP is yours and an NDA is standard.

The scope, timeline and cost are set in a written fixed quote after a free 15-minute technical audit. See mobile app testing and the QA as a service overview, or ask for a pre-launch QA audit.

Frequently asked questions

What should a mobile app testing checklist include?

Install and update, permissions, interruptions and rotation, offline and slow networks, deep links, push and payments, accessibility, performance and battery, and the current App Store and Google Play rules. Run the core user journeys on every device in your matrix.

How many devices do I need to test a mobile app?

Four to eight is a reasonable start for one release: a current flagship, an older or low-memory phone, an unusual screen size, and a previous OS version on each platform. Adjust the list to your own analytics after launch.

Can I run this checklist on emulators only?

Partly. Emulators and simulators handle layout, rotation, deep links and network toggles well. Cameras, sensors, real memory pressure, battery and real networks need real devices, so run at least the final pass on hardware.

What gets apps rejected from the App Store most often?

Apple lists crashes and bugs, broken links, placeholder content, incomplete review information such as a missing demo account, and unclear explanations of why the app needs user data among the common issues.

What is the Google Play target API level in 2026?

From 31 August 2026, new apps and updates must target Android 16 (API level 36), with lower levels allowed for Wear OS, Android Automotive, Android TV and Android XR apps. Extensions to 1 November 2026 can be requested in Play Console.

Does RAITHub develop mobile apps?

No. RAITHub tests iOS and Android apps and reports what it finds with full reproduction steps. Your developers, or a mobile development studio, fix the code.