13 Key Mobile App Testing Challenges and Solutions [2026]

13 Key Mobile App Testing Challenges

Most of these challenges come from variables that desktop web tests rarely face: the OS version and manufacturer skin on the phone, its screen density, the cellular network it is on, and the hardware the app calls. The list starts at the device and OS layer and moves up through the app, the release process, and the test suite itself.

1. Device and OS Fragmentation

Android devices in use run many OS versions at the same time. StatCounter's September 2026 Android version data shows Android 13 still on 11.6% of Android phones and tablets worldwide and Android 11 on 6.35%.

StatCounter's iOS version data for the same month shows iOS 26.6 on 56.35% of iOS phones and tablets worldwide.

iOS testing can therefore center on fewer versions than Android testing, though older iPhones still stay on earlier releases. The iOS version fragmentation guide covers which of them to keep in the matrix.

Each OS version changes behavior your tests rely on, such as permissions, background limits, and the WebView engine. The notification prompt above is one example: Android 11 and 12 never showed it, and all five devices on Android 13 or later did.

• Build the matrix from your analytics - export the device models and OS versions behind your sessions from your analytics or store console, and cover the versions that hold most of your users.
• Keep devices on both sides of each behavior change - one phone on Android 12 or older and one on Android 13 or newer catches the notification permission difference before users do.
• Retest when a new OS ships - run the full suite on the newest Android and iOS release as soon as devices with it are available, before most of your users update.

2. Screen Sizes, Densities, and Foldables

No single screen size covers most phones. StatCounter's mobile screen resolution stats for September 2026 put the most common resolution, 414x896, at a 13.35% share worldwide.

Pixel counts alone hide part of the problem. In the seven-device run, the Oppo A54 and the Moto G22 both have 720x1600 panels, but at 320 and 280 dpi Android gave the app 360 dp and 411 dp of width, so the same layout had 51 dp more room on the Motorola.

Large screens expose layout bugs that phones hide. On the Galaxy Tab A9+ (800 dp wide) and the unfolded Galaxy Z Fold7 (750 dp), the sample app kept its right-hand buttons at 160 dp while the left-hand buttons stretched to 547 dp and 498 dp, and the welcome text moved into the right half of the screen. On the Galaxy S23 phone, the left-hand button was the narrower one, at 108 dp.

• Test by layout width - cover a compact phone around 360 dp wide, a large phone around 410 dp, and a tablet or unfolded foldable.
• Rotate and fold during a flow - change orientation and fold state mid-session and confirm the screen keeps its state and its layout. On Apple's foldable, the iPhone Duo testing guide covers the open-and-close check.
• Read layouts in dp - compare element bounds against the screen width in dp, which is the pixel width times 160 divided by the density in dpi, so the same check works across densities.

3. Native, Hybrid, Web, and PWA Builds

Each app type fails in a different layer, so one test approach does not fit all four. The differences between them are covered in web vs hybrid vs native apps; the table below maps each type to what breaks and what to test.

Hybrid apps need one extra step in automation. Appium's documentation on contexts treats the native layer and each WebView as separate contexts, with the native one conventionally named NATIVE_APP, so a test switches into the WebView context to work with web elements and back to NATIVE_APP for native controls.

4. Unstable Networks and Offline Use

A flow that passes on office Wi-Fi can time out, submit twice, or keep spinning on a slow or dropping connection. Those failures appear only when the network is constrained during the test, so they need their own runs rather than a note in the release checklist.

On TestMu AI real devices, setting network to true and networkProfile to a preset such as 3g-umts-good throttles the whole session. The network throttling docs list presets from 2g-gprs-poor to 4g-lte-advanced-good, custom download, upload, and latency values, and an API call that switches the device offline mid-test.

• Start the app offline - launch with no connection and confirm the app shows cached data or a clear message instead of a blank screen.
• Cut the network mid-request - drop the connection during checkout or upload and check that the app retries or recovers without a duplicate submission.
• Run critical flows on a slow profile - repeat login and checkout on a 2G or 3G preset and look for timeouts set too short for real networks.

