Mobile Compatibility Testing: A Full Guide

What Is Mobile Compatibility Testing?

Mobile compatibility testing checks that your app works and looks right on the phones, tablets, OS versions, browsers and networks your users actually have. The hard part is fragmentation. The same Android version behaves differently on a Samsung, a Pixel and a budget handset, and a layout that fits one screen can hide a button on another.

This guide shows you how to choose the real iOS and Android devices that matter, what to check on each one, and how to prove a failure really follows a device. It includes a real bug from my own app that looked fine on one Android phone and sent another straight to its home screen.

Jump to: How to choose devices · What to check · How to perform it

Why You Should Perform Mobile Compatibility Testing

A compatibility bug you miss in testing becomes a support ticket or a one-star review from a device you never tested: an older OS version, a budget handset, a foldable. The cost isn’t the bug. It’s shipping it to a whole group of your users and hearing about it from them first.

Mobile compatibility testing catches those bugs before release. It keeps the experience consistent on the devices your users actually carry, and it cuts the support load that follows a launch.

For the wider picture, see Kobiton’s ultimate guide to mobile app testing.

Types of Mobile Compatibility Testing

Compatibility testing breaks down by what changes between one user and the next. Most types cover the environment your app runs in. The last two cover time: older versions you still support and newer ones on the way.

Cross-Device Testing

Cross-device testing, sometimes called multi-device testing, checks that one experience holds across the phones, tablets and foldables your users carry. It also checks continuity. A user who starts on a phone and picks up on a tablet should find the same account state, cart or draft. Test that handoff, not just each screen on its own.

Hardware Testing

Hardware testing checks your app against the physical parts of each phone: screen size and density, chipset, memory, cameras, sensors, biometrics and NFC. An emulator can model a screen size. It can’t model a budget chipset under memory pressure. Here’s more on when emulators, simulators and real devices each fit.

Operating Systems Testing

OS compatibility testing checks your app across the iOS and Android versions your users run. iOS users update fast because Apple ships each release to most supported iPhones at once, so the current and previous major versions cover most of them. Android spreads out further. Each manufacturer ships its own build and its own update schedule, so the same Android version can behave differently from one brand to the next. Always include your minimum supported version, the latest release and the versions most of your users are on.

Software Testing

Software compatibility testing checks that your app works alongside the other software on the device: third-party keyboards, password managers, accessibility services, and the apps it hands off to for sharing, payments or sign-in. For platform specifics, see understanding iOS and Android app testing and our iOS and Android app testing guides.

Network Testing

Network testing checks how your app behaves on different connection types and speeds: Wi-Fi, 5G, LTE and slow or lossy links. Real-World Network Conditions below covers what users actually hit.

Browser Testing

For mobile web content and hybrid apps, test the browsers and in-app WebViews your users rely on: Chrome and Samsung Internet on Android, Safari on iOS, and the WebView embedded in your own app. A pass in Safari does not prove another browser or WebView works. Android’s WebView also updates separately from the OS, which is a common source of “works on my phone” bugs.

Backward Compatibility Testing

Backward compatibility testing checks that a new release still works on the older devices and OS versions you support. It catches features that call APIs older versions don’t have, libraries that quietly drop old OS support, and redesigned screens that need more memory than older phones have.

A large credit union learned this after launching a new app that combined its mobile and online banking. Complaints came in from members on older Android versions. The team added the older Android phones it had on hand to its private device pool, reproduced the problem, and validated the hotfix on those same devices before it shipped.

Test the oldest devices and OS versions you support. Fix what fails, or change the support policy on purpose and tell users before release.

Forward Compatibility Testing

Forward compatibility testing checks your current app against OS versions and devices that aren’t out yet.

Run your critical flows on OS betas before the public release. The mobile team at a retail bank upgrades its test iPads to each new iPadOS beta every week. That habit has caught iPadOS changes that would have broken their apps before those changes reached a single customer.

Navigating Challenges in Compatibility Testing

These are the places compatibility bugs come from, and what to do about each.

Device Fragmentation

Mobile device fragmentation changes what your app can do and how it behaves. Test these five sources of failure:

• Manufacturer builds. Android power-saving rules and each manufacturer’s customizations can delay notifications and background sync. Test those flows on the brands your users carry.
• OS version changes. Android 15 made edge-to-edge layouts the default for apps that target it, Android 14 let users share only some of their photos, and Android 13 made notifications opt-in. A flow that works on one version can break on the next, or on one from two releases back.
• Screens and form factors. Notches, punch-hole cameras, foldables, tablets and navigation bars all change how much of the screen your app really gets.
• Hardware tiers. Features that feel instant on a flagship can stutter, or get closed by the OS, on a phone with half the memory.
• Device settings. Navigation mode, accessibility and display settings change layout and motion. On iOS, turning on Prefer Cross-Fade Transitions changes how the keyboard reports its position, which can break layouts built around the default.

A Real Example: The Next Button That Went Home

I build a React Native app and test it on Kobiton. Its form screens have a Next button pinned to the bottom. On my own Galaxy S21+, the button slid behind Android’s gesture navigation bar, even though the app measured the bottom inset correctly. Screens without a keyboard wrapper (the component that moves the form up when the keyboard opens) were fine. The ones with it were not.

My first fix added a small bottom margin. It looked right on the Samsung. Then the automated test ran on a Pixel 10 with Android 16, set to three-button navigation, which reported a bottom inset of zero. The margin wasn’t enough, the test’s tap on Next landed on the navigation bar, and the phone went straight to its home screen.

Same app, same build, two handsets, two navigation modes, two different answers. The fix added a minimum bottom margin on Android, so the button clears the navigation bar even when the device reports no inset. Later runs on the Pixel 10 show the button where it belongs.

The bug lived in the gap between devices, and in a device setting most teams never put in their matrix. It took two different handsets to see it.

Battery, Heat and Memory

An app can pass every functional test and still drain the battery, heat up the phone or get closed by the OS for using too much memory. These problems depend on the chipset, the battery and the manufacturer’s power management, so they show up on specific devices. Watch CPU, memory and battery use during your critical flows on real devices, especially your lowest-tier supported phone.

Real-World Network Conditions

Switching a test between Wi-Fi and a throttled profile is easy. What users hit is harder: signal dropping mid-upload, a switch from Wi-Fi to cellular, high latency on a crowded network. Test critical flows while conditions change, including going offline and coming back. The app should show a clear state, retry sensibly and keep what the user typed.

Regression Risks

Every fix can break something on a device you didn’t retest. Rerun your compatibility flows after each change, not just the one that failed. Here are 5 things to know about regression tests.

Localization Complexity

Test your supported languages on the smallest screens in your matrix. Check longer labels, right-to-left layouts, dates and currency formats. Here’s more on localization testing.

How to Choose Devices for Mobile Compatibility Testing

The device list is where mobile app compatibility testing is won or lost. You can’t test every device, and you don’t need to. You need a device list that looks like your users. Build it from four inputs:

1. Your own analytics. Device model, OS version and browser from your app analytics or store console. This beats any global market-share chart.
2. Your support policy. The oldest OS version and devices you’ve promised to support. These are always in release checks.
3. Production signals. Crash reports and app store reviews by device. Prioritize devices with recurring or severe failures, even when their user share is small.
4. Market data for new regions, where your analytics can’t help yet.

No analytics yet? Start from your support policy and US market data, then replace them with your own numbers. In US mobile web traffic, iOS 18 and newer is 94.9% of iPhone traffic, and Android 11 and newer is 89.7% of Android traffic (StatCounter, June to August 2026).

Then sort every device into a tier by how many users depend on it and how likely it is to fail:

• Tier 1: your busiest or highest-risk combinations. Test these on every release, by hand and automated.
• Tier 2: the rest of your supported device mix. Automated regression on a schedule.
• Tier 3: uncommon form factors and targeted checks.

A budget Android phone or a tablet belongs in Tier 1 if your customers rely on it. Here is an illustrative matrix for a banking app:

Tier 1: busiest or highest-risk

