Как минимизировать риски при релизе мобильного приложения

Что проверяют

Понимаете ли вы, что мобильный релиз необратим: откатить версию у пользователей нельзя, и это меняет весь подход.

Как отвечать

Начните с главного отличия от веба: выпущенную сборку не откатишь. Можно выпустить новую, но она пойдёт через проверку магазина и обновится не у всех сразу. Значит защита строится заранее.

Что делают до релиза:

• проверка обновления поверх старой версии, а не только чистой установки. Миграции локальной базы и изменение формата настроек ломаются именно здесь;
• обратная совместимость с API: у пользователей останутся старые версии приложения на месяцы, и сервер обязан их обслуживать;
• матрица устройств и версий системы, включая слабые и старые, а не только флагман разработчика;
• предрелизное тестирование на внутренней и открытой группе через магазин.

Что делают на релизе:

• поэтапная раскатка: сначала небольшой процент пользователей, с ростом доли по мере наблюдения. При проблеме раскатку останавливают, и это единственный доступный «откат»;
• признаки функций: новая функциональность включается настройкой с сервера, и её можно погасить без выпуска новой версии. Это самая надёжная страховка;
• наблюдение: доля падений и зависаний, ошибки сети, ключевые сценарии по воронке, отзывы в магазине. Смотреть в первые часы, а не через неделю.

И отдельно: механизм принудительного обновления на случай критической ошибки, чтобы приложение могло сообщить пользователю о необходимости обновиться.

Где спотыкаются

Тестируют только чистую установку.

Раскатывают сразу на всех и остаются без вариантов при обнаружении дефекта.

Ломают совместимость API, считая, что все обновятся немедленно.