Mobile App Testing Checklist: What to Check Before Launch

What is a mobile app testing checklist?

A mobile app testing checklist is a written list of the tasks, conditions and standards an app must pass before release, with a pass or fail result for each. A checklist turns launch from a feeling into a decision backed by evidence.

A good checklist tests what customers actually do. A demo that works on fast Wi-Fi with a clean account does not show how the app behaves on a weak signal, after a phone call interrupts a payment, or when someone taps Submit three times.

A pass rate is not a launch decision. Ninety-five percent of tests passing means nothing if one failure exposes private data or charges a customer twice, so list your launch blockers before testing starts.

How should you prepare for testing before launch?

Prepare by deciding what you will test, on what, and who signs off, before the first test runs. Preparation stops testing from turning into an open-ended bug hunt.

• List the core customer tasks, such as sign up, book, pay, upload or message, and the business rules behind each one.
• Choose supported devices and OS versions based on your analytics or target market, including at least one older, lower-powered phone.
• Install the exact release build through TestFlight or a Google Play testing track, not a debug build.
• Create test accounts and data for every user role, plus a demo account for the store reviewers.
• Agree on launch blockers in writing and name the person who accepts any remaining risk.

A small internal app used by a few staff members does not need a large device list. Test on the phones those staff actually carry, and keep the rest of the preparation the same.

What should the pre-launch testing checklist cover?

The checklist should cover eight areas, each tested on the release build and on the devices you support. Work through them in order, and log every result with the device, OS version and build number.

1. Core functions and business rules: complete every customer task from start to finish, including edge cases such as expired cards, empty states, wrong inputs and duplicate taps on Submit or Pay.
2. Weak connections and interruptions: switch between Wi-Fi, mobile data and airplane mode mid-task, take a call, lock the screen and background the app, then confirm nothing is lost or duplicated.
3. Device and OS compatibility: test on small and large screens, the oldest and newest supported OS versions, and rotate each screen several times to check layout and state.
4. Performance under realistic use: measure cold start time, scrolling smoothness, memory use and battery drain on a mid-range phone with real data volumes.
5. Security and privacy: check that sensitive data is stored and sent securely, sessions expire, users cannot see each other's data, and permission requests explain why they are needed.
6. Usability and accessibility: check touch target sizes, color contrast, large text settings, and screen reader labels with VoiceOver and TalkBack.
7. Installs, updates and notifications: test a fresh install, an update over the previous version, and every notification type, including what happens when the user taps it.
8. Store submission requirements: confirm metadata, screenshots, privacy details, a working demo account, live back-end services and in-app account deletion if users can create accounts.

Google's Core App Quality guidelines give concrete Android targets: the app should load quickly or show a progress indicator if it takes longer than two seconds, should not crash or cause Android Not Responding errors, and should return users to their exact state when resumed from the Recents screen.

Which standards should your app meet?

Your app should meet the platform guidelines from Apple and Google plus a recognized security standard. The table lists the benchmarks we check on every launch and where each comes from.

Apple's accessibility guidelines list default and minimum control sizes per platform and use WCAG Level AA contrast values. Android's accessibility guidance recommends touch targets of at least 48dp and a contrast ratio of at least 4.5:1 for text smaller than 18sp. For security, the OWASP MASVS groups controls into storage, cryptography, authentication and authorization, network communication, platform interaction, code quality, resilience and privacy.

Most of these benchmarks are platform guidance rather than automatic rejection rules. Store review guidelines such as Apple's 2.1 are the exception, because missing them can block approval.

What should you check before App Store and Google Play submission?

Before submission, check that the build is final, complete and reviewable. Apple's App Store Review Guideline 2.1 asks for final versions with no placeholder text, apps tested on-device for bugs and stability, demo account details if the app has a login, and back-end services turned on.

• Remove all placeholder text, test screens and debug menus.
• Provide a working demo account and notes for the reviewer.
• Make sure every in-app purchase is complete, visible and working.
• Offer account deletion inside the app if users can create accounts, as Apple's guideline 5.1.1(v) requires.
• Complete privacy details and data safety forms so they match what the app actually collects.
• For a new Google Play personal account, finish the required closed test before applying for production access.

Apple's App Review page notes that over 40% of unresolved issues relate to guideline 2.1, App Completeness. A careful pre-submission pass is the simplest way to avoid a rejection that pushes back your launch date. Our guide to the mobile app development timeline explains how to plan review time into launch.

Which failures should delay launch?

Delay launch for any failure that harms users' data, money or ability to complete the core task. Cosmetic issues can usually ship with a fix scheduled, but these cannot.

• Private data visible to the wrong user, or sent or stored without protection.
• Wrong or duplicate charges, bookings or orders.
• Crashes or freezes in a core task on any supported device.
• Data lost after an interruption, update or connection drop.
• Login or account recovery that fails for some users.
• A core task that cannot be completed with a screen reader or large text.

Record every result with steps to reproduce, the device and build, and a severity rating. After a fix, retest the original failure and the related tasks around it, because fixes often break nearby features.

Prioritizing by severity keeps a long issue list manageable. On our StatSpray website project, critical technical issues fell from 64 to 5, or 92% resolved, in about three months. Results vary, and app projects follow the same rule: fix what blocks users first.

How does DesignFXPro test apps before launch?

DesignFXPro treats QA and launch as its own stage in every app project, covering device testing and App Store and Google Play submission through to approval. Testing follows the Discover, Strategize, Execute and Optimize process we have used across 300+ projects in 15+ countries.

• Discover: we define the core customer tasks, supported devices and launch blockers with you at the start.
• Strategize: we turn them into a written test plan with clear owners and sign-off rules.
• Execute: we test the release build on real devices, fix issues and prepare the store submission.
• Optimize: after launch we monitor crashes and user behavior and ship updates for new OS versions.

To plan testing for your own release, book a free consultation with DesignFXPro. Learn more on our mobile app development services page, or see how we test designs before code in our UI/UX design services and our usability testing guide. If you have not chosen a build approach yet, read native vs hybrid apps first.

Common mistakes in mobile app testing

Most testing mistakes come from testing in ideal conditions. These are the ones DesignFXPro sees most often.

• Testing only on the newest flagship phones with fast Wi-Fi.
• Testing a debug build instead of the exact build that goes to the stores.
• Checking screens one by one instead of complete customer tasks.
• Skipping accessibility checks until a user complains.
• Forgetting the update path, so existing users lose data when the new version installs.
• Assuming store approval means the app is ready; store review does not replace your own QA.