Обеспечение совместимости мобильного приложения с новыми устройствами

Обеспечение совместимости мобильного приложения с новыми устройствами

После выхода новой модели iPhone с изменённым формфактором и Dynamic Island пользователи начали жаловаться: статус-бар перекрывает контент, кнопки ушли под Home Indicator, камера закрывает часть интерфейса. Приложение не сломалось — оно просто не знало о новых Safe Area insets. Наша команда мобильных разработчиков с 8-летним опытом регулярно сталкивается с такими проблемами. За 5 лет мы провели аудит совместимости для более чем 100 мобильных приложений. Мы гарантируем, что после адаптации приложение будет корректно отображаться на любых формфакторах.

Что ломается при выходе нового устройства?

Safe Area и Dynamic Island. На iOS Safe Area insets зависят от модели. Hardcoded отступы — UIEdgeInsets(top: 44, left: 0, bottom: 34, right: 0) — неверны уже для нескольких поколений iPhone. Правильное решение: использовать view.safeAreaInsets или safeAreaLayoutGuide в Auto Layout. В SwiftUI — .ignoresSafeArea() с явным указанием краёв, а не глобально. Подробнее — в Apple Human Interface Guidelines.

Display cutout на Android. С Android 9 появился API DisplayCutout. Устройства с вырезом под камеру (Pixel, Samsung A-серия, Xiaomi) требуют установки LAYOUT_IN_DISPLAY_CUTOUT_MODE_SHORT_EDGES. Если приложение использует NEVER, контент будет обрезан. На Android Developers описаны все режимы.

Изменение aspect ratio. Современные флагманы имеют соотношение 19.5:9 и 20:9. Если layout свёрстан под 16:9 с фиксированными высотами — появляются чёрные полосы. На Android тест через <activity android:maxAspectRatio> — если не указан, ОС может включить letterbox.

Foldable и большие экраны. При разворачивании складного устройства приложение получает configuration change. Если Activity не обрабатывает configChanges, происходит пересоздание с потерей состояния. Jetpack WindowManager FoldingFeature позволяет адаптировать layout.

Какие устройства находятся в зоне риска?

Наибольшие риски возникают при выходе:

• iPhone с Dynamic Island (iOS 16+),
• складные смартфоны (Samsung Galaxy Z Fold, Pixel Fold),
• планшеты и планшетофоны (iPad Pro, Samsung Tab),
• устройства с нестандартным соотношением сторон (20:9, 21:9).

Для каждого типа мы подготовили чеклист проверок. Например, для складных устройств необходимо проверить как портретную, так и ландшафтную ориентацию, а также состояния свёрнутого и развёрнутого экрана.

Как мы это делаем?

Например, в проекте под Android мы обнаружили, что Activity не обрабатывает configChanges, из-за чего при развороте Galaxy Fold приложение пересоздавалось с потерей данных формы. Мы добавили FoldingFeature из Jetpack WindowManager и адаптировали layout под оба состояния. Результат — стабильная работа на всех складных устройствах. Использование Jetpack WindowManager в 2 раза быстрее и проще, чем ручная обработка onConfigurationChanged.

Процесс работы включает:

1. Анализ списка новых устройств и их особенностей (safe area, cutout, foldable).
2. Аудит текущего кода: поиск hardcoded отступов, frame-based layout, устаревших API.
3. Правка layout с использованием современных констрейнтов и системных insets.
4. Тестирование на симуляторах и реальных устройствах (Firebase Test Lab, BrowserStack).
5. Регрессионное тестирование основного функционала.

override func viewSafeAreaInsetsDidChange() {
    super.viewSafeAreaInsetsDidChange()
    // используем актуальные insets
    let top = view.safeAreaInsets.top
    let bottom = view.safeAreaInsets.bottom
    // обновляем layout
}

Быстрая проверка совместимости

