>_ Mobile App Testing Checklist

Short answer

A Mobile App Testing Checklist is a list of checks for native mobile apps on iOS and Android. It helps make sure that the app installs, launches, updates, does not crash, works correctly on different devices and OS versions, and handles permissions, push notifications, deep links, offline mode, app lifecycle, login, payments, analytics, and production release behavior.

Mobile app testing is especially important for consumer apps, SaaS mobile apps, e-commerce apps, fintech apps, health apps, booking apps, marketplaces, delivery apps, internal mobile tools, and any product where users interact through an iOS or Android application.

A good mobile app testing checklist does not stop at checking whether "the app opens." It should cover install, first launch, onboarding, login, permissions, app navigation, forms, offline behavior, background / foreground behavior, interruptions, push notifications, deep links, crashes, performance, battery, memory, app updates, store builds, and release smoke testing.

The main idea is: mobile app testing should confirm that users can install the app, complete the key flow, and keep using the app in real mobile conditions: different devices, networks, OS versions, and app states.

This guide can also be used as a native app testing checklist, iOS app testing checklist, Android app testing checklist, mobile QA checklist, app release checklist, or mobile app smoke checklist for product, QA, and release teams.

Mobile App Testing vs Mobile Web Testing

Mobile app testing and mobile web testing are related, but they are not the same thing.

Mobile web testing checks websites and web applications in a mobile browser:

• responsive layout;
• mobile Safari;
• mobile Chrome;
• mobile navigation;
• mobile forms;
• browser autofill;
• mobile checkout;
• viewport behavior;
• web performance.

Mobile app testing checks native iOS and Android applications:

• app installation;
• first launch;
• app updates;
• device permissions;
• push notifications;
• app lifecycle;
• background / foreground behavior;
• offline mode;
• native navigation;
• crashes;
• App Store / Google Play builds;
• OS and device compatibility.

In simple terms: mobile web testing checks the browser version of a product, while mobile app testing checks the installed application on a device.

When to use a Mobile App Testing Checklist

Use this checklist before every mobile app release or after changes that may affect app behavior.

For example:

• a new iOS or Android app is launching;
• a new app version is being released;
• onboarding is added;
• signup or login changes;
• push notifications are added;
• deep links are added;
• navigation changes;
• offline mode is added;
• data sync changes;
• permissions are added: camera, location, photos, microphone, contacts;
• payment or in-app purchase changes;
• subscription flow changes;
• API is updated;
• crash reporting or analytics changes;
• app build configuration changes;
• the app is being prepared for App Store or Google Play release;
• there was a production crash or mobile incident;
• supported OS version is changing;
• tablet support is added.

For a small bug fix, a mobile app smoke test may be enough. For a new app, major release, payment flow, offline mode, push notifications, or app store release, it is better to go through the full mobile app testing checklist.

Short Mobile App Testing Checklist

If you need a minimal mobile app smoke test, check that:

• the app installs;
• the app launches;
• first launch does not crash;
• onboarding works;
• signup or login works;
• logout works;
• main navigation works;
• the main user flow works end-to-end;
• permissions are requested at the right moment;
• push notification works, if critical;
• deep link opens the correct screen, if used;
• offline or poor network state is handled clearly;
• the app correctly goes to background and returns to foreground;
• the app does not crash during basic usage;
• key screens work on iOS and Android;
• key screens work on different screen sizes;
• analytics events are sent, if important;
• crash reporting is connected;
• app update does not break an existing user;
• release build does not contain test data;
• production mobile app smoke check has passed after release.

This is not full mobile app QA. It is a minimal check that helps quickly understand whether the team can continue testing or move the build further toward release.

Mobile App Testing Checklist

1. Define the mobile app testing scope

Before testing starts, define which app version, platform, and functionality need to be checked.

Check that:

• the app version being tested is clear;
• iOS, Android, or both platforms are included in scope;
• supported devices are known;
• supported OS versions are known;
• critical user flows are defined;
• changed features are known;
• features outside scope are known;
• login or signup is included, if available;
• payments or in-app purchases are included, if available;
• push notifications are included, if available;
• offline mode is included, if available;
• deep links are included, if available;
• permissions are included, if available;
• tablet support is included, if available;
• backend/API changes are known;
• the person responsible for pass / fail decision is known.