The same approach works for sites: see how to test mobile websites on different network conditions.

5. Permission Prompts and Interruptions

Android 13 turned notifications into a runtime permission. Android's notification permission guide says POST_NOTIFICATIONS applies from Android 13 (API level 33), that notifications are off by default for new installs, and that apps targeting Android 12L or lower see the prompt when they create their first notification channel.

That one change broke a simple test in my run. The test opened TestMu AI's Proverbial sample app, tapped Notification, then tapped Toast. On Android 13 through 17, the prompt appeared after the first tap, and while it was open the test could not find the Toast button, so the second step failed on all five newer devices. The prompt also looked different on each manufacturer's skin, which matters for any test that tries to tap Allow by its position or style.

The fix belongs in session setup. Adding autoGrantPermissions, which TestMu AI's Appium capabilities reference describes as granting the permissions your app requires on install, made all five devices pass on the rerun. These are the capabilities the Pixel 11 rerun sent; the app value is the upload ID from my account, so use the lt:// URL your own upload returns.

{
  "platformName": "android",
  "LT:Options": {
    "w3c": true,
    "isRealMobile": true,
    "deviceName": "Pixel 11",
    "platformVersion": "17",
    "app": "lt://APP10160422271791200084955521",
    "build": "Mobile Challenges Blog 2026-10-14",
    "name": "grant | Pixel 11 | Android 17",
    "video": true,
    "devicelog": true,
    "autoGrantPermissions": true
  }
}

• Keep one denial test - grant permissions in most tests, then keep one test that taps Don't allow, so the denied path stays covered.
• Cover iOS alerts too - on iOS, the autoAcceptAlerts and autoDismissAlerts capabilities handle system alerts the same way.
• Test the other interruptions - send the app to the background mid-flow, bring it back, and check incoming notifications and calls, which can cover the screen the same way the prompt did.

Notification flows have their own failure modes beyond the prompt; push notification testing on real devices covers them.

Note: Run your app on Android 11 through 17 and current iOS versions on real devices, with permissions, network profiles, and locations set per session, on TestMu AI. Start testing free

6. Hardware Features and Sensors

Features that read the camera, GPS, fingerprint or face sensor, or NFC chip depend on hardware that varies by model. Emulators help here: the Android Emulator documentation says it can simulate incoming calls and texts, the device location, network speeds, rotation, and other hardware sensors.

A simulated sensor returns the values you give it, though. A payment flow that waits on a specific phone's biometric prompt, or a scanner that depends on its camera pipeline, still needs that phone.

On TestMu AI real devices, a test can pass or fail Face ID, Touch ID, and fingerprint prompts on demand, as the biometric authentication docs show. It can also inject images into the camera for QR and barcode flows and set the device location in more than 150 countries, which helps with localization testing.

7. Release Speed Versus Test Coverage

Weekly or faster releases leave little time to run every test on every device, and a matrix run one device at a time grows with each device you add.

In the seven-device run, each real-device session took 43 to 52 seconds from request to teardown, and 28 to 36 seconds of that went to starting the session, which covers allocating the device and installing the app. Run back to back, the seven sessions add up to about 5.5 minutes; run four at a time, they fit into roughly a minute and a half.

• Split the suite by risk - run a smoke suite on three to five devices for every pull request and the full matrix nightly or before each release.
• Automate the stable flows first - put login, checkout, and other flows that change least into automated regression testing, and keep manual time for new features.
• Parallelize before you trim coverage - more parallel sessions shorten the run without dropping devices from the matrix.

When the suite outgrows simple parallel runs, TestMu AI's HyperExecute runs an existing test suite up to 70% faster on just-in-time infrastructure, according to TestMu AI, and supports Appium, Espresso, XCUITest, Maestro, and Detox.

8. Visual and UX Consistency