• iPhone 15 Pro, current iOS. Top device in analytics. Flows: login, transfer, check deposit. Camera for deposit: full.
• iPhone SE (3rd gen), oldest supported iOS. Small screen at the support floor. Flows: login, transfer. Camera: full.
• Galaxy S22, current Android. Top Android device in analytics. Flows: login, transfer, check deposit. Biometrics: full.
• Budget Android with 4 GB RAM, oldest supported Android. Large share of older customers. Flows: login, transfer. No NFC, so tap to pay is hidden and a message explains why.

Tier 2: the rest of your supported mix

• Pixel 8, current Android. Stock Android reference. All flows.
• Galaxy Z Fold, current Android. Showed up in crash reports. Flows: login, account view, in folded and unfolded layouts.

Tier 3: uncommon form factors

• iPad (10th gen), current iPadOS. Used by branch staff. Flow: account view, in split view.

Four Tier 1 devices cover the top iPhone, the top Android, the oldest supported iOS and the budget Android most older customers carry. The foldable earned its place from crash reports, not market share.

The fallback detail matters. Some devices run your app but lack a feature it uses, like NFC, a particular camera or biometrics. Test that the app hides the feature or explains it clearly. That code path gets far less testing than the happy path.

What this looks like at real teams:

• A credit union with a fully remote QA team, building its mobile device compatibility testing from zero, picked the most recent iPhone generation, a Samsung and a Pixel as its minimum set, then grew from there.
• A marketing technology company set its support floor at Android 14 and tested iOS 18 and 26. Its support policy defined the matrix.
• A travel company saw app crashes on a Samsung foldable in its production reports. The device was niche, but it went straight into the test pool.
• A national mobile network operator sized its device list from its own app analytics, choosing the devices that covered most of its user base.
• An airline's crew app runs only on company-issued iPads and iPhones, so its matrix follows the fleet, not the market.

Review the matrix every quarter, and after every major OS release or shift in usage.

Real Devices vs Emulators for Compatibility Testing

Emulators and simulators are good for:

• Fast functional checks during development
• First-pass layout checks on standard screen sizes
• Simulated battery levels, locations and network profiles
• Smoke tests on every commit

You need a real device for:

• Manufacturer builds and customizations
• Navigation bars, insets and keyboards as each manufacturer draws them
• Real memory limits, heat and battery behavior
• Real cameras, biometrics, NFC and other hardware
• Notches and foldables as users see them
• Final validation before release

An emulator can fake a battery level or a GPS fix. It can't run Samsung's build of Android, and that's where my Next button first broke. Use emulators early, then validate critical flows on real devices before every release.

Where those real devices live is a separate choice: public cloud, private devices, or on-premises when test data must stay inside your network. Our guide to cloud mobile app testing covers how to pick.

What to Check in Mobile Compatibility Testing

Run these ten checks on every device in your matrix.

1. Install and upgrade. Fresh installs and supported upgrade paths succeed. User data survives the upgrade.
2. Layout. Nothing is clipped, overlapping or hidden behind notches, navigation bars or the keyboard, on every screen size in the matrix.
3. Orientation. Rotating keeps the layout and what the user typed.
4. Gestures and input. Taps, swipes, long press and pinch behave the same. The keyboard never covers the active field.
5. Permissions. Deny, grant and revoke each required permission. The app explains limits and recovers without crashing.
6. Interruptions. Calls, notifications, backgrounding and low battery don't lose the user's place.
7. Hardware features. Camera, biometrics, NFC and location work where present and fall back cleanly where not.
8. Performance. Launch time, scrolling and memory meet the limits you set for each device tier.
9. Network. Critical flows survive slow, changing and offline connections.
10. Accessibility. Screen readers, larger text and contrast settings work on every OS version in the matrix.

How to Perform Mobile Compatibility Testing

1. Pick your flows. List the journeys that matter most: sign-up, login, payment, your core screen.
2. Build your device matrix from analytics, support policy and production signals, as above.
3. Run the flows by hand on your Tier 1 devices first. Rotate, background the app, switch networks and work through the ten checks.
4. Automate the flows that are stable, and run them across the matrix on a schedule (below).
5. When something fails, reproduce it before you blame the device. Repeat the action by hand on the failing device and on one where it passes. If the app works and only the automated test fails, fix the test. If the app fails the same way every time, you have a compatibility defect. Typical ones: text that changes size or gets cut off, misaligned or overlapping elements, and controls hidden under system bars or the keyboard.
6. Record the device, OS version, navigation mode, steps and defect evidence, fix it, then rerun the same flow on the same device before release.