The main question is: what should the user be able to do in the mobile app after this release?

2. Prepare the device and OS matrix

Mobile app testing cannot be done well on only one device.

Check that the device matrix includes:

• at least one iPhone device;
• at least one Android device;
• a small-screen device;
• a large-screen device;
• an older supported iOS version;
• the latest supported iOS version;
• an older supported Android version;
• the latest supported Android version;
• a low-end or mid-range Android device, if the audience uses them;
• a tablet, if supported;
• portrait mode;
• landscape mode, if supported;
• stable Wi-Fi;
• mobile network;
• slow or unstable network for key flows.

The device matrix does not need to be endless. It is better to choose a few real combinations that cover the main audience and highest-risk scenarios: iPhone, Android, small screen, large screen, old OS, latest OS, slow network, and critical user flow.

3. Check build and installation

Before deeper testing starts, make sure the app build installs correctly.

Check that:

• the correct build is installed;
• build version is displayed correctly, if available;
• the app installs on iOS;
• the app installs on Android;
• the app does not crash immediately after installation;
• app icon is displayed;
• app name is correct;
• splash screen is displayed;
• app launches after installation;
• release build does not contain debug labels;
• release build does not contain test environment banners;
• app is connected to the correct backend environment;
• app can be deleted;
• app can be reinstalled.

If the build does not install or launches with the wrong configuration, deeper testing may be useless.

4. Check first launch

First launch is the user's first experience after installing the app.

Check that:

• app opens after installation;
• app does not crash on splash screen;
• loading state is displayed;
• first screen loads;
• user understands what to do next;
• onboarding starts, if expected;
• permission prompts do not appear too early without context;
• app does not show an empty or broken state;
• app does not require login without explanation;
• app correctly handles no network on first launch;
• app does not contain test copy;
• app does not show staging data.

First launch should be stable and clear. If the user gets stuck on the first screen, all other features become irrelevant.

5. Check onboarding flow

Onboarding helps the user understand the product and start using the app.

Check that:

• onboarding opens for a new user;
• onboarding steps appear in the correct order;
• user can move to the next step;
• user can skip onboarding, if expected;
• user can go back, if expected;
• copy is clear;
• images or animations do not break layout;
• CTA buttons work;
• permissions are requested at the right moment;
• onboarding does not repeat without reason;
• onboarding saves progress if it is long;
• onboarding leads to the correct next step;
• onboarding works on small screens.

Onboarding should not be only decorative. It should help the user start the key scenario.

6. Check signup, login, and logout

Authentication in a mobile app should be stable because users often return to the app many times.

Check that:

• signup works;
• login works;
• logout works;
• invalid password shows a clear error;
• password reset works;
• email verification works, if available;
• social login works, if available;
• SSO works, if available;
• biometric login works, if available;
• session remains active after app restart;
• session remains active after background / foreground;
• expired session is handled clearly;
• user can log in again after session expiration;
• private screens are unavailable after logout;
• user does not see someone else's data.

For deep authentication testing, use a separate Login and Authentication Testing Checklist. In mobile app testing, confirm that the auth flow works in real app lifecycle scenarios.

7. Check app navigation

Navigation should be clear, stable, and predictable.

Check that:

• bottom navigation works;
• tabs work;
• side menu works, if available;
• back button works;
• Android system back button works correctly;
• iOS swipe back works, if supported;
• user does not end up in a dead end;
• active screen is clear;
• user can return to the main screen;
• navigation does not create duplicate screens;
• deep navigation stack works;
• navigation saves state, if expected;
• logout or session expiration does not break navigation.

Mobile navigation should respect platform expectations. Android back behavior and iOS navigation gestures should be tested separately.

8. Check the main user flow

Start with the main scenario of the app.

For example:

• user signs up;
• creates an object;
• submits a request;
• places an order;
• completes a payment;
• books a service;
• uploads a file;
• sends a message;
• views a dashboard;
• receives a notification;
• completes the key action.

Check that:

• main flow works end-to-end;
• user sees the expected result;
• data is saved;
• status is updated;
• app does not crash;
• loading states are clear;
• errors are clear;
• user can go back;
• result remains after app restart;
• result syncs with backend;
• result is visible in account or history, if needed.

The main question is: can the user complete the key action in the app without help from the team?

