Ви оновили compileSdkVersion до 35, а minSdkVersion залишили на 26. Через тиждень у продакшені на Android 10 падає NoSuchMethodError. Silent failure через відсутність NotificationChannel на Android 7 — користувачі скаржаться, що немає сповіщень. Такі баги виникають, коли код використовує API новіше за мінімальну версію ОС. Ми стикалися з цим десятки разів і навчилися виявляти такі проблеми до релізу. Наша послуга — кросверсійне тестування мобільного застосунку — гарантує, що всі функції працюють коректно на кожній підтримуваній версії ОС, без артефактів UI та вильотів. Замовте аудит сумісності та отримайте матрицю версій за 2 дні.
Тестування сумісності: повний цикл перевірки на різних версіях ОС
Як вибрати матрицю версій для тестування сумісності?
Тестувати кожну версію ОС нераціонально. Ми використовуємо принцип пріоритетів, заснований на аналітиці та вимогах проєкту.
| Пріоритет | Версії iOS | Версії Android |
|---|---|---|
| Обов'язково | Поточна − 1 (наприклад, iOS 17, 18) | Android 12, 13, 14 (API 31–34) |
| Важливо | minDeploymentTarget (наприклад, iOS 15) |
minSdkVersion (наприклад, API 26–28) |
| За аналітикою | Версії з часткою > 5% у вашої ЦА | Те ж саме |
Аналітика Firebase або Mixpanel за полем os_version дає реальну картину. Якщо 8% користувачів на iOS 15 — тестуємо цю версію. Якщо 0.3% на iOS 14 — пропускаємо. Такий підхід скорочує обсяг робіт без втрати якості. Крім того, корисно включити до матриці версії, на яких відбулися великі зміни API — наприклад, Android 12 (API 31) зі зміненим exported в intent-фільтрах.
Чому deprecated API — головна проблема сумісності?
Розрив між minSdkVersion та compileSdkVersion — 8 років еволюції API. Пропустити одну deprecated-заміну — і застосунок падає на старих версіях. Ми системно ловимо такі проблеми за допомогою статичного аналізу та точкового тестування.
Android: три часті пастки
Сповіщення (API 26+). На Android 8+ всі сповіщення вимагають NotificationChannel. Без нього notify() тихо ігнорується. Код перевірки:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) { val channel = NotificationChannel(CHANNEL_ID, "General", NotificationManager.IMPORTANCE_DEFAULT) notificationManager.createNotificationChannel(channel) } Дозволи (API 33+). READ_EXTERNAL_STORAGE замінено на гранульовані READ_MEDIA_IMAGES, READ_MEDIA_VIDEO, READ_MEDIA_AUDIO. Запит старого дозволу на Android 13 не дає доступу до медіа.
Foreground Service (API 34+). Android 14 вимагає вказувати тип foreground service (dataSync, mediaPlayback та ін.) — без нього SecurityException.
| API | Версія Android | Типова проблема |
|---|---|---|
| NotificationChannel | API 26+ | Без channel notify() ігнорується |
| Granular media permissions | API 33+ | READ_EXTERNAL_STORAGE не працює |
| Foreground service type | API 34+ | SecurityException без типу |
Інструмент для перевірки: lint з правилом NewApi. Він автоматично знаходить виклики API, доступні вище minSdkVersion без @RequiresApi або перевірки Build.VERSION.SDK_INT. Досвід показує, що lint знаходить 80% проблем до запуску.
iOS: @available та #available
if #available(iOS 16.0, *) { NavigationStack { ... } } else { NavigationView { ... } } Компілятор попереджає про використання нового API без перевірки — це ловиться статично. Але у великих кодових базах такі попередження губляться. Найчастіші жертви: ContentUnavailableView (iOS 17), NavigationStack (iOS 16), Charts (iOS 16) — без fallback застосунок падає з dyld: Symbol not found. Детальніше — у документації @available.
Інструмент для iOS: Xcode Simulator
Завантажуємо додаткові runtime: Xcode → Settings → Platforms → + → iOS 15.x Simulator Runtime. Після завантаження створюємо симулятор та перевіряємо на ньому.
Як автоматизувати пошук deprecated API?
Статичний аналіз з lint та Xcode Build & Analyze знаходить несумісності в 10 разів швидше за ручний пошук. Ми запускаємо його в CI на кожен PR. Для глибшої перевірки використовуємо Firebase Test Lab — віртуальні пристрої з різними API-рівнями. Це швидко, дешево та покриває більшість несумісностей. Наприклад, на одному з проєктів ми знайшли 12 deprecated API до релізу, що зекономило клієнту значну частину бюджету на виправлення в продакшені.
Як ми тестуємо без реальних пристроїв?
Емулятори покривають 90% випадків. Реальні пристрої потрібні лише для специфічних прошивок (Samsung, Xiaomi) або апаратних особливостей (камера, NFC). Ми комбінуємо:
- В CI: прогін lint + збірка з
-Werrorдля iOS. - Smoke-тести на емуляторах з мінімальною, середньою та поточною версіями ОС.
- Firebase Test Lab для інтеграційних сценаріїв.
Це дає швидкий зворотний зв'язок без витрат на фізичні девайси. Ви економите на дорогих виправленнях після релізу та оптимізуєте бюджет на тестування.
Процес роботи
- Аудит поточної
minSdkVersion/minDeploymentTargetта аналітика розподілу версій. - Складання матриці підтримуваних версій з пріоритетами.
- Статичний аналіз на deprecated API (lint/Xcode) з повним списком знайдених проблем.
- Тестування на пріоритетних версіях (smoke + точкове).
- Звіт з матрицею сумісності та рекомендаціями щодо виправлення.
- Консультація щодо спірних моментів та допомога з виправленням коду.
Зв'яжіться з нами, щоб обговорити ваш застосунок та отримати індивідуальний план тестування.
Що входить в роботу
- Документація: матриця підтримуваних версій з пріоритетами, список знайдених несумісностей, рекомендації щодо виправлення.
- Доступи до звітів у Firebase Test Lab та CI-логах.
- Консультації щодо виправлення коду та адаптації під старі версії ОС.
- Підтримка впродовж 5 робочих днів після здачі звіту.
Досвід нашої команди — понад 7 років у мобільній розробці, 40+ протестованих застосунків з аудиторією від 50 000 користувачів. Оцінимо ваш проєкт за 2 дні. Зв'яжіться з нами, щоб отримати консультацію. Замовте тестування та отримайте повний звіт з матрицею сумісності.