Автоматизация iOS-сборок в конструкторе приложений, или Как перестать делать сборки 24/7 и начать разрабатывать

Всем привет! Наша команда разрабатывает конструктор мобильных приложений, и для нас очень важна автоматизация процесса сборки приложений для наших клиентов. В этой статье хотим поделиться с вами некоторыми особенностями сборки приложений на основе платформы.

Все iOS-разработчики знают, что сборка приложения и загрузка его в AppStore Connect — далеко не самый быстрый процесс, он запросто может съесть у вас до получаса рабочего времени. А если речь идёт о платформе, то для каждого клиента нужно собирать и загружать в Connect своё приложение, причём не просто собрать, а ещё и кучу всего: поменять иконку, название, идентификатор и т.д. Именно о таких вещах и пойдёт речь.

Для начала вкратце опишем, как сейчас у нас построен процесс сборки приложения на нашем конструкторе.

• Менеджером в административной панели заполняется конфигурация для конкретного приложения и запускается процесс его сборки.
• Конфигурация, заполненная менеджером загружается в формате JSON, скачиваются необходимые ресурсы, применяются в проекте и происходит сама сборка приложения. Все это происходит на облачном Mac Mini с помощью Gitlab CI.
• Полученная сборка заливается в AppStore Connect для релиза либо отдается клиенту через сервис TestFlight.

Чтобы добавить иконку в iOS-приложение, вам необходимо иметь ее в разрешениях для всех устройств, которые поддерживает ваше приложение. в IDE Xcode это выглядит вот так (и это только для iPhone, не беря в расчет iPad, Apple Watch и т. д.):

Естественно, никто не будет загружать иконку приложения в каждом разрешении, поэтому менеджер в административной панели загружает единственную иконку размером 1024x1024 px. Далее необходимо получить из единственного файла изображения всех необходимых размеров.

Тут нам на помощь приходит файл Contents.json, который лежит в папке с иконкой. По сути экран, который мы видим в Xcode на скриншоте выше, управляется обычным JSON-файлом с такой структурой:

Поэтому все, что нам нужно сделать для достижения нашей цели – корректно распарсить данный JSON и создать иконки нужных размеров. Сделаем это с помощью вот такого простенького скрипта:

(*) При разработке для iOS по-умолчанию используется размер в поинтах (pt) – специальной размерности, которая не зависит от плотности пикселей на экране. Так, для обычного дисплея (@1x) и для retina-дисплея (@2x и @3x) размер изображения будет разный в пикселях, но одинаковый в поинтах. Подробнее об этом можно почитать, например, здесь.

В разработке под iOS есть один малоприятный аспект - каждое собираемое приложение должно быть подписано специальным сертификатом разработчика.

Если вкратце описать этот процесс, то он выглядит следующим образом:

• Необходимо создать файл запроса на создание сертификата у себя на компьютере
• На портале разработчика с помощью этого файла нужно сгенерировать и загрузить публичную часть сертификата (.cer). Комбинация из публичной части сертификата и приват
• На основе этого сертификата на портале разработчика также нужно сгенерировать специальный файл – Provisioning Profile, который будет уникальный для каждого приложения вашего аккаунта.
• С использованием комбинации сертификата и профайла приложения, можно собрать приложение и загрузить его в AppStore Connect.

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

У нас используется методы cert и sigh. С помощью этих методов автоматически генерируются нужные файлы для подписи приложения и сохраняются в соответствующих местах, чтобы они были доступны при сборке приложения. Не будем подробно описывать, как работает Fastlane под капотом, интересующиеся могут заглянуть в исходный код, они лежат на гитхабе.

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

Выглядит это тоже очень компактно:

С помощью настройки Fastlane, приведенной выше, проверяется, присутствуют ли необходимые файлы для подписи приложения (сертификат и профайл), в случае их отсутствия, они автоматически сгенерируются и подставятся в проект. После этого проект автоматически соберется и загрузится в AppStore Connect.

Все части этого процесса подробно описаны в документации Fastlane, там же приведен список параметров, которые вы можете добавить в каждую функцию в зависимости от специфики вашего проекта.

Вызывается эта процедура следующей командой, которая просто добавляется в ваш bash-скрипт:

Еще одной важной настройкой при выкладке приложения в AppStore является его версия. Версия iOS-приложения состоит из двух частей – сама версия (строка вида 1.2.1) и билд приложения (обычно это просто целое число).

Для проставления версий мы также используем Fastlane, с помощью него можно можно получить последний загруженный в AppStore билд (для конкретной версии или для последней загруженной), но, к сожалению, нельзя получить саму версию, поэтому версионирование у нас работает следующим образом:

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

Выглядит это следующим образом:

Пусть текущая версия платформы - 1.2. При выпуске нового приложения его версия будет 1.2.1 (build 1). Если потом мы захотим обновить приложение на той же версии платформы, то версия будет 1.2.2 (build 2). Если обновим версию платформы до 1.3, а потом решим обновить это приложение на новой версии платформы, то версия будет 1.3.1 (build 1).

В итоге мы получаем следующий механизм проставления версий для приложения.

• Получаем версию платформы из проекта и получаем номер билда последней загруженной в AppStore Connect версии. Если приложение загружается первый раз, то app_store_build_number завершится с ошибкой. Обработаем эту ошибку и присвоим билду значение по умолчани

2) Составляем версию приложения на основе полученного номера билда и проверяем, на актуальной ли версии платформы было собрано это приложение. Проверка довольно простая – мы пытаемся получить номер билда для этой версии и увеличиваем его на 1. Если для проверяемой версии не было загружено ни одной сборки приложения, то придет 0 из-за параметра initial_build_number, который так же увеличится на 1.

3) Составляем новую версию приложения и обновляем версию и билд проекта для его последующей сборки и загрузки.

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

Спасибо за внимание!

ESHOP - конструктор мобильных приложений для магазинов