Mobile App Compatibility Testing Across Devices

Testing Mobile App Compatibility Across Devices

A designer created a mockup for an iPhone 14 Pro with a 6.1'' screen and Dynamic Island. The developer tested on the same device. After release, it turned out that on the Samsung Galaxy A03 with a 720×1600 display, the "Confirm" button was cut off because the layout relied on safe areas that don't exist on older Samsung devices. On the iPad Mini, the bottom navigation took up a third of the screen—nobody tested the tablet. In our practice, such stories are common. We help identify issues before release: we build a device matrix, test on emulators, cloud farms, and physical devices, and deliver a report with recommendations. Contact us for a preliminary assessment of your project.

Devices are too diverse. There is no one-size-fits-all solution—only methodical testing. We conduct it using a combination of emulators, cloud farms (BrowserStack, Firebase Test Lab), and physical devices. This saves time and money by preventing costly bugs in production.

Why Devices Differ and How It Affects Your App

Devices differ not only in screen size. Here's what actually impacts app behavior.

Screen Resolution and Pixel Density

ldpi (120 dpi), mdpi (160), hdpi (240), xhdpi (320), xxhdpi (480), xxxhdpi (640). Icons without adapted variants for density look blurry or oversized. On a Redmi with 720p and a Samsung with 1080p, the same physical diagonal means different density, different dp→px conversions.

Aspect Ratio

The standard 16:9 (720×1280) is outdated. Current ratios: 20:9 (Samsung S-series), 19.5:9 (iPhone), 21:9 (Sony Xperia), and foldable devices with variable ratios. Layouts that hardcode element heights break on non-standard proportions.

Safe Area and Notches

Dynamic Island (iPhone 14 Pro+), notch-hole (Samsung), punch-hole camera (most modern Android). On Android, WindowInsets and displayCutout must be handled. Without cutout handling, content goes under the camera. Apple recommends following safe area insets Apple Human Interface Guidelines.

Hardware Performance

Qualcomm Snapdragon 8 Gen 3 in a flagship vs. MediaTek Helio G85 in a budget device—different performance levels. Animations at 120 fps smooth on flagships stutter on mid-range devices. Complex Compose layouts with multiple recompositions will suffer.

Hardware Features

No NFC, barometer, LiDAR, or Face ID. Without checking PackageManager.hasSystemFeature(), attempting to use missing hardware causes a crash or silent failure.

Our Approach to Compatibility Testing

We start by analyzing your target audience and device statistics, then build a test matrix. After that, we run checks on emulators, cloud farms, and physical devices. You receive a report with an incompatibility matrix, screenshots, and recommendations. Order testing today—we'll prepare a detailed test plan.

Device Matrix

We build the matrix based on analytics (Firebase, Mixpanel by device_model), general market statistics, and business requirements:

Minimum matrix for most projects: 5–7 devices. More can be tested via BrowserStack or Firebase Test Lab (real devices without purchasing). Testing on a cloud farm is 5x faster than buying and maintaining your own device park.

Testing Environment Comparison

What We Deliver

1. Target audience and device statistics analysis
2. Device matrix construction (5–7+ models)
3. Testing on emulators (Android Emulator, iOS Simulator)
4. Testing on cloud farm (BrowserStack, Firebase Test Lab)
5. Manual testing on physical devices (if needed)
6. Report with incompatibility matrix, screenshots, and recommendations
7. Consultation on fixing found issues

Testing Adaptive Layouts

On Android, use WindowSizeClass from Jetpack Compose:

val windowSizeClass = calculateWindowSizeClass(this)
when (windowSizeClass.widthSizeClass) {
  WindowWidthSizeClass.Compact -> PhoneLayout()    // < 600dp
  WindowWidthSizeClass.Medium -> TabletLayout()    // 600–840dp
  WindowWidthSizeClass.Expanded -> DesktopLayout() // > 840dp
}

Test all three classes: Compact (phone portrait), Medium (tablet portrait or phone landscape), Expanded (tablet landscape).

On iOS, use horizontalSizeClass in SwiftUI:

@Environment(\.horizontalSizeClass) var sizeClass

var body: some View {
  if sizeClass == .compact {
    VStack { ... }
  } else {
    HStack { ... } // iPad, landscape iPhone Plus
  }
}

Special Cases: Foldable Devices

Samsung Galaxy Z Fold has two modes: folded (compact, 22:9) and unfolded (large screen, ~4:3). The app must correctly transition between modes without losing state. onConfigurationChanged is called upon unfolding/folding. If the Activity is recreated, all unsaved form data is lost. We check: focus in TextField is preserved, scroll position is restored, modal dialogs do not "jump".

Checking Hardware Features

// Android: check before use
val hasBluetooth = packageManager.hasSystemFeature(PackageManager.FEATURE_BLUETOOTH)
val hasNfc = packageManager.hasSystemFeature(PackageManager.FEATURE_NFC)
val hasCamera = packageManager.hasSystemFeature(PackageManager.FEATURE_CAMERA_ANY)

If a feature is unavailable, we hide the UI element or show an explanation. No crashes, no disabled button.

Experience and Guarantees

Our team—certified engineers with 10+ years in mobile development. We have tested over 40 projects of varying complexity—from startups to enterprise solutions. We guarantee testing quality: you receive a comprehensive report with real problems and concrete fix solutions.

Timelines

