Удаление приложений из App Store и Google Play: что делать бизнесу

Тема актуальна: за последние дни сразу два инцидента напомнили, как быстро приложение может выпасть из стора. Иногда это происходит по решению платформы, иногда — из-за чужого бага.

Сбой, который выключил чужие продукты

По данным gazeta.press со ссылкой на Android Authority, тысячи iOS-приложений начали падать при запуске из-за ошибки в Google Analytics для Firebase. Firebase SDK — это набор библиотек, через которые приложения подключаются к облачным сервисам Google: аналитике, push-уведомлениям, аутентификации. Один баг в чужом коде — и приложения, которые годами работали стабильно, начали крашиться примерно в одно и то же время.

Пользователь в этот момент видит простую картину: тап по иконке, мёртвый экран, повторный тап, снова ничего. Разработчики в трекере проблем Firebase на GitHub описывали панику: один из них потратил значительное количество AI-токенов на отладку собственного приложения, решив, что сломал что-то сам. Другие догадались о связи с Firebase, но могли только ждать патча и смотреть, как растёт счётчик сбоев. Google выпустила исправление через несколько часов, но предупредила: из-за кэширования часть приложений будет падать ещё до четырёх часов после развёртывания фикса. При этом панель статуса Firebase не показала зарегистрированного инцидента, а причина сбоя на момент публикации не была объяснена полностью.

Когда стор решает сам

Как сообщает HT Tech, в Google Play обнаружено 20 вредоносных приложений, которые маскировались под моды для Minecraft. Подробностей о том, какие именно приложения попали в список и были ли они уже удалены, в открытом доступе немного. Сам паттерн при этом знакомый: платформа регулярно вычищает софт, нарушающий правила, и для разработчика это означает мгновенную потерю канала дистрибуции.

Что отслеживать

Из этих двух историй складываются несколько практических выводов. Первое: стоит знать, какие внешние SDK стоят на критическом пути запуска. Если падает аналитика, само приложение не должно падать вместе с ней. Второе: полезно заранее продумать, как быстро откатить релиз или отключить проблемный модуль, если внешний сервис уходит в даунтайм. Третье: иметь альтернативный канал доступа к пользователю — веб-версию, рассылку, прямые ссылки, — чтобы не терять его в первые минуты инцидента. Наконец, нельзя полагаться только на официальные статус-панели внешних сервисов: если Firebase не отразил собственный сбой в дашборде, команде нужен собственный мониторинг.

Удаление из стора по решению платформы и недоступность из-за чужого бага — разные сценарии. Результат один: пользователь не может открыть приложение. Этот момент и стоит проектировать заранее.