Технічна підтримка мобільного застосунку після релізу

Технічна підтримка мобільного застосунку після релізу

Ми — команда з 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-процес?

Покрокова інструкція для критичного крэшу:

1. Виявлення: Crashlytics alert при падінні crash-free rate нижче 99%.
2. Triage: аналіз логу, визначення версії ОС та пристрою.
3. Фікс: створення hotfix-гілки від останнього стабільного тегу.
4. Тестування: smoke-тести на 3–5 реальних пристроях.
5. Деплой: для iOS — TestFlight + рев'ю, для Android — staged rollout 10→100%.
6. Моніторинг: контроль crash-free rate після викатки протягом 2 годин.

Метрики та пороги для реагування

Як ми організуємо процес?

Що робити при критичному крэші?

Якщо crash-free rate падає нижче 99%, ми негайно починаємо triage. Створюємо hotfix-гілку, фіксимо проблему, запускаємо мінімальне тестування та випускаємо оновлення. Для iOS враховуємо час рев'ю в App Store — в середньому 24–48 годин. Для Google Play використовуємо staged rollout: спочатку 10% аудиторії, потім 100%.

Орієнтири за термінами

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

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

Після виходу нової 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 додатків.