The same system prompt looked different on each manufacturer in the seven-device run: a sheet with plain text buttons on the Samsung devices, filled blue and grey buttons on the Redmi Note 13 Pro, and a centered dialog with pill-shaped buttons on the Pixel 11. Your app inherits the same kind of differences in fonts, system bars, dark mode, and default widgets.

Functional assertions can pass while text is clipped or controls overlap, so compare screenshots of key screens across devices on every release, in dark mode and at large font sizes. A mobile app testing strategy that includes visual testing catches these regressions before release.

9. Accessibility on Small Screens

Small screens make accessibility failures easy to ship. Android's accessibility guidelines recommend a touch target of at least 48dp x 48dp for every interactive element.

Text size is the second trap. Android 14's feature notes say the system supports font scaling up to 200% and applies a nonlinear scaling curve to large text.

• Open every key screen at the largest font size - look for clipped labels and buttons pushed below the fold.
• Navigate with TalkBack and VoiceOver - confirm each control announces a meaningful label and that focus moves in reading order.
• Measure touch targets - flag interactive elements smaller than 48dp on Android before they reach users with motor impairments.

For a fuller checklist, see mobile app accessibility.

10. Security and Data Privacy

Mobile apps keep tokens, personal data, and payment details on a device the company does not control. The OWASP Mobile Top 10 2024 ranks improper credential usage first and also lists insecure communication, inadequate privacy controls, and insecure data storage.

To turn those risks into test cases, use the OWASP MASVS, which groups requirements into storage, cryptography, authentication, network communication, platform interaction, code quality, resilience, and privacy.

• Inspect local storage - confirm tokens and personal data never sit in plain files, shared preferences, or logs.
• Test the connection - require TLS and check how the app reacts to an untrusted or swapped certificate.
• Check session handling - expire tokens on logout and require authentication again after biometric or PIN timeouts.

These checks extend standard security testing to what the device itself stores and sends.

11. Battery, CPU, and Memory Drain

Battery drain can reach your store listing. Android vitals reports partial wake locks as excessive when they add up to 2 or more hours in a 24-hour period, and if that happens in more than 5% of app sessions over 28 days, it can affect the app's visibility on Google Play.

To catch drain before users report it, profile real sessions. TestMu AI's App Profiling, turned on with appProfiling set to true in Appium tests, reports startup time, CPU, memory, frame rate, ANRs, crashes, battery drain rate, and device temperature on real devices. The App Profiling docs note that battery data is reported for Android apps only.

• Profile the heaviest flows - measure CPU and memory during sync, video, maps, and long lists, where background work piles up.
• Repeat key flows in low-power states - Low Power Mode on iOS and Battery Saver on Android restrict background activity, which exposes sync and refresh bugs.
• Compare against a baseline build - a regression in startup time or memory is easier to fix in the release that introduced it.

Metrics and thresholds are covered in depth in mobile performance testing.

12. Too Many App Testing Tools

Mobile testing tends to spread across separate tools for Android and iOS, manual and automated runs, and functional and performance testing. Each tool brings its own setup, reporting format, and learning curve, and results end up in several places.

Reduce the count at the framework layer first. Espresso and XCUITest each serve one platform, Appium drives both from one codebase, and Detox targets React Native. The mobile app testing frameworks comparison shows which fits which team, and the mobile app testing tools guide covers the platforms around them.

If an AI coding agent writes your tests, the Appium skill gives it TestMu AI's Appium patterns for locators, waits, and real-device capabilities, so generated tests follow one structure.

13. Flaky Mobile Automation

Android's test stability guide explains that background and asynchronous work can fail a test when a step runs before the UI is ready, and it warns that fixed sleeps make tests slow or flaky because the same test needs different amounts of time in different environments.

The same guide tells teams to configure test devices so the OS does not interrupt test execution, with a system update dialog shown on top of other apps as its example. The notification prompt in the seven-device run is that failure mode: failures that look random but track the OS version, with no code change behind them.

• Replace sleeps with condition waits - wait for the element or state the next step needs, such as a visible button or a finished network call.
• Handle system dialogs in setup - grant permissions at install and dismiss known dialogs before the first test step.
• Log every retry - a test that passes only on retry is a flaky test that needs a fix.

