Обновление мобильного приложения выпускают с проверкой клиентов, которые ещё не установили новую версию

Apple распределяет поэтапное автообновление за семь дней: от 1 % в первый день до 100 % в последний. Речь о подходящих устройствах с включёнными автообновлениями. При этом вручную скачать новую сборку можно в любой день, ещё до завершения этапов.

В Google Play команда сама увеличивает долю выпуска. Документация предупреждает, что получение обновления выбранной группой занимает время. Если остановить выпуск, уже получившие новую сборку остаются на ней.

Фича-флагами новой функции управляют доступом первых пользователей без отдельной версии продукта.

В вымышленном примере приложения заказа старый клиент читает итог из поля total, а новый сервер после переименования отдаёт amount. Магазин может исправно распространять сборку, но прежний клиент уже не прочитает сумму. Этот пример дальше используем как задачу для приёмки.

Перед правкой API команде нужен список сборок, которые она обязуется обслуживать. Его сверяют с обращениями к серверу: платформа, номер сборки, используемый метод, результат запроса. Срок наблюдения указывают в отчёте; отсутствие запросов за короткое окно ещё не означает, что клиент исчез.

Часть клиентов возвращается редко или отправляет сохранённый заказ после работы без сети. Поэтому отдельно проверяют офлайн-очередь и повторную отправку. Запрос без номера сборки оставляют в группе «неизвестно», пока не выяснят его источник.

Сохранение прежнего API может выглядеть как лишний код. Но удалять его до согласованного конца поддержки рискованно. Разбор технического долга помогает убрать дублирование; срок отказа от старого клиента задаёт владелец продукта, а не агент по отсутствию вчерашних запросов.

Google AIP-180 рассматривает API как контракт с существующим кодом. Переименование поля, смена его типа или новое обязательное поле запроса могут нарушить этот контракт. В нашем примере total сохраняют для поддерживаемого клиента, а amount вводят в отдельном контракте для новых сборок, например в новой версии API.

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

В задаче для агента перечисляют сборки, сценарий и ожидаемый итог. «Обнови API» не задаёт приёмку. «Поддерживаемый старый клиент оформляет заказ на новом сервере, сумма совпадает, повторная отправка не создаёт второй заказ» уже можно проверить.

Сначала выпускают сервер, который понимает прежний и новый запросы, затем распространяют проверенную сборку с выключенной новой функцией. После наблюдения включают её тем клиентам, которые умеют с ней работать. Для такого разделения подходят переключатели функций; Firebase Remote Config, например, поддерживает условия по версии приложения.

Переключатель помогает только там, где нужное поведение уже предусмотрено в коде. Проверяют и случай без сети или свежей конфигурации. Скрытая кнопка в приложении также не заменяет серверную проверку права выполнить действие.

Перед выпуском назначают того, кто может остановить распространение и выключить функцию. Ответственность за выпуск включает проверенный способ возврата рабочего поведения. Если новый клиент уже установлен, возвращаемый сервер должен понимать и его; изменения данных с необратимым результатом требуют отдельного решения.

В машине vibecoding.ru зелёные тесты однажды пропустили несовпадение ответа функции с его валидатором. Новое поле появилось в ответе, а описание допустимых полей осталось прежним. После выпуска страницы новостей отвечали ошибкой HTTP 500.

Это веб-инцидент, не мобильный кейс. Но урок подходит к приёмке API: проверить нужно обе стороны взаимодействия. Проверка, которая смотрит лишь на наличие нового поля, не доказывает, что прежний получатель его примет.

Инженер ведёт машину агентов и добавляет найденную причину в проверки. В курсе агентной разработки этому пути посвящён урок «Одиннадцать шагов одной задачи». Для мобильного заказа результатом такого пути будет правка вместе с воспроизводимой проверкой совместимости.

Фраза «обновить мобильное приложение» может означать новый экран, изменение API или замену механизма входа. Начните с одного критического сценария и списка затронутых сборок. В условном приложении это заказ: клиент видит сумму, отправляет его, затем видит правильный результат.

Агентам можно поручить карту затронутых методов, тесты прежнего контракта, правку сервера и отчёт о прогоне. Инженер проверяет результат и границы доступа. Политику поддержки, изменение данных и право включить выпуск согласует владелец приложения.

Если такой сценарий есть, можно обсудить подготовку релиза. Для разговора подготовьте доступные сборки, описание новой функции и правило, какие клиенты должны продолжать работать. По этому адресу открывается страница услуг.

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

Подготовку такого релиза можно обсудить как задачу в потоке «Один проект»: подписка на разработку стоит 250 000 ₽ в месяц на 8 октября 2026. Это цена одного продукта и одного потока работ, не смета отдельного мобильного релиза. На старте согласуют репозиторий, сборки, проверки API и порядок включения; ночные дежурства в услугу не входят.

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

1. Согласуйте поддерживаемые сборки. Пока старый клиент входит в этот список, новый сервер должен сохранять его рабочий путь. Публикация в магазине не заменяет эту проверку.

2. Принимайте релиз по отчёту о конкретных сборках и сценариях. Отдельно проверьте включение функции, остановку и доступное клиентам поведение после неё.

3. Наблюдайте результат по сборкам. Возвращайте каждую найденную несовместимость в проверки. Удаляйте прежний API по согласованному концу поддержки.