9. Check forms and input fields

Forms in mobile apps should work with touch, native keyboard, autofill, and validation.

Check that:

• fields are accessible;
• labels are readable;
• required fields work;
• optional fields can be left empty;
• validation works;
• errors are clear;
• keyboard does not cover the active field;
• correct keyboard type opens for email, phone, and number fields;
• autocorrect does not break email or username;
• password manager works, if applicable;
• one-time code autofill works, if used;
• dropdowns or pickers work;
• date picker works;
• entered data is not lost after an error;
• submit button is available;
• success state is displayed.

Mobile forms often break not because of backend issues, but because of keyboard behavior, focus, small screens, and native input behavior.

10. Check permissions

Mobile apps often use permissions: camera, photos, location, microphone, contacts, notifications, Bluetooth, files.

Check that:

• permission is requested at the right moment;
• user understands why the permission is needed;
• system permission prompt is displayed;
• allow scenario works;
• deny scenario is handled clearly;
• denied permission does not break the app;
• user sees an explanation if the feature requires permission;
• user can open settings to enable permission, if needed;
• permission is not requested too early;
• permission is not requested repeatedly without reason;
• app works with limited photos access, if important;
• location permission works in the required mode;
• background permission is requested only if truly needed.

Permissions should be tested in both scenarios: user allowed and user denied. Deny flow often breaks more often than the happy path.

11. Check push notifications

Push notifications are an important part of the mobile app experience, but they depend on OS permissions, token registration, backend, and app state.

Check that:

• app requests notification permission;
• allow scenario works;
• deny scenario is handled;
• push token is registered;
• notification is delivered;
• notification text is correct;
• notification icon is correct;
• tapping the notification opens the correct screen;
• notification works when the app is closed;
• notification works when the app is in background;
• notification works when the app is in foreground, if expected;
• notification is not duplicated without reason;
• user can disable notifications;
• notification respects user preferences.

Push notification testing should not stop at "was it delivered?" The user should land in the correct context after tapping it.

12. Check deep links and universal links

Deep links help open a specific screen in the app from email, push notification, browser, ad, or another app.

Check that:

• deep link opens the app;
• universal link works on iOS, if used;
• app link works on Android, if used;
• link opens the correct screen;
• link works if the app is installed;
• link leads to fallback page if the app is not installed;
• link works for logged-in user;
• link handles unauthenticated user;
• after login, user lands on the intended screen;
• invalid link shows a clear state;
• expired link is handled;
• link does not open someone else's data;
• push notification deep link works.

Deep links are especially important for onboarding, password reset, email verification, push notifications, marketing campaigns, and shared content.

13. Check app lifecycle: background and foreground

A mobile app can go to background, return to foreground, be closed by the OS, or be restarted.

Check that:

• app correctly goes to background;
• app returns from background;
• current screen is preserved, if expected;
• entered form data is preserved, if important;
• loading state recovers;
• app does not crash after resume;
• session remains active if it has not expired;
• expired session is handled after resume;
• app reconnects after network change;
• sensitive screen is hidden in app switcher, if important;
• app works after force close and relaunch;
• app does not create duplicate actions after resume.

App lifecycle bugs often appear in checkout, forms, payment, chat, media, navigation, and long-running operations.

14. Check interruptions

A real user may receive a call, notification, low battery alert, or switch to another app.

Check that:

• incoming call does not break the app;
• system notification does not break the current flow;
• user can return after switching apps;
• keyboard state recovers;
• form data is not lost;
• payment or checkout does not create duplicate action;
• media pause/resume works, if there is media;
• location tracking behaves according to rules;
• upload/download handles interruption;
• app does not crash after interruption.

Interruption testing is especially important for payments, booking, chat, upload, onboarding, and long forms.

15. Check offline mode

If the app supports offline mode, it should be tested separately.

Check that:

• app shows offline state;
• cached data is available, if expected;
• user understands which actions are available offline;
• unavailable actions are disabled or explained;
• user can create a draft offline, if supported;
• offline actions are saved locally;
• sync starts after network returns;
• sync conflicts are handled;
• user sees sync status;
• duplicate data is not created after sync;
• app does not lose offline changes;
• app does not crash without network.

Offline mode should not look like a broken app. The user should understand what is happening and what will sync later.