Track flakiness with data instead of memory. TestMu AI's Test Intelligence flags tests whose results change across runs and ranks each one by flake rate, so the worst offenders get fixed first.

One Test on 7 Real Android Devices

The findings in challenges 1, 2, and 5 come from one run on October 14, 2026, in TestMu AI build 29020705. I installed TestMu AI's Proverbial sample Android app on seven real devices, one per Android version from 11 to 17, across five manufacturers. A short script sent plain W3C WebDriver calls to the Appium hub: open the app, tap Notification, then tap Toast, and record each device's panel size and density.

The script printed one line per device, with the panel in pixels and the density in dpi:

Oppo A54           Android 11  720x1600   320  prompt: none       PASS
Moto G22           Android 12  720x1600   280  prompt: none       PASS
Galaxy S23         Android 13  1080x2340  480  prompt: after tap  FAIL
Redmi Note 13 Pro  Android 14  1220x2712  480  prompt: after tap  FAIL
Galaxy Tab A9+     Android 15  1200x1920  240  prompt: after tap  FAIL
Galaxy Z Fold7     Android 16  1968x2184  420  prompt: after tap  FAIL
Pixel 11           Android 17  1080x2424  420  prompt: after tap  FAIL

Rerunning the five Android 13 and newer devices with autoGrantPermissions set to true removed the prompt, and every device passed:

Galaxy S23         Android 13  1080x2340  480  prompt: none       PASS
Redmi Note 13 Pro  Android 14  1220x2712  480  prompt: none       PASS
Galaxy Tab A9+     Android 15  1200x1920  240  prompt: none       PASS
Galaxy Z Fold7     Android 16  1968x2184  420  prompt: none       PASS
Pixel 11           Android 17  1080x2424  420  prompt: none       PASS

The run shows that the OS version decides behavior a test never asked about, so a device matrix needs phones on both sides of each behavior change. It also shows that density and screen class change layout more than model names suggest: the two 720x1600 phones gave the app different widths, and the tablet and the foldable exposed a fixed-width button column that the phones hid.

How to Prioritize These Challenges

Start with the challenges your crash reports and store reviews already show, then put the device matrix, the emulator split, and parallel real-device runs below in place so the rest get covered release by release.

Build a Device Matrix From Real Usage

Export the device models and OS versions behind your sessions from your analytics or store console, and cover the combinations that carry most of your users. Then add the newest OS release, one device below each recent behavior change, such as Android 12 next to Android 13 for the notification permission, one compact phone, and one tablet or foldable.

The guide to building an Android device matrix from real data walks through the selection step by step.

Split Work Between Emulators and Real Devices

Emulators and simulators are cheap and fast, and real devices are where manufacturer behavior, hardware, and performance show up. Most teams need both, split by what each one can prove.

TestMu AI also runs Android emulators online and iOS simulators online for the early-feedback tier. The trade-offs are compared in detail in emulator vs simulator vs real device.

Run the Matrix in Parallel on Real Devices

TestMu AI's real device cloud gives live and automated sessions on 50,000+ physical Android and iOS devices, with network throttling, geolocation, biometric, and camera image controls set per session.

Point your existing Appium capabilities at the cloud hub with isRealMobile set to true, as in the capability block in challenge 5, and run the matrix through App Automation, which runs Appium, Espresso, XCUITest, and Maestro suites on real devices.

Run iOS + Android tests written by your AI agent.

Install the Appium Skill free

Conclusion

Start with the cheapest fix on this list: add autoGrantPermissions to your real-device capabilities, keep one test that taps Don't allow, and run both on one phone below Android 13 and one above it this sprint. Then follow the getting started with Appium testing docs to run the rest of your device matrix on TestMu AI.

Testing web or mobile apps without writing code? KaneAI by TestMu AI turns plain-English instructions into tests.

To run your first test, start free, or

book a demo

for a full walkthrough of the product.