Популярное
Свежее
Моя лента
Сообщения
Рейтинг
Курсы
Темы
Маркетинг
Деньги
Сервисы
Личный опыт
Крипто
Маркетплейсы
AI
Образование
Карьера
Путешествия
Показать все
vc.ru
О проекте
Правила
Реклама
Приложения
Napoleon IT
Разработка

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

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

Приложение собирается менеджером проекта, без программиста
Приложение собирается менеджером проекта, без программиста

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

Общее

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

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

Иконка приложения

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

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

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

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

"images" : [ { "idiom" : "iphone", "size" : "20x20", "scale" : "2x", "unassigned": true }, { "idiom" : "iphone", "size" : "20x20", "scale" : "3x" } ] "info" : { "version" : 1, "author" : "xcode" }

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

APP_ICON_NAME="Назание иконки размером 1024х1024 px (без расширения файла)" APP_ICON_ASSETS_FOLDER="Путь до папки с иконкой проекта (обычно Assets.xcassets/Appicon.appiconset" CONFIG_FILE="Название файла конфигурации (обычно Contents.json)" # Пробегаем по каждому json-объекту в файле Contents.json echo $OLD_CONFIG_FILE_CONTENT | jq -c '.images[]' | while read config; do # Проверяем, используется ли изображение, описанное данным объектом unassigned=$(echo $config | jq '.unassigned') [ $unassigned = true ] && continue # Получаем ширину, высоту и масштаб изображения (*) widthpt=$(echo $config | jq '.size' | grep -oE '[0-9]+(\.[0-9]+)?' | head -n 1) heightpt=$(echo $config | jq '.size' | grep -oE 'x[0-9]+(\.[0-9]+)?' | head -n 1 | tail -c +2) scale=$(echo $config | jq '.scale' | grep -oE '[0-9]' | head -n 1) # Составляем название изображения name="$APP_ICON_NAME-$widthpt"x"$heightpt@$scale"x".png" # Копируем само изображение в папку cp $APP_ICON_NAME $APP_ICON_ASSETS_FOLDER/$name # Конвертируем высоту и ширину изображения из pt в px (*) # и обновляем изображение с учетом полученного разрешения widthpx=$(echo $widthpt*$scale | bc) heightpx=$(echo $heightpt*$scale | bc) sips -z $widthpx $heightpx $APP_ICON_ASSETS_FOLDER/$name > /dev/null # Добавляем файл Contents.json config=$(echo $config | jq ". + {\"filename\": \"$name\"}") config="[$config]" final=$(cat $TEMP_CONFIG_FILE | jq ".images |= . + $config") echo $final | jq '.' > $TEMP_CONFIG_FILE done # Заменяем содержание файла Contents.json нашей конфигурацией cat $TEMP_CONFIG_FILE | jq '.' > $APP_ICON_ASSETS_FOLDER/$CONFIG_FILE

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

Code Signing и сборка приложения

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

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

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

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

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

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

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

lane :uploadapp do |options| cert sigh( app_identifier: options[:bundle] ) # Этот шаг необходим, если у вас при ручной сборке включена опция Automatic signing disable_automatic_code_signing(path: "Название .xcodeproj файла") update_project_provisioning( xcodeproj: "Название .xcodeproj файла", # Здесь необязательно указывать полное имя профайла, достаточно указать Developer или Distribution code_signing_identity: "iPhone Distribution" ) build_app( workspace: "Название .xcworkspace файла", scheme: "Scheme проекта, которую необходимо собирать (указана слева от выбора устройства, на которое собирается приложение)", # Нужно ли выполнить clean project перед сборкой проекта clean: true ) upload_to_testflight( skip_waiting_for_build_processing: true, app_identifier: options[:bundle] ) end

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

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

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

fastlane uploadapp

Версионирование

Еще одной важной настройкой при выкладке приложения в 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 завершится с ошибкой. Обработаем эту ошибку и присвоим билду значение по умолчани
core_version = get_version_number(xcodeproj: "Platform.xcodeproj") old_app_build_number = 0 begin old_app_build_number = app_store_build_number( live: false, app_identifier: options[:bundle] ) rescue old_app_build_number = 1 end

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

client_version_with_old_build = core_version.to_s + "." + old_app_build_number.to_s new_build_number = app_store_build_number( live: false, version: client_version_with_old_build, app_identifier: options[:bundle], initial_build_number: 0 ) + 1

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

new_client_version = core_version.to_s + "." + new_build_number.to_s increment_version_number( version_number: new_client_version, xcodeproj: "Platform.xcodeproj" ) increment_build_number( build_number: new_build_number )

Заключение

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

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

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

88
3 комментария
Napoleon IT
Автор

Fastlane работает следующим образом:
Сначала он пробегается по каждому сертификату из developer.apple и смотрит, установлен ли данный сертификат на машине, на которой осуществляется сборка
Если он не находит ни одного такого совпадения, он пытается сгенерировать новый
Если уже достигнуто максимальное количество сгенерированных сертификатов (для релизных сертификатов - 3), то он выдает ошибку, сборка приложения останавливается. Такую проблему уже приходится решать вручную

1
Ответить
Виктор Мазуренко

Спасибо за разъяснения. Эпоха уходит, теперь разработчик уже не сможет отмазаться что "оно билдится". А сам сервис по итогу будет внутренним, скажем для менеджера, или же будет отдан самому клиенту?

Ответить