16. Check poor network and network switching

Even if offline mode is not supported, the app should handle weak network conditions properly.

Check that:

• slow network shows loading state;
• timeout shows a clear error;
• retry works;
• form data is not lost after network error;
• app does not get stuck on endless loader;
• app handles switching from Wi-Fi to mobile data;
• app handles switching from mobile data to Wi-Fi;
• API errors are displayed clearly;
• images load progressively;
• user can continue after network is restored;
• duplicate submit is not created after retry.

Poor network testing is a required part of mobile app QA because users are rarely in perfect network conditions.

17. Check data sync

If the app syncs data with backend, consistency should be checked carefully.

Check that:

• created data syncs;
• updated data syncs;
• deleted data syncs;
• sync status is clear;
• sync works after app restart;
• sync works after background / foreground;
• sync works after offline changes;
• conflicts are handled;
• duplicate records are not created;
• stale data updates;
• user sees current data after refresh;
• data matches between mobile app and web/admin/backend, if important.

Data sync is especially important for offline-first apps, CRM, field service apps, delivery apps, notes, tasks, dashboards, and collaboration products.

18. Check device compatibility

The app should work on supported devices and screen sizes.

Check that:

• app works on small screen;
• app works on large screen;
• app works on tablet, if supported;
• layout does not break on different aspect ratios;
• notch and safe areas are handled;
• status bar does not cover content;
• bottom system navigation does not cover CTA;
• fonts are readable;
• touch targets are comfortable;
• images are not stretched;
• key flow works on different devices.

Device compatibility is especially important for Android, where device fragmentation is higher.

19. Check OS compatibility

The app should work on supported OS versions.

Check that:

• app works on minimum supported iOS;
• app works on latest iOS;
• app works on minimum supported Android;
• app works on latest Android;
• OS-specific permissions work;
• OS-specific UI behavior does not break the app;
• push notifications work on supported OS versions;
• background behavior works;
• biometric login works, if available;
• media, camera, location, or files work;
• there is no OS-specific crash;
• deprecated OS behavior is handled, if important.

OS compatibility should be reviewed after major iOS or Android updates.

20. Check orientation and screen rotation

If the app supports multiple orientations, they should be tested.

Check that:

• portrait mode works;
• landscape mode works, if supported;
• layout reflows correctly;
• current state is preserved;
• form data is not lost;
• media behavior is correct;
• modals do not break;
• keyboard does not break layout;
• navigation remains available;
• orientation lock works if the app should be portrait-only;
• app does not crash after rotation.

Even if the app is mostly portrait-only, this behavior should be intentional and stable.

21. Check native gestures

Mobile users expect gestures to behave naturally.

Check that:

• tap works;
• long press works, if used;
• swipe works, if used;
• pull to refresh works, if available;
• pinch to zoom works, if supported;
• drag and drop works, if available;
• iOS swipe back works, if supported;
• Android back gesture works;
• gestures do not conflict with each other;
• accidental gestures do not trigger destructive actions;
• gesture has an alternative control if the action is critical.

Gestures should help the user, not be the only hidden way to perform a critical action.

22. Check native UI components

Native mobile UI should be understandable and match platform expectations.

Check that:

• action sheets work;
• bottom sheets work;
• alerts work;
• toasts or snackbars are clear;
• date picker works;
• time picker works;
• dropdown or picker works;
• tabs work;
• segmented controls work;
• native sharing works, if available;
• loading indicators are clear;
• empty states are clear;
• error states are clear.

Native components should be not only visually correct, but also usable on each platform.

23. Check app content and localization

If the app supports several languages or regions, localization should be tested separately.

Check that:

• app language is detected correctly;
• language switch works, if available;
• translated text is displayed;
• long translated strings do not break layout;
• dates are displayed in the correct format;
• time is displayed in the correct format;
• numbers are displayed correctly;
• currency is displayed correctly;
• right-to-left layout works, if supported;
• untranslated keys are absent;
• placeholder text is absent;
• push notifications are localized, if needed.

Localization bugs often look like UI bugs: text is cut off, a button disappears, or layout breaks.

24. Check payments and in-app purchases, if applicable

Mobile app payments may use regular checkout, an external payment provider, or App Store / Google Play in-app purchases.

Check that:

• payment screen opens;
• price is displayed correctly;
• currency is correct;
• test purchase succeeds;
• failed purchase is handled clearly;
• canceled purchase is handled;
• user receives paid access after successful purchase;
• user does not receive paid access after failed purchase;
• subscription is created if there is a subscription;
• subscription status is correct;
• restore purchases works, if needed;
• receipt validation works, if used;
• purchase is not duplicated after retry;
• confirmation state is clear.

For deep payment QA, use a separate Payment Testing Checklist. In mobile app testing, confirm that payment flow works in the native app context.

25. Check camera, photos, and file access

If the app works with media or documents, these flows should be checked on real devices.

Check that:

• camera permission is requested;
• user can take a photo;
• user can select a photo from gallery;
• limited photo access works, if important;
• user can upload a file;
• unsupported file type is handled;
• large file is handled;
• upload progress is displayed;
• upload error shows a clear message;
• uploaded file is displayed;
• file is available to the correct user;
• denied permission is handled clearly.

Camera, photos, and files often behave differently on iOS and Android.

26. Check location features, if applicable

Location features require special attention to permissions, accuracy, and battery usage.

Check that:

• location permission is requested at the right moment;
• approximate location works, if the OS supports it;
• precise location works, if needed;
• denied permission is handled;
• user can enable permission in settings;
• current location is detected;
• map opens;
• location updates work, if needed;
• background location works only if expected;
• app explains why location is needed;
• app does not drain battery excessively;
• no location state is handled.

Location testing is better done on a real device, not only in a simulator.

27. Check biometric login, if applicable

Biometric login may use Face ID, Touch ID, or Android biometrics.

Check that:

• user can enable biometric login;
• biometric prompt appears;
• successful biometric login works;
• failed biometric attempt is handled;
• fallback to password works;
• biometric unavailable state is handled;
• user can disable biometric login;
• logout behavior is clear;
• biometric does not bypass required security rules;
• app does not show sensitive data before successful authentication.

Biometric login is convenient, but it should be tested as a security-sensitive feature.

28. Check security basics

Mobile app testing does not replace a security audit, but basic security checks are needed.

Check that:

• sensitive screens require authentication;
• private data is not visible after logout;
• app does not show sensitive data in app switcher, if important;
• tokens are not displayed in logs;
• credentials are not stored insecurely;
• API calls use HTTPS;
• certificate errors are not ignored without reason;
• user cannot open someone else's data through deep link;
• permissions are checked on the backend;
• debug logs are not enabled in release build;
• test API keys are not used in production build;
• app does not contain test user credentials;
• local storage does not contain sensitive data without protection.

For fintech, healthcare, enterprise apps, and apps with personal data, this section should be much deeper.

29. Check privacy and consent

Mobile apps often collect personal data, device data, location, analytics data, and notification permissions.

Check that:

• privacy notice is available;
• terms are available, if needed;
• consent screen is displayed, if needed;
• analytics consent works, if used;
• marketing consent works, if available;
• user can change preferences;
• app does not request unnecessary permissions;
• permission purpose is clear;
• denied consent is handled;
• personal data is not sent to unnecessary systems;
• delete account or data request flow works, if expected.

QA does not replace legal review, but it should check that agreed privacy elements are displayed and working.

30. Check accessibility basics

A mobile app should be usable for different users.

Check that:

• screen reader basics work;
• buttons have clear names;
• form fields have labels;
• touch targets are large enough;
• text is readable;
• contrast is acceptable;
• dynamic font size does not break layout, if supported;
• error messages are clear;
• focus order is logical for assistive technologies;
• images have descriptions, if important;
• gestures have alternative controls if the action is critical;
• user can complete the key flow with basic accessibility settings.

For a full accessibility review, run a separate accessibility pass, but basic checks should be part of mobile app QA.

31. Check performance

Mobile app performance affects retention, conversion, and user trust.

Check that:

• app starts fast enough;
• splash screen does not stay too long;
• screens open quickly;
• lists scroll smoothly;
• images load acceptably;
• forms respond quickly;
• search does not freeze;
• checkout does not freeze;
• background operations do not block UI;
• app does not slow down after long usage;
• app does not overheat the device;
• app works acceptably on a mid-range device.

Performance should not be checked only on a new flagship device.

