Технічна підтримка мобільного застосунку після релізу
Ми — команда з 5-річним досвідом пост-релізної підтримки мобільних застосунків. За цей час ми провели понад 50 проєктів — від фінтех-застосунків з мільйонною аудиторією до корпоративних інструментів для логістики. Перші два тижні після публікації в App Store та Google Play — найвразливіший період. Ви тестували на п'яти пристроях, а в продакшені застосунок запускається на сотнях конфігурацій: різні версії ОС, розміри екрану, нестандартні шрифти системи, обмежена пам'ять. Крэші, які не відтворювалися на QA, з'являються в реальних умовах. Наше завдання — нівелювати ці ризики з першого дня.
Чому моніторинг критичний?
Firebase Crashlytics фіксує crash-free rate — у нового застосунку він рідко буває вище 99.5% одразу після релізу. Кожний необроблений крэш — це користувач, який видаляє застосунок і ставить 1 зірку. Без моніторингу ці крэші накопичуються днями, перш ніж команда дізнається про проблему.
Типова ситуація: витік пам'яті в RecyclerView на Android 8.x, який не відтворити на емуляторі з Android 13. Користувачі з конкретними пристроями (Xiaomi MIUI 12, Samsung One UI 3.x) стикаються з OOM-крэшем на екрані каталогу. Без підтримки це виявляється через 2–3 тижні за накопиченими відгуками.
Що входить у технічну підтримку
Моніторинг крэшів та ANR — технічна підтримка мобільного
Щоденний перегляд Firebase Crashlytics та Google Play Console (Android Vitals). Пріоритизація за crash-free rate: якщо падає нижче 99%, це критично. ANR-рейт вище 0.47% — Google знижує видимість застосунку в пошуку.
Для iOS — моніторинг Xcode Organizer (Crashes) та MetricKit для memory/CPU. MetricKit доставляє діагностику на пристрої раз на 24 години:
// Підписка на MetricKit діагностику class AppDelegate: UIResponder, MXMetricManagerSubscriber { func didReceive(_ payloads: [MXMetricPayload]) { // Аналіз CPU, memory, disk usage } func didReceive(_ payloads: [MXDiagnosticPayload]) { // Crash logs, hang logs } } Triage нових крэшів
Для кожного нового крэшу визначаємо: зачеплених користувачів, версію ОС, пристрій, build версію. Якщо крэш зачіпає >0.1% сесій — створюємо hotfix-гілку.
Відповіді на технічні відгуки
Відгуки зі згадуванням технічних проблем в App Store та Google Play — частина підтримки. Користувач описав крэш у відгуку швидше, ніж напише в support-форму. Моніторимо ключові слова: «вилітає», «не відкривається», «зависає», «помилка».
Оновлення залежностей
Через 1–2 місяці після релізу виходять патч-версії Firebase SDK, Retrofit, Alamofire з фіксами безпеки. Без регулярного оновлення проєкт накопичує вразливості. Оновлюємо з перевіркою на regression.
Типові помилки при пост-релізній підтримці
- Ігнорування нестабільних крэшів з малим відсотком зачеплення (вони можуть стати масовими після оновлення ОС).
- Відсутність автоматизації тестування hotfix-релізів — ручне тестування затягує випуск.
- Невикористання staged rollout на Google Play — ризик викотити баг на 100% аудиторії.
Як організувати hotfix-процес?
Покрокова інструкція для критичного крэшу:
- Виявлення: Crashlytics alert при падінні crash-free rate нижче 99%.
- Triage: аналіз логу, визначення версії ОС та пристрою.
- Фікс: створення hotfix-гілки від останнього стабільного тегу.
- Тестування: smoke-тести на 3–5 реальних пристроях.
- Деплой: для iOS — TestFlight + рев'ю, для Android — staged rollout 10→100%.
- Моніторинг: контроль crash-free rate після викатки протягом 2 годин.
Метрики та пороги для реагування
| Метрика | Поріг | Дія |
|---|---|---|
| Crash-free rate | < 99% | Hotfix-реліз |
| ANR rate | > 0.47% | Оптимізація UI-потоку |
| Crash sessions | > 0.1% | Triage та hotfix |
Як ми організуємо процес?
| Етап | Тривалість | Опис |
|---|---|---|
| Налаштування моніторингу | 1–2 дні | Crashlytics alerts, Slack-сповіщення, Dashboard у Firebase |
| Щоденний triage | 30–60 хв | Перегляд нових крэшів та ANR, пріоритизація |
| Щотижневий звіт | 1 год | Crash-free rate, топ-3 проблеми, статус фіксів |
| Hotfix-реліз | 24–48 годин | App Store review, staged rollout на Google Play |
Що робити при критичному крэші?
Якщо crash-free rate падає нижче 99%, ми негайно починаємо triage. Створюємо hotfix-гілку, фіксимо проблему, запускаємо мінімальне тестування та випускаємо оновлення. Для iOS враховуємо час рев'ю в App Store — в середньому 24–48 годин. Для Google Play використовуємо staged rollout: спочатку 10% аудиторії, потім 100%.
Орієнтири за термінами
Початкове налаштування моніторингу та процесів — 1–2 дні. Ongoing-підтримка розраховується індивідуально залежно від активної аудиторії та частоти релізів. Отримайте консультацію щодо технічної підтримки вашого застосунку — зв'яжіться з нами для оцінки вашого проєкту.