Используйте симулятор нового устройства (Xcode Simulator для iOS, Android Emulator с нужным AVD). Для iOS проверьте traitCollection.horizontalSizeClass и verticalSizeClass. Для Android — WindowMetricsCalculator.computeCurrentWindowMetrics(activity) вместо устаревшего Display.getSize(). Затем прогоните UI-тесты на облачном сервисе — это занимает 1–2 часа. Сравнение подходов: симулятор даёт 70% достоверности, реальное устройство — 100%, но облачный сервис (Firebase Test Lab) покрывает 90% при меньшей стоимости.

Почему это важно для бизнеса?

80% негативных отзывов в первые дни после выхода нового устройства связаны с проблемами отображения. Потеря пользователей из-за некорректной работы приложения может достигать 15%. Своевременная адаптация не только сохраняет аудиторию, но и повышает рейтинг в магазинах приложений. Предварительный аудит позволяет сэкономить до 70% бюджета на исправления, которые потребовались бы после релиза.

Что входит в работу

• Документация с перечнем изменённых файлов и обоснованием.
• Адаптация под последнюю версию ОС и новые API.
• Рекомендации по поддержке будущих устройств.
• Доступ к отчётам тестирования на реальном парке (200+ устройств).
• Гарантия на исправления в течение 30 дней.

Сроки и стоимость

Аудит совместимости с новыми устройствами и правка критичных багов занимает от 2 до 5 дней в зависимости от объёма кода. Если приложение изначально писалось без Auto Layout / ConstraintLayout (старый frame-based код), может потребоваться значительный рефакторинг. Стоимость рассчитывается индивидуально.

Свяжитесь с нами для консультации — наши сертифицированные инженеры обеспечат корректную работу на всех современных устройствах. Закажите аудит совместимости, чтобы избежать потери пользователей и негативных отзывов.

Тестирование мобильных приложений: XCTest, Espresso, Detox и Appium

Flaky-тест, падающий на CI раз в пять запусков без воспроизводимой причины, хуже его отсутствия. Команда перестаёт доверять инфраструктуре и отключает тесты — регрессии проскакивают в продакшн. Мы это видим каждый день и знаем, как выстроить надёжную систему тестирования, которая не требует постоянного внимания. Получите консультацию — оценим ваш проект и предложим архитектуру тестов под ваш стек.

Почему flaky-тесты опасны?

Одна нестабильная проверка может завалить пайплайн, заблокировав релиз. Разработчики тратят 15-20% рабочего времени на перезапуск и анализ ложнонегативных сбоев. Автоматизация без стабильности — не экономия, а потеря эффективности. Мы решаем эту проблему на уровне архитектуры: Gray Box-фреймворки (Detox, Patrol) синхронизируются с состоянием приложения, а native инструменты (XCUITest, Espresso) получают правильные IdlingResource и accessibilityIdentifier. Результат: стабильность >99% на CI.

Unit-тесты: что тестировать, а что нет

На iOS XCTest — основа. Бизнес-логика в ViewModel, Interactor, UseCase — тестируется без проблем, если она не тянет UIKit. Типичная ошибка: логика в UIViewController напрямую — тогда unit-тест требует создания view-иерархии, что медленно и нестабильно. Выход — выносить логику в сервисы с @testable import.

Для асинхронного кода в Swift: XCTestExpectation для старого стиля, await + XCTest async для современного. С Combine — XCTestExpectation + sink, но удобнее использовать библиотеки типа CombineExpectations. На Android JUnit 4/5 + Mockito для unit-тестов, Coroutines Test для suspend-функций. runTest {} из kotlinx-coroutines-test — стандарт для ViewModel с StateFlow. Покрытие кода unit-тестами на уровне 80% сокращает время регрессии на 60% (данные наших проектов).

UI-тесты: стабильность важнее покрытия