32. Check memory, battery, and resource usage

A mobile app can be functionally correct but too heavy for the device.

Check that:

• app does not use too much memory;
• app does not crash after long usage;
• app does not create memory leaks in key flows;
• image-heavy screens do not cause crash;
• app does not drain battery excessively;
• background activity does not run without reason;
• location, Bluetooth, or media does not remain active unnecessarily;
• app does not overload CPU;
• app remains responsive after repeated navigation.

This section is especially important for apps with maps, camera, video, chat, background sync, or long sessions.

33. Check crashes, ANR, and error reporting

App stability is one of the main criteria for mobile app readiness.

Check that:

• app does not crash on launch;
• app does not crash in the main flow;
• app does not crash during login/logout;
• app does not crash on network error;
• app does not crash after background/foreground;
• app does not crash after orientation change;
• app does not crash with large data;
• Android does not show ANR in key flows;
• crash reporting is connected;
• crash report contains useful diagnostics;
• error reporting does not contain sensitive data;
• release build sends crash reports to the correct project.

Even one crash in a critical flow can be a blocker for mobile app release.

34. Check analytics and event tracking

Mobile analytics helps understand activation, retention, conversion, and crashes.

Check that:

• app open event is sent;
• signup event is sent;
• login event is sent;
• onboarding completed event is sent, if used;
• key action event is sent;
• purchase event is sent, if purchases exist;
• push opened event is sent, if needed;
• events are not duplicated;
• user ID or anonymous ID works according to rules;
• UTM or campaign attribution is preserved, if used;
• events are sent after offline usage, if expected;
• analytics does not send sensitive data;
• events are sent to the correct environment.

Analytics should not hurt app performance, but critical events should be correct.

35. Check app update flow

App update is a separate important scenario. Users do not always install the app from scratch.

Check that:

• app updates from the previous version;
• user remains logged in after update, if expected;
• local data is preserved;
• settings are preserved;
• cached data updates correctly;
• in-app database migration works;
• old data does not break the new version;
• new feature appears after update;
• deprecated data is handled;
• app does not crash after update;
• forced update flow works, if available;
• optional update message works, if available.

Update testing often finds bugs that do not appear during clean install.

36. Check uninstall / reinstall behavior

Uninstalling and reinstalling the app can affect account, cache, and local data.

Check that:

• app can be uninstalled;
• app can be installed again;
• app launches after reinstall;
• local data is cleared or preserved according to platform and product rules;
• user can log in after reinstall;
• push token is updated;
• cached data does not create incorrect state;
• old deep links continue to work;
• user does not receive duplicate notifications after reinstall.

Uninstall/reinstall is especially important for push notifications, local storage, authentication, and offline data.

37. Check App Store / Google Play readiness

Before release, check not only app functionality but also store readiness.

Check that:

• app name is correct;
• app icon is correct;
• version number is correct;
• build number is correct;
• release notes are ready;
• screenshots are up to date;
• store description is up to date;
• privacy information is filled in;
• permissions match app functionality;
• app does not contain test content;
• app is not connected to staging backend;
• production API keys are used correctly;
• crash reporting and analytics are configured for production;
• app review requirements are considered;
• internal testing / beta testing is complete.

Store readiness is part of release QA. The app may work correctly but still be rejected or represented incorrectly in the store.

38. Run release build smoke test

Release build may differ from debug build. It should be tested separately.

Check that:

• release build installs;
• release build launches;
• no debug menu is visible if it should not be;
• there are no staging labels;
• there are no test credentials;
• correct backend environment is used;
• login works;
• main flow works;
• push notifications work, if critical;
• deep links work, if critical;
• payment or in-app purchase works, if critical;
• analytics is sent to the correct project;
• crash reporting works;
• app does not crash in the main flow.

Do not rely only on debug build. Before publishing, test the actual release candidate.

39. Run production mobile app smoke after release

After publication or rollout, run a short production check.

Check that:

• app is available for installation;
• correct version is available;
• app opens after installation;
• app opens after update;
• login works;
• main flow works;
• push notification works, if critical;
• deep link works, if critical;
• purchase works, if critical;
• production backend works;
• analytics receives events;
• crash reporting does not show a spike;
• ratings/reviews do not show a widespread issue;
• support team knows where to check mobile issues.

