Моніторинг мобільного застосунку: Crashlytics, ANR, продуктивність

У продакшені кожна хвилина простою — втрачені користувачі та гроші. Crash-free rate 99.2% звучить непогано, доки не порахувати: при 100 000 DAU це 800 крашів на день. Без інструментів моніторингу команда дізнається про проблему з відгуків в App Store — із затримкою в кілька годин, коли сотні користувачів уже зіткнулися з помилкою. Ми вирішуємо це завдання: налаштовуємо повний цикл моніторингу — від інтеграції Crashlytics до алертів у Telegram. Наш досвід — 5+ років у мобільній розробці, ми провели 50+ релізів з гарантією стабільності. Зв'яжіться з нами для безкоштовного аудиту поточного стану вашого застосунку.

Чому моніторинг мобільного застосунку — необхідність?

Кожен відсоток падіння crash-free rate обходиться в десятки тисяч доларів втрати виручки через відтік користувачів та зниження рейтингу в сторах. Інвестиція в моніторинг окупається за 2-3 місяці. За даними Google, застосунок з ANR rate вище 0.47% втрачає до 20% користувачів. Налаштувавши алертинг, ви скорочуєте час реакції на краш з 4 годин до 10 хвилин — це зберігає дохід та репутацію.

Економія від впровадження моніторингу може досягати 30% бюджету на підтримку, а вартість інциденту в середньому становить десятки тисяч гривень. Своєчасне налаштування алертів дозволяє швидко локалізувати проблему та мінімізувати збитки. Замовте аудит стабільності та отримайте рекомендації.

Які метрики критичні в продакшені? — моніторинг мобільного застосунку

Креші та помилки

Основний інструмент — Firebase Crashlytics. Автоматично перехоплює fatal та non-fatal виключення, групує по стектрейсу, показує зачеплених користувачів та сесії. Ключові метрики для щоденного контролю:

• Crash-free users (не sessions) — реальна картина по користувачах
• Velocity alerts — Crashlytics вміє надсилати сповіщення, коли новий кріш зачіпає N% сесій за годину
• Regression tracking — був кріш, закрили, з'явився знову в новій версії

Для NDK/C++ компонентів потрібно окремо налаштовувати nativeSymbolUploadEnabled = true та завантажувати .so символи через Crashlytics CLI.

ANR та зависання (Android)

Google Play Console → Android Vitals → ANR rate. Порогове значення Google — 0.47% ANR-rate, вище нього застосунок позначається як проблемний та знижується в пошуку. ANR на головному потоці найчастіше означає блокуючий IO або синхронний запит до бази даних в onCreate.

StrictMode в Debug-збірках допомагає зловити такі місця до продакшену:

if (BuildConfig.DEBUG) {
    StrictMode.setThreadPolicy(
        StrictMode.ThreadPolicy.Builder()
            .detectDiskReads()
            .detectNetwork()
            .penaltyLog()
            .build()
    )
}

Продуктивність (iOS MetricKit)

MetricKit з iOS 14 доставляє агреговані дані по діагностиці: hang rate, crash rate, disk writes, launch time. Дані приходять раз на добу в didReceive(_ payloads: [MXMetricPayload]). Для моніторингу launch time критично відстежувати applicationLaunchMetrics.histogrammedTimeToFirstDraw — деградація на 200ms вже впливає на утримання. Детальніше — в документації Apple (Developer Documentation).

Нестандартні події

Firebase Crashlytics дозволяє логувати non-fatal помилки вручну — це важливо для бізнес-критичних флоу:

// iOS: логуємо помилку оплати як non-fatal
Crashlytics.crashlytics().record(error: paymentError)
Crashlytics.crashlytics().log("Payment failed at step: \(step)")

// Android
FirebaseCrashlytics.getInstance().recordException(exception)
FirebaseCrashlytics.getInstance().log("Checkout step: $step")

