Підтримка мобільних додатків: моніторинг, хотфіксі та оновлення ОС
Додаток у App Store — це не здданий проект, а жива система. iOS 18 змінює поведінку Background App Refresh. Android 15 ужесточує foreground service policy. Новий iPhone 17 з іншим співвідношенням сторін ломає hardcoded layout. Все це вимагає реакції без повного циклу розробки.
Crash Monitoring у продакшні
Firebase Crashlytics відправляє alert при зростанні crash rate вище порога. Але достатньо просто отримати сповіщення — потрібен процес реагування.
Метрика, на яку дивимось в першу чергу: crash-free users rate. Менше 99.5% — тривожний сигнал. Менше 99% — інцидент. Google Play Console та App Store Connect показують свої метрики, які рахуються інакше чим Crashlytics — розхідження нормальне.
Типовий сценарій: після релізу iOS 18.1 з'являється новий краш у UISheetPresentationController на пристроях з iOS 18.1 та конкретною версією додатку. Crashlytics показує 0.3% affected users, але зростаючий velocity. Оперативно: верифікуємо на пристрої, знаходимо причину (зміна поведінки detents у iOS 18.1), випускаємо хотфікс.
Для React Native додатково використовуємо Sentry з breadcrumbs — видно які дії передували крешу. Для Flutter — sentry_flutter з WidgetsFlutterBinding.ensureInitialized() та runZonedGuarded.
Хотфіксі: що можна без публікації в стор
App Store не дозволяє змінювати виконуваний код без ревю (Review Guideline 2.5.2). Але є легальні механізми оперативного втручання.
Remote Config (Firebase або власний) — зміна поведінки через флаги без оновлення. Відключити проблемну фічу, показати maintenance banner, змінити URL endpoint — все без релізу. Критично для монетизаційних експериментів та швидкого rollback.
OTA обновлення (React Native): react-native-code-push (Microsoft CodePush) або Expo Updates дозволяють оновлювати JS-бандл без App Store. Обмеження: тільки JS-код, нативні модулі вимагають повного оновлення. І все одно підпадає під обмеження гайдлайнів при зловживанні — не можна змінювати ключову функціональність через OTA.
Expo EAS Update — сучасна альтернатива CodePush для Expo-проектів з підтримкою каналів (production/staging) та rollback.
Оновлення ОС: підготовка та тестування
Apple анонсує iOS beta в червні (WWDC), фінальний релиз — у вересні. Це дає три місяці на тестування. На практиці багато команд починають у серпні та отримують сюрпризи в день релізу.
Критичні області перевірки при кожному major iOS update:
- Privacy Manifest — з iOS 17 обов'язковий для використання ряду API. Без нього reject при ревю
-
UIScenelifecycle зміни - Зміни в
UICollectionViewтаUITableViewанімаціях - Swift Concurrency поведінка
На Android аналогічно: target SDK зобов'язаний оновлюватись щорічно (Google Play вимагає targetSdk мінімум Android -1). Перехід з targetSdk 33 на 34 змінює behaviour для foreground services, broadcast receivers, implicit intents.
Технічний борг та планування
Підтримка — це не лише реакція на баги. Планюємо технічний борг у backlog: застаріли зависимості з відомими уразливостями (npm audit / bundler-audit), deprecated API які будуть удалені в наступному Xcode, бібліотеки без активної підтримки.
Dependency updates через Dependabot (GitHub) або Renovate автоматично створюють PR при виході нових версій. Це не избавляє від тестування, але исключає ситуацію «ми не оновлювали бібліотеки два роки».
Мінімальна підтримувана версія ОС — переглядаємо щорічно. Apple публікує статистику версій, Google — Android distribution dashboard. Підняття мінімальної версії з iOS 15 на iOS 16 дозволяє видалити значний обсяг workaround-коду.
Строки реагування на краш: хотфікс при критичному крешу (crash rate >1%) — протягом 24-48 годин до публікації, 3-7 днів до проходження ревю Apple (Expedited Review доступен для критичних проблем безпеки та функціональності).