Production smoke should be short and safe. Its goal is to make sure real users can install, open, and use the app after release.

Common mistakes

1. Testing on only one device

One device does not show the full picture. Android fragmentation, iOS versions, screen sizes, and OS-specific behavior can create different bugs.

2. Testing only clean install

Clean install is important, but update flow often breaks more often. Users usually update the app instead of installing it from scratch.

3. Ignoring poor network

Mobile users often work on unstable connections. The app should handle slow network, timeout, reconnect, and offline states.

4. Not testing app lifecycle

The app may work while active, but break after background, foreground, force close, relaunch, or interruption.

5. Not testing denied permissions

A user may deny camera, location, photos, or notification permissions. The app should explain what to do next instead of breaking.

6. Not testing push notification tap behavior

It is important not only to receive a push notification, but also to open the correct screen after tapping it.

7. Not testing deep links

Deep links often break in unauthenticated state, after app update, with expired links, or on different OS versions.

8. Testing only debug build

Debug build and release build may differ in environment, analytics, crash reporting, permissions, optimization, and store configuration.

9. Not checking crash reporting

If the app crashes but crash reporting is not configured, the team may not know about a production problem in time.

10. Not running production smoke after release

A mobile release can pass QA, but production issues may appear after rollout because of store build, backend, push settings, analytics, or production configuration.

FAQ

What is a Mobile App Testing Checklist?

A Mobile App Testing Checklist is a list of checks for native iOS and Android applications. It helps test installation, first launch, onboarding, login, permissions, push notifications, deep links, offline mode, app lifecycle, device compatibility, OS compatibility, performance, crashes, analytics, and release readiness.

How is mobile app testing different from mobile web testing?

Mobile app testing checks an installed native app on iOS or Android.

Mobile web testing checks a website or web app in a mobile browser, such as Safari or Chrome.

What should be checked in mobile app testing?

At minimum, check:

• install;
• first launch;
• onboarding;
• signup / login / logout;
• main user flow;
• navigation;
• forms;
• permissions;
• push notifications;
• deep links;
• offline or poor network behavior;
• background / foreground;
• device compatibility;
• OS compatibility;
• app update;
• crashes;
• analytics;
• release build;
• production smoke.

Do you need to test on real devices?

Yes. Simulators and emulators are useful, but real devices show touch behavior, performance, camera, photos, push notifications, biometrics, battery, network switching, and OS-specific issues more accurately.

Which devices should be included in mobile app testing?

At minimum, test:

• one iPhone;
• one Android device;
• small screen;
• large screen;
• older supported OS;
• latest supported OS;
• low-end or mid-range Android device, if important for your audience.

If the app supports tablets, add a tablet scenario.

How do you test a mobile app update?

Test update from the previous version to the new one:

• app updates successfully;
• user remains logged in, if expected;
• local data is preserved;
• settings are preserved;
• migrations work;
• new features are available;
• app does not crash after update.

Update flow should be tested separately from clean install.

How do you test push notifications?

Check:

• permission prompt;
• allow and deny scenarios;
• notification delivery;
• notification content;
• app behavior after tap;
• foreground behavior;
• background behavior;
• closed app behavior;
• notification preferences;
• no duplicate notifications.

How do you test offline mode?

Check that:

• app shows offline state;
• cached data is available;
• unavailable actions are explained;
• offline actions are saved, if supported;
• sync works after reconnect;
• conflicts are handled;
• duplicate data is not created;
• app does not crash without network.

What is a mobile app smoke test?

A mobile app smoke test is a short check of a build or release candidate.

It usually includes:

• install;
• launch;
• login;
• main flow;
• permissions;
• push or deep link, if critical;
• no crash;
• analytics/crash reporting;
• production environment check.

Smoke test does not replace full QA, but it helps quickly understand whether the build is usable.

How do you know a mobile app is ready for release?

A mobile app can be considered ready for release when:

• app installs;
• app launches;
• onboarding works;
• login works;
• main user flow works;
• permissions are handled;
• push notifications work, if critical;
• deep links work, if critical;
• app lifecycle is stable;
• poor network is handled;
• update flow works;
• release build is checked;
• crash reporting is connected;
• analytics events are sent;
• there are no blocker or critical bugs;
• production mobile app smoke has passed after release.