Поддержка мобильных приложений: мониторинг, хотфиксы и обновления ОС
Приложение в 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 — видно какие actions предшествовали крэшу. Для 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 доступен для критических проблем безопасности и функциональности).