Mobile App Testing Checklist for Real Devices and States
By SayCraft Team · 2026-08-19 · 11 min read
A mobile app testing checklist should cover the declared device and OS matrix, real lifecycle changes, input methods, accessibility, connectivity, and recovery. Record the smallest and largest supported screens, orientation or adaptive layouts, touch and keyboard behavior, text scaling, screen readers, permissions, network transitions, background and resume, interruptions, sessions, persistence, links, notifications, and install or update paths that are actually in scope. Combine static analysis, automation, manual real-device checks, and representative user testing because each finds different problems. “Works in the simulator” is useful evidence for one environment, not proof across the support range.
Device and OS matrix
| Dimension | Record and test |
|---|---|
| Platform | Supported iOS/iPadOS/Android versions; label platform-only checks |
| Hardware | Smallest and largest supported phone; representative tablet/foldable if in scope |
| Window | Portrait, landscape, resizing or split-screen where supported |
| Input | Touch, hardware keyboard, switch/screen-reader navigation where in scope |
| Display | Text scaling, contrast, light/dark theme if supported, localization expansion |
| Network | Offline, slow, interrupted, switching Wi-Fi/cellular, retry and duplicate prevention |
Core mobile checklist
- Install and update: clean install, upgrade with existing data, first launch, storage limits, and rollback policy where applicable.
- Permissions: first request, denial, later grant/revoke, limited access, and a useful fallback.
- Background and resume: preserve or safely reset forms, uploads, timers, authentication, and navigation after interruption.
- Interruptions: calls, alarms, app switch, lock/unlock, process termination, and low-resource recovery relevant to the workflow.
- Authentication and persistence: expiry, sign-out, account switch, biometric cancellation if used, and protected cached data.
- Links and notifications: valid, expired, malformed, signed-out, and wrong-account destinations if those features exist.
- Accessibility: labels, reading order, visible focus, target size, text scaling, error association, and meaningful announcements.
Platform-specific checks
| Platform | Only apply when | Checks |
|---|---|---|
| iOS / iPadOS | That platform and feature are in scope | Permission changes through Settings, Dynamic Type, VoiceOver, scene background/resume, universal links, supported install/update path, and iPad layout where declared. |
| Android | That platform and feature are in scope | Runtime permission changes, font and display scale, TalkBack, activity or process recreation, app links, adaptive layouts, system back behavior, and supported update path. |
| Shared | Both platforms are supported | Run the same user outcome on each platform, but do not assume permission, lifecycle, navigation, or assistive-technology semantics are identical. |
Use multiple testing methods
| Method | Best used for | Does not cover alone |
|---|---|---|
| Static analysis | Known API and accessibility patterns | Runtime interaction and real hardware behavior |
| Automated tests | Repeatable logic and regression paths | Unexpected usability and device-context issues |
| Manual real-device test | Lifecycle, permissions, hardware, assistive technology | Broad repeatability across every release |
| Representative user test | Comprehension and task behavior | Technical coverage or population-wide proof |
Turn important items into repeatable test cases and keep business acceptance in the UAT plan.
Sources used for this guide
Turn the document into something testable
Use the checklist to define the mobile states the first preview must demonstrate. A web preview can validate flow and layout, but native lifecycle and platform behavior still require the relevant device build.
Frequently asked questions
What should I test in a mobile app?
Test the supported device and OS matrix, screen sizes and orientation, touch and keyboard input, accessibility, permissions, network changes, background and resume, interruptions, authentication, persistence, deep links, notifications if used, and install or update behavior.
Can automated testing replace real-device testing?
No. Automation and analysis tools are valuable, but real devices and user testing reveal runtime, hardware, assistive-technology, interruption, and context problems that tools alone may miss.