XCUITest (iOS) и Espresso (Android) — нативные UI-тесты. Работают быстро, интегрированы с IDE, но тестируют одну платформу. Главная проблема XCUITest — хрупкость селекторов. app.buttons["Войти"] падает при смене локализации или рефакторинге accessibility label. Правильный подход: accessibilityIdentifier для тестируемых элементов, никогда не текстовые метки. Идентификаторы из shared enum — чтобы они не расходились между приложением и тестами. Опыт показывает: такая практика снижает flakiness на 90%.

Espresso на Android стабильнее из-за IdlingResource механизма — тест автоматически ждёт завершения background операций. Но кастомные async операции (OkHttp, кастомные Executors) нужно регистрировать в IdlingRegistry вручную, иначе тест не синхронизируется с сетевыми запросами. Мы гарантируем правильную настройку IdlingResource на этапе аудита.

Detox и Patrol: end-to-end для React Native и Flutter

Detox — E2E фреймворк для React Native, разработанный Wix. Работает на реальных устройствах и симуляторах через Gray Box подход: знает о состоянии JS thread и синхронизируется с ним. Это решает главный flakiness-источник — тест не нажимает кнопку, пока приложение занято. Настройка Detox нетривиальна. Требует специальный debug-билд с DetoxInstrumentsServer, конфигурации в package.json и отдельного Appium-сервера не нужно. Типичная проблема: тест стабилен на симуляторе, падает на реальном устройстве из-за анимаций. Решение — animations: disabled в Detox конфигурации для E2E билда.

Patrol — аналог для Flutter. Расширяет встроенный integration_test пакет и добавляет возможность взаимодействовать с нативными системными диалогами (permission prompts, notifications) — то, что flutter_driver и базовый integration_test не умеют. Для CI используется через patrol test --target integration_test/app_test.dart.

Appium: кроссплатформа с ценой

Appium — когда нужно покрыть iOS и Android одними тестами. Использует WebDriver протокол, поверх XCUITest и UiAutomator2 драйверов. Скорость ниже нативных фреймворков, но для команд без ресурсов на две тестовые кодовые базы — компромисс. Appium 2.x с плагинной архитектурой заметно удобнее первой версии. appium-doctor диагностирует окружение — полезен при настройке CI.

CI и параллелизация

Для параллельного запуска XCUITest используем Xcode Cloud или xcodebuild test-without-building с несколькими симуляторами через parallel-testing-enabled. Время прогона 200 UI-тестов с параллелизацией на 4 симулятора — с 40 минут до 12. На Android аналогично используем Firebase Test Lab с шардингом.

Типичные ошибки при настройке (и как их избежать)

Как мы это делаем: процесс работы

1. Аудит текущего кода и CI — оцениваем flakiness, покрытие, узкие места.
2. Проектирование тестовой архитектуры — выбираем фреймворк, селекторы, моки.
3. Настройка инфраструктуры — CI пайплайн, parallel execution, отчёты (Allure, Xcode Report).
4. Написание тестов — unit, UI, E2E, performance (XCTMetrics, Macrobenchmark).
5. Интеграция и стабилизация — прогон 200+ тестов, отлов flaky-кейсов.
6. Передача документации — архитектура, запуск, troubleshooting.

Что входит в работу (deliverables)

• Архитектурная документация тестового покрытия
• Настроенный CI-пайплайн с параллелизацией и отчётами
• Код тестов (unit, UI, E2E) с styleguide
• Обучение команды (2 часа воркшопа)
• Доступ к тестовым билдам и CI-логам
• Поддержка в течение месяца после сдачи (фикс flakiness, обновление под новые версии)

Сроки ориентировочно

Настройка инфраструктуры с нуля (CI, unit + UI тесты, отчёты) — 2-3 недели. Написание покрытия для существующего приложения — от 2 недель до месяца в зависимости от объёма. Оценим ваш проект за 2 дня — свяжитесь с нами. 5+ лет опыта в автоматизации, 50+ успешных проектов, сертифицированные специалисты по iOS/Android. Гарантируем стабильность тестов >98% на CI после внедрения.