Cross-Version Testing for iOS and Android Apps

Our cross-version mobile app testing service ensures compatibility across all supported OS versions. We detect deprecated APIs and prevent compatibility issues before release. Our mobile app compatibility testing covers both iOS and Android. You updated compileSdkVersion to 35, but kept minSdkVersion at 26. A week later in production on Android 10, a NoSuchMethodError crashes. Silent failure due to missing NotificationChannel on Android 7 — users complain about no notifications. Such bugs occur when code uses APIs newer than the minimum OS version. We've encountered this dozens of times and learned to identify these issues before release. Our service — cross-version mobile app testing — ensures all features work correctly on each supported OS version, without UI artifacts or crashes. Order a compatibility audit and get a version matrix in 2 days. With 7+ years of experience and 40+ successful projects, we guarantee thorough testing. Packages start at $999 for a basic compatibility audit, saving you up to $10,000 in potential production fixes.

How to Choose the Version Matrix for Cross-Version Testing?

Testing every OS version is impractical. We use a priority-based approach, leveraging analytics and project requirements.

Analytics from Firebase or Mixpanel on the os_version field provides the real picture. If 8% of users are on iOS 15 — test that version. If 0.3% are on iOS 14 — skip it. This approach reduces workload without losing quality. Additionally, it's useful to include versions with major API changes — for example, Android 12 (API 31) with the changed exported in intent-filters.

Why Deprecated APIs Are the Main Compatibility Issue?

The gap between minSdkVersion and compileSdkVersion spans about 8 years of API evolution. Miss one deprecated replacement — and the app crashes on older versions. We systematically catch such issues with static analysis and targeted testing.

Android: Three Common Pitfalls

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
  val channel = NotificationChannel(CHANNEL_ID, "General", NotificationManager.IMPORTANCE_DEFAULT)
  notificationManager.createNotificationChannel(channel)
}

Tool to check: lint with the NewApi rule. It automatically finds API calls above minSdkVersion without @RequiresApi or Build.VERSION.SDK_INT check. Experience shows lint catches 80% of issues before launch.

iOS: @available and #available

if #available(iOS 16.0, *) {
  NavigationStack { ... }
} else {
  NavigationView { ... }
}

The compiler warns about using new API without a check — this can be caught statically. But in large codebases, such warnings get lost. The most common victims: ContentUnavailableView (iOS 17), NavigationStack (iOS 16), Charts (iOS 16) — without a fallback, the app crashes with dyld: Symbol not found. More details in the @available documentation.

Tool for iOS: Xcode Simulator

Download additional runtimes: Xcode → Settings → Platforms → + → iOS 15.x Simulator Runtime. After downloading, create a simulator and test on it.

How to Automate Deprecated API Detection?

Static analysis with lint and Xcode Build & Analyze finds incompatibilities 10x faster than manual search. We run it in CI on every PR. For deeper checks, we use Firebase Test Lab — virtual devices with different API levels. It's fast, cheap, and covers most incompatibilities. For example, on one project we found 12 deprecated APIs before release, saving the client over $10,000 in potential production fixes.

How We Test Without Real Devices?

Emulators cover 90% of cases. Real devices are only needed for specific firmware (Samsung, Xiaomi) or hardware features (camera, NFC). We combine:

• In CI: run lint + build with -Werror for iOS.
• Smoke tests on emulators with minimum, mid-range, and current OS versions.
• Firebase Test Lab for integration scenarios.

This provides fast feedback without the cost of physical devices. You save on expensive post-release fixes and optimize the testing budget.

Our Process

1. Audit current minSdkVersion / minDeploymentTarget and version distribution analytics.
2. Compile a supported version matrix with priorities.
3. Static analysis for deprecated APIs (lint/Xcode) with a full list of found issues.
4. Testing on priority versions (smoke + targeted).
5. Report with compatibility matrix and recommendations for fixes.
6. Consultation on contentious points and help with code fixes.

Contact us to discuss your app and get a customized test plan. Packages start at $999 for a basic compatibility audit, $1,999 for full version matrix testing.

What's Included

• Documentation: supported version matrix with priorities, list of discovered incompatibilities, fix recommendations.
• Access to Firebase Test Lab reports and CI logs.
• Consultations on code fixes and adaptation for older OS versions.
• Support for 5 business days after report delivery.

Our certified team has over 7 years in mobile development and 40+ tested apps with audiences from 50,000 users. We guarantee accurate results. We'll assess your project in 2 days. Contact us to get a consultation. Order testing and receive a full report with compatibility matrix.

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.