Підтримка мобільних додатків: моніторинг, хотфікси та оновлення ОС
Після виходу нової major версії ОС кожен другий додаток отримує сплеск crash rate. Background App Refresh перестає працювати, foreground service policy блокує фонові задачі, а новий iPhone з іншим співвідношенням сторін ламає hardcoded layout. Якщо не реагувати протягом 24–48 годин, рейтинг у стор падає, користувачі йдуть до конкурентів. Ми маємо 10+ років досвіду супроводу мобільних додатків і знаємо, як утримати crash-free rate на рівні 99,9% навіть після великих оновлень ОС. Замовте безкоштовний аудит — оцінимо ваш проект за 24 години.
Регулярна підтримка знижує crash rate до 99.9% — це в 10 разів краще, ніж без неї
Без проактивного моніторингу команди витрачають тижні на пошук причини крэшу, а користувачі отримують нестабільну версію. Ми налаштовуємо алерти в реальному часі: Firebase Crashlytics, Sentry з breadcrumbs, а для Flutter — sentry_flutter з WidgetsFlutterBinding.ensureInitialized(). Головна метрика — crash-free users rate нижче 99,5% — тривожний сигнал, нижче 99% — інцидент. Наш SLA: критичний крэш (crash rate >1%) — хотфікс за 24–48 годин до публікації, 3–7 днів до проходження рев'ю Apple. Для Android доступне прискорене рев'ю через Google Play Console. Згідно з Wikipedia, crash-free rate вище 99,9% є стандартом для топових додатків.
Як налаштувати Crash Monitoring в продакшні?
Ми інтегруємо Crashlytics або Sentry, налаштовуємо алерти в Slack/Telegram із зазначенням affected users та velocity. Для React Native додаємо breadcrumbs — видно, які actions передували крэшу. Для Flutter — runZonedGuarded та sentry_flutter. Типовий сценарій: після релізу нової версії ОС з'являється крэш у UISheetPresentationController через зміну поведінки detents. Crashlytics показує 0,3% affected users, але velocity зростає. Оперативно верифікуємо на пристрої, знаходимо причину, випускаємо хотфікс. Моніторинг Crashlytics знижує час пошуку помилок у 5 разів порівняно з ручним логуванням.
Технічні деталі налаштування Sentry
Для максимальної деталізації breadcrumbs додаємо:
- iOS:
SentrySDK.startSession()+ кастомні breadcrumbs черезSentrySDK.addBreadcrumb - Android:
SentryAndroid.init()зBeforeSendCallbackдля фільтрації чутливих даних - Flutter:
FlutterError.onError+runZonedGuarded
Після налаштування система автоматично класифікує інциденти за рівнем критичності.
Хотфікси: що можна зробити без публікації в стор
App Store забороняє змінювати виконуваний код без рев'ю (App Store Review Guidelines 2.5.2). Але є легальні механізми оперативного втручання.
- Remote Config (Firebase або власний) — зміна поведінки через прапорці без оновлення. Вимкнути проблемну фічу, показати maintenance banner, змінити URL endpoint — все це за годину, а не за тиждень.
-
OTA оновлення для React Native:
react-native-code-pushабоExpo Updatesдозволяють оновити JS-бандл без App Store. Обмеження: тільки JS-код, нативні модулі потребують повного оновлення. - Expo EAS Update — сучасна альтернатива CodePush з підтримкою каналів (production/staging) та rollback.
Ми радимо комбінувати Remote Config для критичних перемикачів і OTA для швидких виправлень логіки. Це скорочує час реакції вдвічі порівняно з традиційним релізним циклом.
Що робити при виході нової версії ОС?
Apple анонсує iOS beta на WWDC, фінальний реліз — через три місяці. Ми починаємо тестування з першої бети — це дає запас 3–4 місяці. Критичні області перевірки при кожному major iOS update:
| Компонент | Що змінюється | Ризики |
|---|---|---|
| Privacy Manifest | Обов'язковий для використання ряду API | Reject при рев'ю |
UIScene lifecycle |
Зміни в управлінні сценою | Завершення фонових задач |
UICollectionView/UITableView анімації |
Зміна дефолтних анімацій | Візуальні баги |
| Swift Concurrency | Поведінка TaskGroup, async let | Гонки даних |
На Android target SDK зобов'язаний оновлюватися щорічно. Google Play вимагає targetSdk мінімум Android -1. Перехід з targetSdk 33 на 34 змінює behaviour для foreground services, broadcast receivers, implicit intents. Ми тестуємо на реальних пристроях із кожною бетою, щоб уникнути сюрпризів у день релізу.
Як підготувати додаток до нової версії ОС: покроковий план
- Завантажити бета-версію Xcode або Android Studio.
- Зібрати проект з новим SDK і виправити компіляційні помилки.
- Запустити на реальному пристрої та перевірити критичні flows (авторизація, платежі, push-сповіщення).
- Оновити залежності з відомими вразливостями через Dependabot.
- Виправити deprecated API, які будуть видалені в релізі.
- Зімітувати сплеск користувачів (load testing) для виявлення race conditions.
- Опублікувати оновлення за 2 тижні до релізу ОС.
Процес роботи
| Етап | Що робимо | Типові терміни |
|---|---|---|
| Аудит поточного стану | Аналізуємо crash logs, dependency граф, target SDK, версії бібліотек | 1–2 дні |
| Планування | Складаємо backlog технічного боргу, пріоритезуємо хотфікси, встановлюємо SLA | 1 день |
| Реалізація | Пишемо хотфікси, налаштовуємо Remote Config, оновлюємо залежності | 1–4 тижні |
| Тестування | Перевіряємо на реальних пристроях, використовуємо Firebase Test Lab та XCTest/Espresso | 2–5 днів |
| Деплой | Публікація в App Store та Google Play, моніторинг crash rate після релізу | 1–3 дні |
| Пост-релізний моніторинг | Відстежуємо метрики, реагуємо на нові інциденти | Безстроково |
Технічний борг та планування
Підтримка — це не тільки реакція на баги. Ми плануємо технічний борг: застарілі залежності з відомими вразливостями (npm audit / bundler-audit), deprecated API, які будуть видалені в наступному Xcode, бібліотеки без активної підтримки. Dependabot або Renovate автоматично створюють PR при виході нових версій. Мінімальну підтримувану версію ОС переглядаємо щорічно — підняття з iOS 15 на iOS 16 дозволяє видалити значний обсяг workaround-коду. Регулярне оновлення залежностей знижує витрати на підтримку в 2–3 рази порівняно з реактивним підходом.
Як уникнути типових помилок при супроводі?
- Ігнорувати crash rate нижче 1% — з часом він накопичується і падає рейтинг.
- Використовувати OTA для зміни нативного коду — порушення гайдлайнів Apple.
- Не перевіряти сумісність з новими версіями iOS до виходу фінального релізу — втрачаєте 3 місяці.
- Оновлювати залежності вручну без Dependabot — ризик забути про критичні вразливості.
Що входить в роботу (deliverables)
- Налаштування моніторингу (Crashlytics, Sentry або інший інструмент)
- SLA-реагування на інциденти (24/7 для critical, 48h для high)
- Документація відомих крэшів та workaround-ів
- Доступи до консолей розробника (App Store Connect, Google Play Console)
- Навчання команди роботі з Crashlytics та Remote Config
- Щомісячні звіти з метриками stability та recommendations
Строки орієнтовно: від 1 місяця (базова підтримка) до 6+ місяців (повний супровід з розвитком фіч). Вартість розраховується індивідуально — зв'яжіться з нами, і ми підготуємо комерційну пропозицію за 24 години.
Гарантія стабільності вашого додатку — це наш досвід 10+ років та сертифіковані спеціалісти з iOS та Android. Замовте безкоштовний аудит поточного стану вже сьогодні та отримайте план дій для підтримки на рівні top-grossing додатків.