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

Мы просто устанавливаем номер версии для собранного продукта равным количеству коммитов Git. Это не повлияет на систему управления версиями, поскольку сценарий изменяет только созданный продукт.

Добавьте эту фазу сборки Run Script в конец ваших фаз сборки:

if [ "${CONFIGURATION}" = "Release" ]; then
    buildNumber=$(git rev-list --count head)
    /usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildNumber" "${TARGET_BUILD_DIR}/${INFOPLIST_PATH}"
fi

Установите версию Info.plist в своем проекте так, как хотите, она никогда не будет использована при создании сборки выпуска. Я установил для себя AUTOMATED или DEVELOPMENT, чтобы было ясно, когда я запускаю сборку для разработки.

Вот и все! Созданное приложение будет иметь постоянно увеличивающийся номер сборки. (Если вы всегда строите свои сборки из одной и той же ветки.)

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

• Легкий
• Не загрязняет историю версий 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

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

• Установите для Current Project Version любое значение по вашему выбору.

Ваш файл данных проекта 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 вашего приложения номера версии и сборки. Он обновляет их, если они существуют, и ничего не делает в противном случае. Убедитесь, что ключи CFBundleVersion (версия пакета) и CFBundleShortVersionString (строка версий пакета, короткая) существуют в вашем Info.plist, как показано на изображении ниже:

Закройте Xcode, затем перейдите в каталог, содержащий файл вашего проекта .xcodeproj, в приложении «Терминал» перед выполнением любой из следующих команд. Файл проекта .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 находится в подкаталоге с именем, содержащим пробелы, поэтому мне пришлось изменить сценарий запуска, заключив в кавычки путь к списку:

${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

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

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

# 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 gist.

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

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

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

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

Этот сценарий Perl увеличивает все Info.plist в проекте, а не только один для текущей цели, поэтому все номера сборки остаются неизменными. Он также использует одну цифру патча и две второстепенные цифры, поэтому для сборки 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). В противном случае номер вашей версии может очень быстро подняться.

В схеме (Продукт / Редактировать схему / Архив / Предварительные действия) вы можете добавить скрипт, который будет выполняться только при архивировании.

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

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

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

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

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

В качестве номера сборки я использую последнюю ревизию 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}'`

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

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

Версия X:

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

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

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

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

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

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

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+")

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

Пусть система CI Jenkins решит 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 и установите для параметра «Версия пакета» значение 1, а для параметра «Строка версий пакета, краткое» - значение 1, которое вы должны установить.

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

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

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

Создайте файл с именем 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, когда хочешь.

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

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

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

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

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

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» в меню «Файл проекта» и убедитесь, что ключ «Версия пакета» в разделе «Ключ» больше всего содержит числовое значение Отметьте пятый шаг