Ensuring Mobile App Compatibility with New Devices

Ensuring Mobile App Compatibility with New Devices

After the release of a new iPhone model with a changed form factor and Dynamic Island, users started complaining: the status bar overlaps content, buttons go under the Home Indicator, the camera covers part of the interface. The app didn't break—it just didn't know about the new Safe Area insets. Our mobile development team, with 8 years of experience, regularly encounters such problems. Over 5 years, we have conducted compatibility audits for more than 100 mobile apps. We guarantee that after adaptation, the app will display correctly on any form factor.

What Breaks When a New Device Launches?

Safe Area and Dynamic Island. On iOS, Safe Area insets depend on the model. Hardcoded offsets—UIEdgeInsets(top: 44, left: 0, bottom: 34, right: 0)—are already incorrect for several iPhone generations. The right solution: use view.safeAreaInsets or safeAreaLayoutGuide in Auto Layout. In SwiftUI—.ignoresSafeArea() with explicit edge specification, not globally. For more details, see the Apple Human Interface Guidelines.

Display cutout on Android. Since Android 9, there's the DisplayCutout API. Devices with a camera cutout (Pixel, Samsung A-series, Xiaomi) require setting LAYOUT_IN_DISPLAY_CUTOUT_MODE_SHORT_EDGES. If the app uses NEVER, content will be clipped. All modes are described on Android Developers.

Changing aspect ratio. Modern flagships have aspect ratios of 19.5:9 and 20:9. If the layout is designed for 16:9 with fixed heights, black bars appear. On Android, test using <activity android:maxAspectRatio>—if not specified, the OS may enable letterbox.

Foldable and large screens. When unfolding a foldable device, the app receives a configuration change. If the Activity does not handle configChanges, it gets recreated with state loss. Jetpack WindowManager FoldingFeature allows adapting the layout.

Which Devices Are at Risk?

The greatest risks occur with the release of:

• iPhones with Dynamic Island (iOS 16+),
• Foldable smartphones (Samsung Galaxy Z Fold, Pixel Fold),
• Tablets and phablets (iPad Pro, Samsung Tab),
• Devices with non-standard aspect ratios (20:9, 21:9).

For each type, we have prepared a checklist of checks. For example, for foldable devices, it is necessary to check both portrait and landscape orientations, as well as folded and unfolded screen states.

How We Do It

For example, in an Android project, we discovered that the Activity did not handle configChanges, causing the app to recreate with form data loss when unfolding a Galaxy Fold. We added FoldingFeature from Jetpack WindowManager and adapted the layout for both states. The result—stable operation on all foldable devices. Using Jetpack WindowManager is 2x faster and simpler than manual onConfigurationChanged handling.

The work process includes:

1. Analysis of new devices and their specifics (safe area, cutout, foldable).
2. Audit of current code: search for hardcoded offsets, frame-based layout, deprecated APIs.
3. Fixing layout using modern constraints and system insets.
4. Testing on simulators and real devices (Firebase Test Lab, BrowserStack).
5. Regression testing of core functionality.

override func viewSafeAreaInsetsDidChange() {
    super.viewSafeAreaInsetsDidChange()
    // use actual insets
    let top = view.safeAreaInsets.top
    let bottom = view.safeAreaInsets.bottom
    // update layout
}

Quick Compatibility Check

Use a simulator of the new device (Xcode Simulator for iOS, Android Emulator with the appropriate AVD). For iOS, check traitCollection.horizontalSizeClass and verticalSizeClass. For Android—WindowMetricsCalculator.computeCurrentWindowMetrics(activity) instead of the deprecated Display.getSize(). Then run UI tests on a cloud service—this takes 1–2 hours. Comparison of approaches: simulator gives 70% reliability, real device—100%, but cloud service (Firebase Test Lab) covers 90% at a lower cost.

Why This Matters for Business

80% of negative reviews in the first days after a new device launch are related to display issues. User loss due to app malfunction can reach 15%. Timely adaptation not only preserves the audience but also boosts app store ratings. A preliminary audit can save up to 70% of the budget that would be needed for fixes after release.

What's Included in the Work

• Documentation with a list of changed files and rationale.
• Adaptation to the latest OS version and new APIs.
• Recommendations for supporting future devices.
• Access to test reports on a real device park (200+ devices).
• 30-day warranty on fixes.

Timelines and Cost

A compatibility audit for new devices and fixing critical bugs takes from 2 to 5 days, depending on code volume. If the app was originally written without Auto Layout / ConstraintLayout (legacy frame-based code), significant refactoring may be required. The cost is calculated individually.

Contact us for a consultation—our certified engineers will ensure correct operation on all modern devices. Order a compatibility audit to avoid losing users and negative reviews.

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.