Я использовал сценарий оболочки как часть моего процесса сборки XCode, чтобы увеличить номер сборки в файле plist , однако это часто приводит к сбою XCode 4.2.1 (с ошибкой о том, что цель не принадлежит проекту; я предполагаю, смена в Plist файла путает Xcode в некотором роде).

Сценарий оболочки сделал это так, чтобы номер сборки увеличивался только тогда, agvtoolкогда файл новее, чем файл plist (так что просто сборка не увеличивала значение):

if [ -n \"`find ProjDir -newer ProjDir/Project-Info.plist`\" ]; then agvtool -noscm next-version -all; else echo \"Version not incremented\"; fi

Есть ли способ увеличить номер сборки (в файле plist или где-либо еще), который не нарушает Xcode?

ЗАКЛЮЧИТЕЛЬНОЕ РЕДАКТИРОВАНИЕ : сейчас я делаю такие вещи, используя скрипт на python, который я только что опубликовал на github . Это не очень хорошо задокументировано, но не должно быть трудным для разработки. В качестве бонуса этот репозиторий также содержит полезный скрипт для автоматического объединения сторонней библиотеки в комплект приложений.

Если я правильно понимаю ваш вопрос, вы хотите изменить Project-Info.plistфайл, который является частью стандартного шаблона проекта XCode?

Причина, по которой я спрашиваю это, заключается в том, что Project-Info.plistобычно она находится под контролем версий, и ее изменение означает, что она будет помечена как, ну, в общем, измененная.

Если вас это устраивает, то следующий фрагмент обновит номер сборки и пометит файл как измененный в процессе, где get_build_numberнаходится некоторый сценарий (т. Е. Заполнитель в этом примере), чтобы получить (возможно увеличенный) номер сборки, который вы хочу использовать:

#!/bin/sh

# get_build_number is a placeholder for your script to get the latest build number
build_number = `get_build_number`

/usr/libexec/PlistBuddy -c "Set :CFBundleVersion ${build_number}" ProjDir/Project-Info.plist

PlistBuddy позволяет вам установить любой ключ в файле plist, а не только номер версии. Вы можете создать все необходимые файлы plist и при необходимости включить их в ресурсы. Затем их можно прочитать из комплекта.

Что касается необходимости показывать версию на панели about и в других местах, вы также можете посмотреть настройки CFBundleGetInfoStringи CFBundleShortVersionString.

Я возился с множеством ответов на этот вопрос, и ни один из них меня не удовлетворил. Однако я наконец-то придумала смесь, которая мне действительно нравится!

Есть два шага, один в начале и один в конце фаз сборки.

В начале:

# Set the build number to the count of Git commits
if [ "${CONFIGURATION}" = "Release" ]; then
    buildNumber=$(git rev-list HEAD | wc -l | tr -d ' ')
    /usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildNumber" "${PROJECT_DIR}/${INFOPLIST_FILE}"
fi

В конце:

# Set the build number to "DEVELOPMENT"
if [ "${CONFIGURATION}" = "Release" ]; then
    /usr/libexec/PlistBuddy -c "Set :CFBundleVersion DEVELOPMENT" "${PROJECT_DIR}/${INFOPLIST_FILE}"
fi

Взглянув на Info.plist в XCode, вы увидите, что номер версии - «РАЗРАБОТКА», но встроенное приложение будет иметь постоянно увеличивающийся номер сборки. (Пока вы всегда делаете свои сборки из одной и той же ветки.)

Установка номера версии обратно в константную строку в конце предотвращает изменение файла Info.plist при сборке приложения.

Почему мне нравится этот метод:

• Легко
• Не загрязняет историю версий Git
• CFBundleVersion полностью автоматический
• Красивый номер версии может быть изменен всякий раз, когда я хочу

Я использовал этот список. Работает как положено. https://gist.github.com/sekati/3172554 (все права принадлежат первоначальному автору)

Скрипты, которые я модифицировал со временем.

xcode-versionString-generator.sh ,

xcode-build-number-generator.sh

Поскольку эти идеи помогают сообществу разработчиков, я создал проект GitHub. Итак, давайте развивать это хорошо. Вот проект GitHub: https://github.com/alokc83/Xcode-build-and-version-generator

Я обновил код для обоих скриптов, немного улучшив. вместо того, чтобы использовать ниже, возьмите последнюю версию от GitHub

Для версии:

# xcode-version-bump.sh
# @desc Auto-increment the version number (only) when a project is archived for export. 
# @usage
# 1. Select: your Target in Xcode
# 2. Select: Build Phases Tab
# 3. Select: Add Build Phase -> Add Run Script
# 4. Paste code below in to new "Run Script" section
# 5. Check the checkbox "Run script only when installing"
# 6. Drag the "Run Script" below "Link Binaries With Libraries"
# 7. Insure your starting version number is in SemVer format (e.g. 1.0.0)

# This splits a two-decimal version string, such as "0.45.123", allowing us to increment the third position.
VERSIONNUM=$(/usr/libexec/PlistBuddy -c "Print CFBundleShortVersionString" "${PROJECT_DIR}/${INFOPLIST_FILE}")
NEWSUBVERSION=`echo $VERSIONNUM | awk -F "." '{print $3}'`
NEWSUBVERSION=$(($NEWSUBVERSION + 1))
NEWVERSIONSTRING=`echo $VERSIONNUM | awk -F "." '{print $1 "." $2 ".'$NEWSUBVERSION'" }'`
/usr/libexec/PlistBuddy -c "Set :CFBundleShortVersionString $NEWVERSIONSTRING" "${PROJECT_DIR}/${INFOPLIST_FILE}"

Для сборки:

# xcode-build-bump.sh
# @desc Auto-increment the build number every time the project is run. 
# @usage
# 1. Select: your Target in Xcode
# 2. Select: Build Phases Tab
# 3. Select: Add Build Phase -> Add Run Script
# 4. Paste code below into new "Run Script" section
# 5. Drag the "Run Script" below "Link Binaries With Libraries"
# 6. Ensure that your starting build number is set to a whole integer and not a float (e.g. 1, not 1.0)

buildNumber=$(/usr/libexec/PlistBuddy -c "Print CFBundleVersion" "${PROJECT_DIR}/${INFOPLIST_FILE}")
buildNumber=$(($buildNumber + 1))
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildNumber" "${PROJECT_DIR}/${INFOPLIST_FILE}"

Вся эта запись была чрезвычайно полезной. Я использовал этот трюк, но настроил свой скрипт как ловушку пост-фиксации в GIT, поэтому CFBundleVersion увеличивается после каждого успешного коммита. Скрипт хука идет в .git / hooks. Журнал остается в каталоге проекта.

Это соответствует моему самому основному критерию. Я хочу иметь возможность получить версию из GIT и перестроить ту сборку, которая была у меня ранее. Любые приращения, сделанные во время процесса сборки, этого не делают.

Вот мой сценарий:

#!/bin/sh
#
# post-commit
#
# This script increments the CFBundleVersion for each successful commit
#

plist="./XYZZY/XYZZY-Info.plist"
buildnum=$(/usr/libexec/Plistbuddy -c "Print CFBundleVersion" "$plist")
if [ -z "$buildnum" ]; then
    exit 1
fi
buildnumplus=$(expr $buildnum + 1)
/usr/libexec/Plistbuddy -c "Set CFBundleVersion $buildnumplus" "$plist"

echo $(date) "- Incremented CFBundleVersion to" $buildnumplus >> hookLog.txt

Я не знаю, какой путь самый лучший, но я опубликую ответ Apple на тот случай, если кто-то его ищет ...

Согласно этому сообщению от Apple :

Автоматизация номеров версий и сборок с помощью agvtool

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

Номер сборки идентифицирует неизданную или выпущенную версию вашего приложения. Он хранится в Info.plist вашего приложения как CFBundleVersion(Bundle версия).

Вы должны выполнить следующие шаги в вашем проекте XCode:

1. Включить agvtool

Перейдите на панель «Настройки сборки» своей цели, затем обновите ее для всех ваших конфигураций сборки следующим образом:

• Установите текущую версию проекта на значение по вашему выбору.

Ваш файл данных проекта XCode, project.pbxproj, содержит CURRENT_PROJECT_VERSIONпараметр сборки (Текущая версия проекта), который указывает текущую версию вашего проекта. agvtool ищет файл project.pbxproj CURRENT_PROJECT_VERSION. Он продолжает работать, если CURRENT_PROJECT_VERSIONсуществует, и останавливается, в противном случае. Его значение используется для обновления номера сборки.

• Установите систему управления версиями на Apple Generic.

По умолчанию Xcode не использует какую-либо систему управления версиями. Установка системы управления версиями на Apple Generic гарантирует, что Xcode будет включать всю информацию о версиях, созданную agvtool, в ваш проект.

2. Настройте свою версию и номера сборки

agvtool ищет в Info.plist вашего приложения ваши версии и номера сборки. Он обновляет их, если они существуют, и ничего не делает, в противном случае. Убедитесь, что в вашем Info.plist есть ключи CFBundleVersion(Bundle version) и (Bundle version CFBundleShortVersionStringstring, short), как показано на рисунке ниже:

Выйдите из Xcode, затем перейдите в каталог, содержащий ваш файл проекта .xcodeproj в приложении Terminal, прежде чем выполнять любую из следующих команд. Файл проекта .xcodeproj содержит project.pbxproj, который используется agvtool. (Это часть, которую вы можете запустить в сценарии вместо командной строки.)

Обновление номера версии

Чтобы обновить номер версии до определенной версии, запустите

xcrun agvtool new-marketing-version <your_specific_version>

Пример: обновить номер версии до 2.0

xcrun agvtool new-marketing-version 2.0

Обновление номера сборки

Чтобы автоматически увеличить номер сборки, запустите

xcrun agvtool next-version -all

Чтобы установить номер сборки вашего приложения для конкретной версии, запустите

xcrun agvtool new-version -all <your_specific_version>

Пример: установить номер сборки на 2.6.9

xcrun agvtool new-version -all 2.6.9

Бонус:

Чтобы просмотреть номер текущей версии, запустите

xcrun agvtool what-marketing-version

Чтобы просмотреть текущий номер сборки, запустите

xcrun agvtool what-version

FWIW - это то, что я сейчас использую, чтобы увеличить номер сборки только для релизных сборок (включая архивирование). Работает нормально под Xcode 5.1.

Просто скопируйте / вставьте фрагмент в фазу сборки сценария запуска непосредственно в Xcode:

buildnum=$(/usr/libexec/PlistBuddy -c "Print :CFBundleVersion" "$PRODUCT_SETTINGS_PATH")

if [ "$CONFIGURATION" = "Release" ]; then
buildnum=$((buildnum + 1))
echo "Build number updated to $buildnum"
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildnum" "$PRODUCT_SETTINGS_PATH"
fi;

Спасибо за сценарий. Работает отлично.

Мой Info.plist находится в подкаталоге с именем, содержащим пробелы, поэтому мне пришлось изменить Run Script с кавычками вокруг пути plist:

${PROJECT_DIR}/tools/bump_build_number.sh "${PROJECT_DIR}/${INFOPLIST_FILE}"

и сценарий оболочки таким же образом с кавычками вокруг всех путей:

#!/bin/sh

if [ $# -ne 1 ]; then
    echo usage: $0 plist-file
    exit 1
fi

plist=$1
dir=$(dirname "$plist")

# Only increment the build number if source files have changed
if [ -n "$(find "$dir" \! -path "*xcuserdata*" \! -path "*.git" -newer "$plist")" ]; then
    buildnum=$(/usr/libexec/PlistBuddy -c "Print CFBundleVersion" "$plist")
    if [ -z "$buildnum" ]; then
        echo "No build number in $plist"
        exit 2
    fi
    buildnum=$(expr $buildnum + 1)
    /usr/libexec/Plistbuddy -c "Set CFBundleVersion $buildnum" "$plist"
    echo "Incremented build number to $buildnum"
else
    echo "Not incrementing build number as source files have not changed"
fi

Сценарий, который я сейчас использую, очень похож на сценарий Аликс , описанный выше. Моя адаптация, ниже, добавляет проверку, чтобы делать автоинкремент только при сборке релиза / архива.

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

# xcode-build-bump.sh
# @desc Auto-increment Xcode target build number every time the project is archived
# @src stackoverflow.com/a/15483906
# @usage
# 1. Select: your Target in Xcode
# 2. Select: Build Phases Tab
# 3. Select: Add Build Phase -> Add Run Script
# 4. Paste code below in to new "Run Script" section
# 5. Drag the "Run Script" below "Link Binaries With Libraries"
# 6. Insure that your starting build number is set to a whole integer and not a float (e.g. 1, not 1.0)

if [ "Release" != "${CONFIGURATION}" ]
then
    exit 0
fi

buildNumber=$(/usr/libexec/PlistBuddy -c "Print CFBundleVersion" "${PROJECT_DIR}/${INFOPLIST_FILE}")
buildNumber=$(($buildNumber + 1))
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildNumber" "${PROJECT_DIR}/${INFOPLIST_FILE}"

Он также доступен (в несколько более простом формате для копирования и вставки) в виде GitHub .

Я бы порекомендовал использовать автонаблюдение .

Xcode допускает файл заголовка (который может быть автоматически сгенерирован во время сборки, а не в самом vcs), чтобы обеспечить значения, которые будут раскрыты в info.plist во время сборки. Вы можете найти пошаговое руководство по настройке этого на веб-сайте автообзора .

Autorevision имеет тип вывода, ориентированный на заголовочные файлы этих типов, чтобы помочь именно в этих ситуациях.

Одна из проблем с некоторыми из этих решений заключается в том, что Launch Services распознает только четыре пять основных цифр в версии пакета . У меня есть проект с номером сборки, который исчисляется тысячами, поэтому я хотел использовать некоторые из менее значимых цифр.

Этот сценарий Perl увеличивает все Info.plists в проекте, а не только один для текущей цели, поэтому номера сборок остаются в непрерывном режиме. Он также использует одну цифру патча и две младшие цифры, поэтому сборка 1234 имеет версию 1.23.4. Я использую его как поведение перед сборкой, поэтому оно применимо ко всем проектам, которые я создаю.

Сценарий довольно грубый, но он работает для меня.

#!/usr/bin/perl

use strict;
use warnings;
use v5.12.0;

use Dir::Iterate;

for my $plist_file(grepdir { /-Info.plist$/ } '.') {
    my $build = `/usr/libexec/PlistBuddy -c "Print CFBundleVersion" '$plist_file'`;
    chomp $build;

    next unless $build;

    # Strip dots
    $build =~ s/\.//g;
    $build =~ s/^0//g;

    # Increment
    $build++;

    # Re-insert dots
    $build =~ s/^(\d{0,4}?) (\d{0,2}?) (\d{0,1}?)$/$1.$2.$3/x;

    # Insert zeroes
    $build =~ s{(^|\.)\.}{${1}0.}g;

    system qq(/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $build" '$plist_file');
}

Вы можете использовать универсальные версии Apple . По сути, все, что вам нужно сделать, это позвонить agvtool next-version -allиз каталога, в котором находится ваш файл .xcproj. Для более подробной информации проверьте URL выше.

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

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

# Set the build number to the decimal conversion of the short version of the current git SHA

# Get the short version of the current git SHA in hexadecimal
SHA=$(git rev-parse --short @)
# Uppercase any alphabetic chars in SHA (bc doesn't like lowercase hex numbers)
UPPERCASE_SHA=$(tr '[:lower:]' '[:upper:]' <<< "$SHA")
# Use bc to convert the uppercase SHA from hex to decimal
BUILD_NUM=$(bc <<< "ibase=16;obase=A;$UPPERCASE_SHA")
# Set our build number to that
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $BUILD_NUM" "${PROJECT_DIR}/${INFOPLIST_FILE}"

# To convert a build number back to a usable git SHA, run the following, substituting the build number for <build number>
# bc <<< "ibase=10;obase=16;<build number>"

Это преобразует короткую версию текущего git SHA в десятичную. Шестнадцатеричные символы не очень хорошо соответствуют требованиям к номеру сборки Apple, поэтому я должен был это сделать. Чтобы преобразовать его обратно, вы просто запустите что-то вроде этого:

SHA=$(bc <<< "ibase=10;obase=16;<build number>")

в bash <build number>- номер сборки, которую вы получили из двоичного файла. Тогда просто беги git checkout $SHA, и вот так.

Поскольку это адаптация решения Уилла Гизелера , как упоминалось выше, вам также понадобится следующий сценарий после сборки:

# Set the build number to "DEVELOPMENT"
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion DEVELOPMENT" "${PROJECT_DIR}/${INFOPLIST_FILE}"

который держит вашу историю Git в чистоте.

Я попытался изменить процедуру, и она не сработала, потому что:

1. Xcode 4.2.1 изменяет подкаталог xcuserdata в .xcodeproj

2. git отмечает предыдущее изменение в Project-Info.plist

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

if [ -n "$(find $dir \! -path "*xcuserdata*" \! -path "*.git" -newer $plist)" ]; then

Возможно, вы захотите сделать это только тогда, когда вы архивируете (и загружаете в TF, например). В противном случае номер вашей версии может очень быстро возрасти.

В схему (Product / Edit Scheme / Archive / Pre-Actions) вы можете добавить скрипт, который будет выполняться только при архивировании.

Кроме того, вы можете сбросить номер сборки при каждом увеличении версии приложения.

И последнее, если вы используете архив вместо этого, вы можете безопасно отключить:

# if [ -n "$(find "$dir" \! -path "*xcuserdata*" \! -path "*.git" -newer "$plist")" ]; then
...
# else
    # echo "Not incrementing build number as source files have not changed"
# fi

Поскольку номер сборки будет увеличиваться только при архивировании ...

РЕДАКТИРОВАТЬ: Исправьте то, что я сказал, предварительные действия в архиве происходят после сборки (но до архивирования), поэтому номер сборки будет увеличиваться для следующего архива ... Но вы можете создать новую схему и добавить это действие в сборку (предварительно действия) раздел этой новой схемы. и использовать эту схему, когда вы хотите создать новую сборку

Я использую последнюю версию SVN для номера сборки. Если вы измените Info.plist в каталоге сборки, это не повлияет на исходный Info.plist:

# use the last SVN revision as the build number:
Info_plist="$BUILT_PRODUCTS_DIR/$CONTENTS_FOLDER_PATH/Info.plist"
defaults write "${Info_plist}" CFBundleVersion `svn stat -u | awk '/'"Status against revision:"'/ {print $4}'`

Я чувствую, что нашел свое племя. Племя, надеюсь, тебя позабавила версия X.

Десять лет назад, работая над рабочим пространством, в котором было более 25 проектов Xcode, я воспользовался возможностью автоматизировать версию и создать обновления строк до такой степени, которая может показаться абсурдной, если вы поддерживаете только один или два проекта со случайными обновлениями.

VersionX:

• знает о типе сборки (Release / Debug)
• собирает информацию во время сборки из репозитория (включая поддержку git, но может быть настроен для hg, svn или любого другого используемого вами)
• предоставил легко настраиваемые строки причудливой маркетинговой версии (у которых было гораздо больше вариаций, прежде чем App Store наложил соглашение), чтобы вы могли автоматически увеличивать строки, которые включали символы для «беты», например, с помощью соглашения git-тегов.
• включает в себя класс, заполненный переменными экземпляра, содержащими информацию о версии и фиксации. Это полезно для заполнения панели about about и создания строк регистрации, отчетов о сбоях или сообщений об ошибках электронной почты пользователя с предварительно заполненной информацией.

Это было весело сделать. Я узнал много о системе сборки Xcode.

Вот пример типа причудливой версии и строк сборки, которые может автоматически генерировать VersionX.

Версия X 1.0.1 β7 (c5959a3 «Чистый»)

Маркетинговая версия: VersionX 1.0.1 β7 «1.0.1 является производным от тега для фиксации, в то время как« Beta 7 »автоматически генерируется счетчиком коммитов или счетчиком сборок (например).

Версия сборки: (c5959a3 «Очистить») Отображает хэш короткой фиксации и информирует вас о том, что в каталоге сборки не было ни одного незафиксированного изменения.

VersionX (источник на GitHub) - система в стиле барокко для автоматического увеличения версии и построения строк в проектах Xcode.

Документация VersionX.

Возможно, вы захотите проверить новый инструмент, который я разрабатывал, под названием Xcodebump. Он может обрабатывать обновление как CFBundleShortVersionString, так и CFBundleVersion. В качестве последнего шага он также будет регистрировать git и отмечать коммит, чтобы он соответствовал этим значениям CFBundle.

Проект Xcodebump находится здесь:

https://github.com/markeissler/Xcodebump

Я обновляю build numberследующим способом.

$INFO_FILEпуть к файлу plist И $build_numberэто новый номер сборки для этого здания.

/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $build_number" "${INFO_FILE}"

В общем, мой $build_numberсостоит majorи minorчасти. Это minorиз информации о проекте. Поэтому я опишу, как создать majorчасть.

## Composed by `major` and `minor`. 
## `minor` is parsed from project information. It's another story.
## Examples: `21.1`, or `21.1.3`
build_number="${major_number}.${minor_number}"

У меня есть 2 стратегии, чтобы решить $build_number .

Первая стратегия

Эта стратегия использует git tagсчет, чтобы решить majorо build number. Если есть 53теги проекта, он вернется 53по следующему сценарию оболочки.

Как правило, это увеличивается. И это заставит разработчика поставить тег git перед публикацией.

major_number=$(git tag -l | wc -l | grep -oE "\d+")

Вторая стратегия

Пусть система Jenkins CI решит majorроль. У него есть переменная окружения BUILD_NUMBER. Он увеличивается автоматически при построении системы CI. Эта информация полезна для отслеживания истории проекта в системе CI.

major_number=${BUILD_NUMBER}

Вот обновленная версия. Это работает с Xcode 9.3.1, iOS 11.

Нажмите «Построить этапы» в целевом приложении, нажмите значок +, чтобы добавить новый сценарий выполнения, и в поле вставьте этот код.

buildNumber=$(/usr/libexec/PlistBuddy -c "Print CFBundleVersion" "${PROJECT_DIR}/${INFOPLIST_FILE}")
buildNumber=$(($buildNumber + 1))
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildNumber" "${PROJECT_DIR}/${INFOPLIST_FILE}"

Перейдите в файл Info.plist и установите для «Bundle version» значение 1, а для «Bundle version string, short» значение 1, вы должны быть установлены.

Создайте проект с использованием Info.plist, и вы увидите изменение версии Bundle (номера сборки).

• Обратите внимание, что начиная с Xcode 9.3.1 вы не сможете увидеть эти изменения на вкладке «Общие», но увидите изменения при архивировании сборки и в Info.plist

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

Создайте файл с именем, Rakefileкоторый содержит это:

require "xcodeproj"
require "versionomy"

XCODEPROJECT = "MyProject.xcodeproj"
INFOPLISTFILE = "MyProject/MyProject-Info.plist"

$UPDATES = [:major,:minor,:tiny]
$UPDATES.each { |part|
  desc "increment #{part} part of version"
  task "increment:#{part}" do |task|
    version=`/usr/libexec/Plistbuddy -c "Print CFBundleVersion" #{INFOPLISTFILE}`.chomp
    version=Versionomy.parse(version)
    version=version.bump(part)

    # I use the same string for CFBundleVersion and CFBundleShortVersionString for now
    `/usr/libexec/PlistBuddy -c "Set :CFBundleVersion #{version}" #{INFOPLISTFILE}`
    `/usr/libexec/PlistBuddy -c "Set :CFBundleShortVersionString #{version}" #{INFOPLISTFILE}`
    print "version upgraded to #{version}\n"
  end
}

Подготовить: gem install xcodeproj versionomy

Запустите: rake increment:majorили rake increment:minorили rake increment:tinyкогда захотите.

Я считаю наиболее удобным использовать Automating Version и номера сборки с помощью agvtool .

Попробуй это:

1. Настройте его, как описано в документации Apple, ссылка на которую приведена выше.
2. Добавить сценарий в качестве предварительного действия для проекта -> Изменить схему ... -> Архив (или другой, если вы предпочитаете)
3. Set: предоставить настройки сборки из <your_app_target>

Скрипт (первая строка необязательна):

exec > ${PROJECT_DIR}/prebuild.log 2>&1
cd ${PROJECT_DIR}
xcrun agvtool next-version -all
cd -

Давайте сделаем это по-своему Apple. Это увеличит номер сборки после каждой успешной сборки

Я проведу вас через 5 изображений, просто пройдите.

1. Выберите «Редактировать схему ...» из выпадающего списка, когда вы выбираете имя своего проекта, расположенное справа от кнопки Stop_build_. Проверьте первый шаг

2. В левостороннем меню разверните опцию «Построить» и выберите «Пост-действия». Проверьте второй шаг.

3. Здесь вы можете добавить желаемые коды (скрипты), которые вы хотите выполнить после успешной сборки вашей программы. Это место, где мы должны добавить немного кода, чтобы наша автоматизация работала идеально. >> 1. Нажмите кнопку «Добавить (+)» в левом углу, чтобы добавить новый файл скрипта. >> 2. Теперь из выпадающего меню выберите «Создать действие сценария». Проверьте третий шаг.

4. Он имеет 3 поля >> 1. Оболочка уже назначена для вас >> 2. Теперь для «Предоставить настройки для сборки из» Выберите название проекта. >> 3. Существует большое поле для добавления вашего скрипта, просто скопируйте и вставьте туда этот код: проверьте четвертый шаг

   PLIST = "$ {PROJECT_DIR} / $ {INFOPLIST_FILE}" PLB = / usr / libexec / PlistBuddy LAST_NUMBER = $ ($ PLB -c "Печать CFBundleVersion" "$ PLIST") NEW_VERSION = $ (($ LAST_NUMBER + 1)) $ PLB -c "Набор: CFBundleVersion $ NEW_VERSION" "$ PLIST"

5. После завершения 4-го шага просто нажмите «Закрыть», чтобы закрыть окно, и мы должны сделать последний шаг, перейдите к файлу «plist.info» в меню «Файл проекта» и убедитесь, что ключ «Версия пакета» в разделе «Ключ» наиболее содержит пятый шаг проверки числового значения