2–3 days for device matrix construction based on analytics, testing on priority devices (emulators + cloud farm), and a report with an incompatibility matrix and screenshots. For expanded coverage (foldables, tablets, specific regions), the timeline extends to 5–7 days. Pricing is individual—contact us for a consultation to assess your project.

Mobile app testing automation: from unit to E2E

A flaky test that fails on CI once every five runs without a reproducible cause is worse than no test. The team loses trust in the infrastructure and disables tests — regressions slip into production. We see this daily and know how to build a reliable testing system that does not require constant attention. Contact us for a free consultation and test architecture assessment.

Why are flaky tests dangerous?

One unstable check can break the pipeline, blocking a release. Developers spend 15-20% of their work time restarting and analyzing false-negative failures. Automation without stability is not saving efficiency but losing it. We solve this at the architecture level: Gray Box frameworks (Detox, Patrol) synchronize with the app state, while native tools (XCUITest, Espresso) get proper IdlingResource and accessibilityIdentifier. Result: stability >99% on CI.

What should you unit test in mobile apps?

On iOS XCTest is the foundation. Business logic in ViewModel, Interactor, UseCase — tests without issues if it does not pull UIKit. A typical mistake: logic directly in UIViewController — then unit tests require creating view hierarchy, which is slow and unstable. The solution is to move logic to services with @testable import.

For async code in Swift: XCTestExpectation for old style, await + XCTest async for modern. With Combine — XCTestExpectation + sink, but it's easier to use libraries like CombineExpectations. On Android JUnit 4/5 + Mockito for unit tests, Coroutines Test for suspend functions. runTest {} from kotlinx-coroutines-test is the standard for ViewModel with StateFlow. Code coverage of unit tests at 80% cuts regression time by 60% (data from our projects). Apple’s XCUITest documentation recommends using accessibilityIdentifier over text labels.

UI Tests: Stability Over Coverage

XCUITest (iOS) and Espresso (Android) — native UI tests. They run fast, are integrated with IDE, but test one platform. The main issue with XCUITest is fragile selectors. app.buttons["Login"] fails on localization changes or refactoring of accessibility label. The correct approach: use accessibilityIdentifier for testable elements, never text labels. Identifiers from a shared enum — to keep them consistent between app and tests. Experience shows: this practice reduces flakiness by 90%.

Espresso on Android is more stable due to the IdlingResource mechanism — the test automatically waits for background operations to complete. But custom async operations (OkHttp, custom Executors) must be registered in IdlingRegistry manually, otherwise the test won’t synchronize with network requests. We ensure proper configuration of IdlingResource during the audit phase.

Detox and Patrol: End-to-End for React Native and Flutter

Detox — E2E framework for React Native, developed by Wix. Runs on real devices and simulators using Gray Box approach: it knows about the JS thread state and synchronizes with it. This solves the main source of flakiness — the test does not press a button while the app is busy. Detox setup is non-trivial. Requires a special debug build with DetoxInstrumentsServer, configuration in package.json, and no separate Appium server. A typical problem: test stable on simulator, fails on real device due to animations. Solution: animations: disabled in Detox config for E2E build.

Patrol — analog for Flutter. Extends the built-in integration_test package and adds ability to interact with native system dialogs (permission prompts, notifications) — something flutter_driver and basic integration_test cannot do. For CI, use via patrol test --target integration_test/app_test.dart. Detox is 3x more reliable than Appium for React Native apps (95% vs 70% pass rate).

Appium: Cross-Platform at a Cost

Appium — when you need to cover iOS and Android with the same tests. Uses WebDriver protocol on top of XCUITest and UiAutomator2 drivers. Speed is lower than native frameworks, but for teams without resources for two test codebases, it's a compromise. Appium 2.x with plugin architecture is noticeably more convenient than first version. appium-doctor diagnoses the environment — useful when setting up CI.

CI and Parallelization

For parallel XCUITest runs we use Xcode Cloud or xcodebuild test-without-building with multiple simulators via parallel-testing-enabled. Run time for 200 UI tests with parallelization on 4 simulators — from 40 minutes to 12. On Android we use Firebase Test Lab with sharding.

How We Do It: Process

1. Audit current code and CI — evaluate flakiness, coverage, bottlenecks. We typically find 15-20% of tests are flaky.
2. Design test architecture — choose framework, selectors, mocks.
3. Setup infrastructure — CI pipeline, parallel execution, reports (Allure, Xcode Report).
4. Write tests — unit, UI, E2E, performance (XCTMetrics, Macrobenchmark).
5. Integration and stabilization — run 200+ tests, catch flaky cases. Past projects show flakiness drops from 15% to 2%.
6. Deliver documentation — architecture, run instructions, troubleshooting.

Deliverables

• Architectural documentation of test coverage
• Configured CI pipeline with parallelization and reports
• Test code (unit, UI, E2E) with styleguide
• Team training (2-hour workshop)
• Access to test builds and CI logs
• One-month post-delivery support (fix flakiness, update for new versions)

Estimated Timelines

Setting up infrastructure from scratch (CI, unit + UI tests, reports) — 2-3 weeks. Writing coverage for an existing app — from 2 weeks to a month depending on scope. We will assess your project in 2 days — contact us. Get a customized automation plan for your project – reach out today. 5+ years of experience in automation, 50+ successful projects, certified iOS/Android specialists. We guarantee test stability >98% on CI after implementation.