Step 5 matters because the test itself can be the device-specific part. Android's default alert style shows button text in capitals, so a test in my app that looked for "Delete everything" never found "DELETE EVERYTHING" on Android and failed there only. Nothing was wrong with the app.

When to Run It

Trigger these from your CI/CD (continuous integration and delivery) pipeline so nobody has to remember:

• Every build: a small smoke suite on emulators or a few Tier 1 devices.
• Nightly or on merge: full regression across Tier 1 and Tier 2.
• Before release: the whole matrix including Tier 3, plus a manual pass on your top devices.
• OS betas: your critical flows, kept separate from release validation.
• After release: watch crashes and reviews by device, and add any device with recurring or severe failures.

What This Looks Like in Kobiton

Here is the Next button bug from earlier, run through that procedure on Kobiton.

Pick the devices. My private pool covers Galaxy S21, S22 and S25 models, Pixel 6 and 6 Pro, and iPhones from the SE to the 15 Pro. Newer models like the Pixel 10 come from Kobiton's public device cloud when the pool doesn't have them.

Run the flow. The automated test filled in the form and tapped Next on a Pixel 10 from the public cloud. Session Explorer keeps a screenshot for each command on a timeline, so the moment the tap landed on the navigation bar is right there, and so is the retest after the fix.

Add coverage. After the fix, I also ran the app's forms on a Pixel 6, a different screen size and density, to confirm the buttons stayed visible with the keyboard up and down.

Keep the evidence. This Appium session keeps the device, OS version, video, device logs and Appium logs (the command log from Appium, the widely used open-source framework for automating mobile apps) together, so the defect report carries its own proof.

Reuse it. Capture a manual flow on each platform and convert each session into a test case. Then generate an Appium script from the test case and run it on the matching devices in your matrix.

Best Practices for Mobile Compatibility Testing

Four habits keep compatibility testing from sliding back into guesswork.

Test the fallback path, not just the feature. Every device that lacks NFC, a camera or biometrics is running code most of your tests never touch.

Put the device, OS and navigation mode in every bug title. A defect that says "Pixel 10, Android 16, three-button nav" gets reproduced in minutes. One that says "button broken" doesn't.

Retest on the same device that failed. A pass on a different phone proves nothing about the fix.

Add one device from crash reports every quarter. Your users tell you which devices matter. Automate the flows on it once it's in the matrix.

Mobile Compatibility Testing FAQs

Can I do mobile compatibility testing on emulators? For early checks, yes. For release, no. Emulators can't reproduce manufacturer builds, real memory limits or real hardware, so validate critical flows on real devices before every release.

How many devices do I need? Enough to cover your busiest devices from analytics, your oldest supported OS on each platform, and any device with recurring failures in crash reports. Your matrix grows from those three sources, not from a fixed number.

What's the difference between backward and forward compatibility testing? Backward compatibility checks a new release on older devices and OS versions you still support. Forward compatibility checks your current app on upcoming OS versions, usually by testing on betas.

Kobiton, Your Map to Mobile Compatibility

Compatibility bugs live in the gaps between devices. Finding them takes a device list that looks like your users, a clear list of what to check on each one, and the discipline to prove a failure follows the device before you file it. Kobiton is built for that:

• Real iOS and Android devices in the public cloud, as private devices, or fully on-premises when test data has to stay inside your network.
• Manual sessions that convert into test cases and Appium scripts, so a flow you capture by hand on each platform can run across the matching devices in your matrix. Nobody else generates Appium scripts from a manual session.
• Accessibility checks for labels, contrast and touch target size that run automatically during manual sessions when enabled.
• CPU, memory, network and battery metrics during manual sessions, plus device logs, screenshots and session video that show exactly where a flow broke.

Want to see where your own app breaks? Request a demo and run it on real devices with our team.