Оперативне виправлення критичних багів мобільного додатку
Оплата перестала працювати у 15% користувачів після оновлення до iOS 17.4. Або на Android 14 додаток падає при відкритті уведомлення — а вчора ще працював. Це критичні баги: вони блокують ключові користувацькі сценарії, й кожна година без виправлення — це втрати конверсії й зростання негативних відзивів.
Що вважати критичним
Не кожен баг вимагає hotfix. Критерії для екстреного виправлення:
- Крешу торкається >1% сесій за останні 6 годин
- Заблоковані оплата, авторизація або core-функціонал додатку
- Уразливість безпеки з можливістю утечі даних
- ANR rate перевищив 1% на Android (ризик попередження від Google)
Баг з неправильним відображенням дати в профілі — не критичний. Падення при спробі зробити замовлення — критичний.
Як працює hotfix-процес
Діагностика (першів 30–60 хвилин)
Дивимось Crashlytics: версія затронутих пристроїв, ОС, конкретний стектрейс. Якщо крешу почалась після конкретного релізу — git diff між версіями звужує пошук. Якщо почалась без релізу — шукаємо зміни на backend (API-ответ, формат даних, новий endpoint).
Типовий сценарій: бэкенд повернув null у полі, яке мобільний клієнт не очікував отримати null — NullPointerException або force-unwrap у Swift (Fatal error: Unexpectedly found nil). Фікс на стороні клієнта — defensive parsing:
// Було — падає при null
val price = response.price.toDouble()
// Стало — graceful handling
val price = response.price?.toDoubleOrNull() ?: 0.0
Розробка й тестування
Hotfix-гілка від поточного production-тегу, не від main. Тільки мінімальне змінення — ніяких «заодно рефакторингів». Тестування на реальному пристрої з версією ОС, на якій воспроізводиться крешу.
Для Android: можна випустити hotfix через staged rollout — спочатку 10%, дивимось на crash-rate у Play Console у реальному часі, потім розширюємо.
Публікація
App Store: екстрений review займає 24–48 годин при стандартній черзі. При реальній критичній ситуації Apple приймає запит на Expedited Review через Resolution Center — рішення в межах кількох годин. Обґрунтування повинна бути конкретним: «crashes for 100% of users on iOS 17.4 during payment».
Google Play: staged rollout 10% → 50% → 100% з кроком 1–2 години при стабільних метриках. Повний rollout на всіх користувачів — протягом дня.
Remote kill switch
Для критичних ситуацій, коли фікс не готовий швидко — можна заздалегідь реалізувати feature flags через Firebase Remote Config. Відключити проблемну фічу без релізу:
// iOS: перевірка флагу перед показом функції
let config = RemoteConfig.remoteConfig()
let isPaymentEnabled = config["payment_enabled"].boolValue
Якщо флаг не був реалізований заздалегідь — це аргумент на користь його додавання після розрішення інциденту.
Після фіксу
Post-mortem: що саме зломалось, чому тест не поймав, що додати в регресійний набір. Не для пошуку винних — для того, щоб наступний аналогічний баг поймати на staging, а не в продакшені.
Орієнтири по строкам
Діагностика й мінімальний фікс стандартної крешу — 2–8 годин. Проблема, пов'язана з змінною поведінки ОС або стороннього SDK (наприклад, змін у AVFoundation після оновлення iOS) — до 2 робочих днів. Вартість розраховується індивідуально після аналізу ситуації.