В последние недели погрузился в абсолютно новую для себя штуку - мобильную разработку. Точнее, DevOps-часть для нее.

Всё новое, изначально ничего непонятно, даже то, с какой стороны подступаться к этому. Хорошо, что мы живем в 2026 году, где существуют ChatGPT и Claude. Но ответственность не позволяет навайбкодить все конфиги и решения. Вместо этого я сижу и делаю кросс-проверки, разбираюсь что и зачем нужно, какие инструменты есть, и почему именно они.

Больше, конечно, ковырялся именно с iOS частью, потому что проверять сборку проще локально - андроид телефона у меня нет. Разобрался в целом с воркфлоу разработки: Xcode, Apple Developer аккаунт, bundle-id, загрузка в App Store Connect, публикация в TestFlight для внутренних тестировщиков.

Понял, что если мы хотим тестировать приложение на dev-окружении, то по сути надо делать два приложения dev и prod. Потому что внутрь приложения зашивается конфигурация, в которой API-эндпоинты указаны. Получается, что можно собрать dev-приложение, загрузить его в App Store Connect и отправить в TestFlight для проверок. В ревью оно никогда не пойдет. А вот prod-приложение уже пойдет по пути TestFlight → Review → Store.

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

Ага, не забыть еще скриптик для инкремента версий приложений - сторы требуют обновления версии при каждой новой загрузке приложений. А еще требуют иконку для приложения. Чтобы на iOS картинку не зашакалило (частично из-за Liquid Glass), её надо сделать в Icon Composer-е с помощью SVG-элементов.

Разобрался как работают OTA-апдейты (over the air). Это когда можешь пересобрать только внутреннюю часть, запаковать ее в js-бандл и залить в s3. Приложение при запуске проверит наличие апдейта, скачает и предложит перезапуститься. Самая большая выгода - для мелких багфиксов тебе не нужно публиковать новую версию в сторы и ждать ревью. Тут надо быть осторожным, потому что добавлять функционал через OTA-апдейты без ревью запрещается правилами сторов.

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

В общем, погружение в новую область это всегда так - сначала чувствуешь себя идиотом, не знаешь основных терминов. Мозг к вечеру выжат настолько, что хочется просто сесть на диван и смотреть в стену. Главное помнить - глаза боятся, а руки делают. Потихоньку, мелкими итерациями, но в итоге картина становится яснее, начинаешь лучше во всем ориентироваться.