Так у Crashlytics з'являються «м'які» помилки — користувач не побачив краша, але транзакція не пройшла.

Як налаштувати алертинг для швидкого реагування?

Налаштовуємо сповіщення в Slack або Telegram через Crashlytics webhooks або Firebase Extensions. Мінімальний набір алертів:

Алертинг через Slack в 3 рази швидше реагування на відгуки в сторах — ви дізнаєтеся про проблему протягом хвилини.

Що входить у налаштування моніторингу під ключ?

В рамках послуги ми надаємо:

• Інтеграція Crashlytics та налаштування velocity alerts
• Підключення алертів у Slack/Telegram
• Налаштування Android Vitals та MetricKit
• Документація по метриках та діях при інцидентах
• Навчання команди: як читати звіти та розбирати краші
• Доступи до інструментів моніторингу

Гарантуємо стабільну роботу: після налаштування ви отримуєте показники crash-free rate не нижче 99.9% на цільовому рівні.

Чек-лист: що перевірити перед налаштуванням моніторингу

• Переконайтеся, що в проекті є Crashlytics SDK останньої версії.
• Перевірте, чи налаштований ProGuard/R8 для Android — щоб не вирізати логи.
• Для iOS: налаштуйте Bitcode та символізацію крашів.
• Визначте список бізнес-критичних флоу для non-fatal логування.
• Узгодьте канали оповіщення (Slack/Telegram) та відповідальних.

Процес роботи

1. Аналітика — вивчаємо поточні інструменти та код на предмет логування
2. Проектування — визначаємо ключові метрики та пороги спрацювання
3. Реалізація — інтегруємо SDK, налаштовуємо non-fatal логи
4. Тестування — емулюємо краші та перевіряємо алерти
5. Деплой — розгортаємо на стейджинг, потім продакшен

Орієнтири по термінах

Первинне налаштування повного моніторингу — від 1 до 3 днів залежно від складності проекту. Ongoing-моніторинг та щотижневі звіти — обговорюється індивідуально. Зв'яжіться з нами для оцінки вашого проекту — ми підготуємо точний кошторис та терміни.

Кейс з практики: Один із наших клієнтів зіткнувся з падінням crash-free rate до 99.0% після виходу нової версії. Завдяки velocity alert ми помітили проблему через 10 хвилин, а за годину з'ясували причину — витік пам'яті в UICollectionView. Користувачі навіть не встигли залишити негативні відгуки.

Отримайте консультацію — ми безкоштовно проаналізуємо поточний стан вашого застосунку та запропонуємо план моніторингу. Замовте аудит стабільності прямо зараз.

Підтримка мобільних додатків: моніторинг, хотфікси та оновлення ОС

Після виходу нової 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 разів порівняно з ручним логуванням.

Хотфікси: що можна зробити без публікації в стор

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:

На Android target SDK зобов'язаний оновлюватися щорічно. Google Play вимагає targetSdk мінімум Android -1. Перехід з targetSdk 33 на 34 змінює behaviour для foreground services, broadcast receivers, implicit intents. Ми тестуємо на реальних пристроях із кожною бетою, щоб уникнути сюрпризів у день релізу.

Як підготувати додаток до нової версії ОС: покроковий план

1. Завантажити бета-версію Xcode або Android Studio.
2. Зібрати проект з новим SDK і виправити компіляційні помилки.
3. Запустити на реальному пристрої та перевірити критичні flows (авторизація, платежі, push-сповіщення).
4. Оновити залежності з відомими вразливостями через Dependabot.
5. Виправити deprecated API, які будуть видалені в релізі.
6. Зімітувати сплеск користувачів (load testing) для виявлення race conditions.
7. Опублікувати оновлення за 2 тижні до релізу ОС.

Процес роботи

Технічний борг та планування

Підтримка — це не тільки реакція на баги. Ми плануємо технічний борг: застарілі залежності з відомими вразливостями (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 додатків.