Содержание
Как автоматически увеличить версию сборки (Build) Xcode?
Я не мало потратил времени, пытаясь найти в интернете корректное решение этого вопроса. Полноценного решения так и не нашел. Решения для увеличения номера версии приложения (Revision) не нашел вообще, а с номером сборки (Build) вариантов много, но практически все они однотипны и обладают одним важным дефектом - в случае ручного изменения номера сборки в проекте, автоматическая нумерация номера сборки замораживается и перестает увеличиваться. Пришлось изобретать самому. В итоге я приготовил решение этого вопроса.
Предлагаю два варианта скрипта. Light версия увеличивает только номер сборки (Build), а Full версия скрипта и то и другое, то есть и Build и Revision. Эти решения я проверил и для приложений Mac OS (MacOS) и для приложений iOS/iPadOS.
После установки этих скриптов все будет работать автоматически и также сохранится возможность вручную изменять номера версий как в проекте, так и в info.plist приложения.
Auto-Incrementing Build Light Version in Xcode 12+
- Edit Debug Scheme (Not Release)
- Click on Build > Post-actions.
- Click on the +button at the bottom and add a New Run Script Action.
- Select target
- Write script
#!/bin/sh
# ------------------------------------------------------------
# Auto-Incrementing Build Light Version in Xcode 12+
# Format Build (0+)
# Author: @iSavaDev (sageleo.com)
# ------------------------------------------------------------
PLIST="${PROJECT_DIR}/${INFOPLIST_FILE}"
PLB=/usr/libexec/PlistBuddy
BUILD_VERSION=$($PLB -c "Print CFBundleVersion" "${PLIST}")
if [ "$BUILD_VERSION" = "\$(CURRENT_PROJECT_VERSION)" ]; then
# Disable option Apple Generic
BUILD_VERSION="${CURRENT_PROJECT_VERSION}"
fi
if [[ -z "${BUILD_VERSION}" ]]; then
BUILD_VERSION="0"
fi
#NEW_BUILD_VERSION=$(($BUILD_VERSION + 1))
#inc=.01 or inc=1
inc=1
NEW_BUILD_VERSION=`echo $BUILD_VERSION + $inc|bc`
$PLB -c "Set :CFBundleVersion $NEW_BUILD_VERSION" "${PLIST}"
Важно: Убедитесь, что вы выбрали свою цель (Target) выше (по умолчанию она может быть не выбрана), что также нарушит ваш скрипт, и вы не поймете, почему. Необходимо повторить эти действия для каждой цели (но кроме Release, если вы используете полную версия скрипта).
Важно: Xcode не завершит вашу сборку (или увеличение не будет работать), если этот скрипт завершится неудачно, например плохо скопировали код скрипта или код скрипта был нарушен (Xcode проигнорирует статус выхода любых скриптов, которые мы прикрепляем к схеме). Кроме того, все ошибки и стандартные файлы будут полностью подавлены, поэтому отладка этих сценариев может быть практически невозможна.
Важно: Мы хотим увеличивать номер сборки после сборки, потому что мы не хотели бы увеличивать сборку, если она не была успешной - например, из-за ошибки компиляции.
Важно: Если вы делитесь этим проектом с другими (например через систему управления версиями) или запускаете его на любом внешнем компьютере (включая систему CI), вы должны установить флажок Shared, который сохраняет вашу схему вместе с проектом, иначе другие копии этого проекта не будут включать эти скрипты.
Auto-Incrementing Build Full Version in Xcode 12+
Это полная версия скрипта для увеличения как номера сборки (Build), так и версии приложения (Revision).
Номер сборки (Build) никогда не обнуляется. Номер патча (Patch version) увеличивается с каждой сборкой (рекомендую в debug Scheme). Когда он достигает значения 99, мы его сбрасываем на ноль и увеличиваем второстепенный номер (Minor version). Основной номер версии мы не трогаем, его изменение только вручную.
Например у нас было 1.2.99 (503), со следующей сборкой у нас станет 1.3.0 (504)
Я рекомендую этот скрипт установить только в схему с режимом Debug* и в пункт Post-actions, а в схеме Release не прописывать ничего. В схеме Debug снимите галочку Archive. Это для удобства, чтобы случайно не упаковать и не отправить на проверку приложение с неверным номером версии приложения.
*Для чего так нужно: чтобы при создании архива (Archive) у нас была указана правильная версия приложения. Чтобы этого достичь, всю разработку ведем в режиме отладки (Debug Scheme) Перед созданием архива, переключаемся на схему Release Scheme, делаем Build и только после этого приложение можно архивировать (Menu Archive).
Примечание: Необходимо предварительно создать несколько схем, минимум две, Debug и Release.
#!/bin/sh
# ------------------------------------------------------------
# Auto-Incrementing Build Full Version in Xcode 12+
# Format Semantic Versioning: 1.0.0 (0)
# Author: @iSavaDev (sageleo.com)
# ------------------------------------------------------------
PLIST="${PROJECT_DIR}/${INFOPLIST_FILE}"
PLB=/usr/libexec/PlistBuddy
#
# --- BUILD_VERSION
#
BUILD_VERSION=$($PLB -c "Print CFBundleVersion" "${PLIST}")
if [ "$BUILD_VERSION" = "\$(CURRENT_PROJECT_VERSION)" ]; then
# Disable option Apple Generic
BUILD_VERSION="${CURRENT_PROJECT_VERSION}"
fi
if [[ -z "${BUILD_VERSION}" ]]; then
BUILD_VERSION="0"
fi
#NEW_BUILD_VERSION=$(($BUILD_VERSION + 1))
#inc=.01 or inc=1
inc=1
NEW_BUILD_VERSION=`echo $BUILD_VERSION + $inc|bc`
$PLB -c "Set :CFBundleVersion ${NEW_BUILD_VERSION}" "${PLIST}"
#
# --- SHORT_VERSION
#
SHORT_VERSION=$($PLB -c "Print CFBundleShortVersionString" "${PLIST}")
if [ "$SHORT_VERSION" = "\$(MARKETING_VERSION)" ]; then
# Disable option Apple Generic
SHORT_VERSION="${MARKETING_VERSION}"
fi
if [[ -z "${SHORT_VERSION}" ]]; then
SHORT_VERSION="1.0.0"
fi
MAJOR_NUMBER=$(echo $SHORT_VERSION | cut -d. -f1)
if [[ -z "${MAJOR_NUMBER}" ]]; then
MAJOR_NUMBER="1"
fi
MINOR_NUMBER=$(echo $SHORT_VERSION | cut -d. -f2)
if [[ -z "${MINOR_NUMBER}" ]]; then
MINOR_NUMBER="0"
fi
PATH_NUMBER=$(echo $SHORT_VERSION | cut -d. -f3)
if [[ -z "${PATH_NUMBER}" ]]; then
PATH_NUMBER="0"
fi
if [ "${PATH_NUMBER}" -ge 99 ]; then
MINOR_NUMBER=$(($MINOR_NUMBER + 1))
PATH_NUMBER="0"
else
PATH_NUMBER=$(($PATH_NUMBER + 1))
fi
NEW_VERSION="${MAJOR_NUMBER}.${MINOR_NUMBER}.${PATH_NUMBER}"
$PLB -c "Set :CFBundleShortVersionString ${NEW_VERSION}" "${PLIST}"
Ключевые моменты
Если в файле info.plist отсутствуют ключи CFBundleShortVersionString и CFBundleVersion, то их необходимо добавить и заполнить их начальными данными. Ключи эти нужно создать именно в самом файле, а не на вкладке Info.
Если в файле info.plist уже присутствуют ключи CFBundleShortVersionString и CFBundleVersion, но в их значении стоят переменные со знаком доллара, то нужно стереть эти переменные и заполнить начальными данными.
Пример (было):
Bundle version string (short) = $(MARKETING_VERSION)
Bundle version = $(CURRENT_PROJECT_VERSION)
Пример (нужно):
Bundle version string (short) = 1.0.0
Bundle version = 0
Как отобразить версию версии приложения (iOS, iPadOS) в пакете настроек моего приложения?
- Необходимо добавить в проект набор файлов Settings.bundle
- Описать в файле Root.plist все необходимые элементы интерфейса окна настроек
- Скриптом автоматически при сборке приложения вносить изменения в файл Root.plist.
В настройках приложения у нас только один элемент Title (PSTitleValueSpecifier). Вносить изменения мы будем в словарь PreferenceSpecifiers, внутри которого массив и наш элемент под номером 0, содержащий ключ DefaultValue, в которое непосредственно и будем делать запись нового значения.
Пример файла с Title
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>PreferenceSpecifiers</key>
<array>
<dict>
<key>DefaultValue</key>
<string>1.0.35 (39)</string>
<key>Key</key>
<string>kVersionApp_preference</string>
<key>Title</key>
<string>VersionApp</string>
<key>Type</key>
<string>PSTitleValueSpecifier</string>
</dict>
</array>
<key>StringsTable</key>
<string>Root</string>
</dict>
</plist>
Скрипт Auto Incrementing Settings Build
Непосредственно наш скрипт (этот код можно использовать отдельно по инструкции в начале статьи, а можно вставить в конец скрипта Auto-Incrementing).
# Type a script or drag a script file from your workspace to insert its path.
# ------------------------------------------------------------
# Auto Incrementing Settings Build in Xcode 12+
# Format Semantic Versioning: 1.0.0 (0)
# Author: @iSavaDev (sageleo.com)
# ------------------------------------------------------------
PLB=/usr/libexec/PlistBuddy
# Local file Root.plist: Write build version app
R1LIST="${PROJECT_DIR}/${PROJECT_NAME}/Settings.bundle/Root.plist"
$PLB -c "Set :PreferenceSpecifiers:0:DefaultValue ${NEW_VERSION} (${NEW_BUILD_VERSION})" "${R1LIST}"
# Target file Root.plist: Write build version app
R2LIST="${TARGET_BUILD_DIR}/${CONTENTS_FOLDER_PATH}/Settings.bundle/Root.plist"
$PLB -c "Set :PreferenceSpecifiers:0:DefaultValue ${NEW_VERSION} (${NEW_BUILD_VERSION})" "${R2LIST}"
Схема версий Xcode
Revision: CFBundleShortVersionString
Не обязательно, но хорошо бы, чтобы это была семантическая версия (1.0.0). Также известна как сокращенная версия.
Build: CFBundleVersion
это частная версия. То есть его можно использовать внутри компании для идентификации бета-версий или других предварительных версий. Опять же, здесь вы не ограничены (на самом деле это так, это дико расстраивает, но я вернусь к этому чуть позже †), и большинство людей используют постоянно увеличивающееся целое число, которое не сбрасывается с новыми выпусками - более широко известное как номер сборки.
Семантическая версия
{MajorVersion}.{MinorVersion}.{PatchVersion}
- Major version - Major changes, redesigns, and functionality changes
- Minor version - Minor improvements, additions to functionality
- Patch version - A patch number for bug-fixes
Когда вы видите такую версию, как 1.2.3, она состоит из трех отдельных частей. Это основная (Major), второстепенная (Minor) и патч- версии (Patch) соответственно. У каждого есть свои правила о том, когда и почему его следует увеличивать.
Увеличивайте количество патчей, когда вы исправляете ошибки, но не меняете какой-либо функционал.
Приложения, которые полагаются на ваше программное обеспечение, должны всегда иметь возможность обновлять выпуск исправлений без сбоев.
Увеличивайте второстепенное, когда вы добавляете неразрывные функции.
То есть вы предоставляете своему приложению больше функций, API и т. Д. Без изменения каких-либо существующих функций. Другие приложения, использующие ваше программное обеспечение, должны иметь возможность обновляться, но не обязательно автоматически. Может потребоваться внесение минимальных изменений.
Увеличивайте основное значение при критических изменениях.
Приложения, которые полагаются на ваше программное обеспечение, могут работать, но, как правило, вы ожидаете, что они не будут работать. Только в тех случаях, когда другие приложения используют функции, которые не были изменены в новом основном выпуске, может не потребоваться обновление.
Версия всегда должна содержать все три части, даже если они должны быть дополнены нулями. Например, 1.0.0 - это правильная семантическая версия, 1.0 - нет. Это правило не соблюдается большинством людей.
Частично текст взят и переведен из статьи:
Incrementing the Xcode Build Number
AVGTOOL
Другой вариант, более мощный. Предварительно нужно удалить везде скрипт из раздела выше, если вы его прописали. Или одно или другое.
Чтобы использовать это:
Настройте свой проект в Xcode в разделе «Build Settings» Versioning на использование «Apple Generic».
Далее там же, установите версию и номер сборки, или в терминале выполните:
agvtool new-version 1 (установите номер сборки на 1)
agvtool new-marketing-version 1.0 (установите Маркетинговую версию на 1.0)
См. Справочную страницу agvtool для получения тонны полезной информации