Eu tenho usado um shell script como parte do meu processo de compilação do Xcode para aumentar o número da compilação no arquivo plist , no entanto, ele está causando o travamento do Xcode 4.2.1 com frequência (com um erro sobre o destino que não pertence a um projeto; a alteração do arquivo plist está confundindo o Xcode de alguma forma).

O script do shell fez isso para que o número da compilação seja incrementado apenas agvtoolquando um arquivo for mais novo que o arquivo plist (portanto, apenas a construção não incrementou o valor):

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

Existe uma maneira de incrementar o número da compilação (no arquivo plist ou em qualquer outro lugar) que não quebre o Xcode?

Edição final : Agora faço esse tipo de coisa usando um script python que acabei de tornar público no github . Não está bem documentado, mas não deve ser difícil de resolver. Como bônus, este repositório também contém um script útil para agrupar automaticamente a biblioteca de terceiros em um pacote de aplicativos.

Se entendi sua pergunta corretamente, você deseja modificar o Project-Info.plistarquivo, que faz parte do modelo de projeto padrão do Xcode?

A razão pela qual pergunto isso é que Project-Info.plistnormalmente está sob controle de versão e modificá-lo significa que ele será marcado como modificado.

Se estiver tudo bem com você, o trecho a seguir atualizará o número da compilação e marcará o arquivo como modificado no processo, onde get_build_numberestá algum script (por exemplo, um espaço reservado neste exemplo) para obter o número da compilação (possivelmente incrementado) que você quer usar:

#!/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

O PlistBuddy permite que você defina qualquer chave em um arquivo plist, não apenas o número da versão. Você pode criar todos os arquivos plist desejados e incluí-los nos recursos, se necessário. Eles podem ser lidos no pacote.

Quanto à sua necessidade de mostrar a versão no painel sobre e em outros lugares, você também pode verificar a configuração CFBundleGetInfoStringeCFBundleShortVersionString .

Eu brinquei com muitas respostas sobre esta questão, e nenhuma delas me satisfez. No entanto, finalmente criei uma mistura que realmente gosto!

Há duas etapas, uma no início e outra no final das fases de construção.

No inicio:

# 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

No fim:

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

Olhando para o Info.plist no Xcode, você verá que o número da versão é "DESENVOLVIMENTO", mas o aplicativo criado terá um número de build constantemente crescente. (Contanto que você sempre faça suas compilações no mesmo ramo.)

Definir o número da versão de volta para uma cadeia constante no final impede que o arquivo Info.plist seja alterado criando o aplicativo.

Por que eu gosto desse método:

• Fácil
• Não polui o histórico de versões do Git
• CFBundleVersion é totalmente automático
• O número da versão bonita pode ser modificado sempre que eu quiser

Eu usei essa glist. Funciona como esperado. https://gist.github.com/sekati/3172554 (todo o crédito é para o autor original)

Scripts que eu modifiquei com o tempo.

xcode-versionString-generator.sh ,

xcode-build-number-generator.sh

Como essas essência estão ajudando a comunidade de desenvolvedores, eu fiz o projeto do GitHub. Então, vamos desenvolvê-lo bem. Aqui está o projeto GitHub: https://github.com/alokc83/Xcode-build-and-version-generator

Eu atualizei o código para ambos os scripts um pouco de aprimoramento. em vez de usar abaixo, pegue as últimas do GitHub

Para a versão:

# 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}"

Para construção:

# 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}"

Toda essa entrada foi extremamente útil. Usei esse truque, mas configurei meu script como um gancho pós-confirmação no GIT, para que o CFBundleVersion seja incrementado após cada confirmação bem-sucedida. O script hook entra em .git / hooks. Um log é deixado no diretório do projeto.

Isso atende ao meu critério mais básico. Quero poder obter uma versão do GIT e reconstruir a compilação exata que eu tinha anteriormente. Qualquer incremento feito durante o processo de construção não faz isso.

Aqui está o meu script:

#!/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

Não sei qual o melhor caminho, mas publicarei a resposta da Apple para o caso de alguém a procurar ...

De acordo com este post de perguntas e respostas da Apple :

Automatizando números de versão e compilação usando agvtool

As chaves de versão e número de compilação, respectivamente, especificam as versões interna e de marketing do seu aplicativo. agvtool é uma ferramenta de linha de comando que permite incrementar automaticamente esses números para o próximo número mais alto ou para um número específico.

O número da compilação identifica uma versão não lançada ou lançada do seu aplicativo. Ele é armazenado no Info.plist do seu aplicativo comoCFBundleVersion (versão do pacote).

Você deve concluir as seguintes etapas no seu projeto do Xcode:

1. Ativar agvtool

Navegue até o painel Configurações de compilação do seu destino e atualize-o para todas as suas configurações de compilação, da seguinte maneira:

• Defina a versão atual do projeto com um valor de sua escolha.

O arquivo de dados do projeto Xcode, project.pbxproj, inclui uma CURRENT_PROJECT_VERSIONconfiguração de construção (Versão Atual do Projeto), que especifica a versão atual do seu projeto. O agvtool procura em project.pbxproj CURRENT_PROJECT_VERSION. Ele continua executando, se CURRENT_PROJECT_VERSIONexistir, e para de executar, caso contrário. Seu valor é usado para atualizar o número da compilação.

• Defina o Versioning System como Apple Generic.

Por padrão, o Xcode não usa nenhum sistema de controle de versão. A configuração do sistema de versão como Apple Generic garante que o Xcode inclua todas as informações de versão geradas pelo agvtool em seu projeto.

2. Configure sua versão e crie números

O agvtool pesquisa o Info.plist do seu aplicativo pela sua versão e compila números. Ele os atualiza se eles existirem e não fizer nada, caso contrário. Verifique se as teclas CFBundleVersion(versão do pacote) e CFBundleShortVersionString(sequência de versões do pacote, curta) existem no seu Info.plist, como mostra a imagem abaixo:

Saia do Xcode e navegue até o diretório que contém o arquivo de projeto .xcodeproj no aplicativo Terminal antes de executar qualquer um dos seguintes comandos. O arquivo de projeto .xcodeproj contém project.pbxproj, que é usado pelo agvtool. (Esta é a parte que você pode executar em um script em vez da linha de comando.)

Atualizando o número da versão

Para atualizar o número da versão para uma versão específica, execute

xcrun agvtool new-marketing-version <your_specific_version>

Ex: atualize o número da versão para 2.0

xcrun agvtool new-marketing-version 2.0

Atualizando o número da compilação

Para incrementar automaticamente seu número de compilação, execute

xcrun agvtool next-version -all

Para definir o número da compilação do seu aplicativo para uma versão específica, execute

xcrun agvtool new-version -all <your_specific_version>

Ex: Defina o número da compilação como 2.6.9

xcrun agvtool new-version -all 2.6.9

Bônus:

Para visualizar o número da versão atual, execute

xcrun agvtool what-marketing-version

Para visualizar o número da compilação atual, execute

xcrun agvtool what-version

FWIW - é o que estou usando atualmente para aumentar o número da compilação apenas para compilações de versão (que inclui arquivamento). Funciona bem no Xcode 5.1.

Basta copiar / colar o snippet na fase de criação do script Run diretamente no 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;

Obrigado pelo script. Isso funciona muito bem.

Meu Info.plist está em um subdiretório com um nome que contém espaços, então eu tive que modificar o Run Script com aspas no caminho plist:

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

e o shell script da mesma maneira com aspas em todos os caminhos:

#!/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

O script que estou usando atualmente é muito baseado no Alix , acima. Minha adaptação, abaixo, adiciona uma verificação para fazer apenas o incremento automático em uma versão / compilação de arquivo.

Sem essa alteração, haverá conflitos de controle de versão, pois cada desenvolvedor aumentará o número da compilação na sua própria taxa. E o fato de que o histórico do git seria desnecessariamente poluído, com o número da compilação mudando o tempo todo.

# 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}"

Também está disponível (em um formato um pouco mais fácil de copiar e colar) como uma essência do GitHub .

Eu recomendaria o uso de autorevisão .

O Xcode permite que um arquivo de cabeçalho (que pode ser gerado automaticamente no momento da compilação e não no próprio vcs) forneça valores que serão expandidos no info.plist no momento da compilação. Você pode encontrar uma explicação passo a passo sobre como configurar isso no site de revisão automática .

A revisão automática tem um tipo de saída voltado para esses arquivos de cabeçalho para ajudar exatamente nessas situações.

Um problema com algumas dessas soluções é que o Launch Services reconhece apenas quatro cinco dígitos principais na versão do pacote . Eu tenho um projeto com um número de compilação que está na casa dos milhares, então eu queria usar alguns dos dígitos menos significativos.

Esse script Perl incrementa todas as listas de informações do projeto, não apenas a do destino atual; portanto, todos os números de compilação permanecem na mesma etapa. Ele também usa um dígito de correção e dois dígitos menores, portanto, o build 1234 recebe a versão 1.23.4. Eu o uso como um comportamento de pré-construção, portanto se aplica a todos os projetos que eu construo.

O roteiro é bastante forte, mas funciona para mim.

#!/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');
}

Você pode usar o versionamento genérico da Apple . Basicamente, tudo o que você precisa fazer é chamar agvtool next-version -allde dentro do diretório que hospeda o arquivo .xcproj. Para mais detalhes, consulte o URL acima.

Com base na solução de Wil Gieseler , eu tinha apenas uma alteração que queria fazer. Sua solução coloca a contagem de confirmações do git no número da compilação. Útil, mas ainda meio difícil de encontrar o commit real que criou essa compilação. Eu não me importava muito se o número da compilação estava aumentando monotonicamente e, portanto, abandonei esse requisito para que eu pudesse acessar mais facilmente a confirmação que gerava um determinado binário.

Para esse fim, modifiquei seu primeiro script para o seguinte:

# 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>"

Isso converte a versão curta do SHA atual do git em decimal. Caracteres hexadecimais não combinam bem com os requisitos de número de compilação da Apple, e é por isso que eu tive que fazer isso. Para convertê-lo novamente, basta executar algo como isto:

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

no bash, onde <build number>está o número de compilação que você obteve de um binário. Então, apenas corra git checkout $SHA, e lá vai você.

Como essa é uma adaptação da solução de Wil Gieseler , como mencionado acima, você também precisará do seguinte script pós-compilação:

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

o que mantém seu histórico do git limpo.

Eu tentei o procedimento modificado e não funcionou, porque: -

1. O Xcode 4.2.1 altera o subdiretório xcuserdata em .xcodeproj

2. O git observa a alteração anterior no Project-Info.plist

A modificação a seguir faz com que eles sejam ignorados e sinaliza apenas alterações genuínas: -

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

Você pode fazer isso apenas quando arquivar (e fazer upload para o TF, por exemplo). Caso contrário, o número da sua versão poderá subir muito rapidamente.

No esquema (Produto / Editar esquema / Arquivar / Pré-ações), você pode adicionar um script que será executado somente quando você arquivar.

Além disso, você pode redefinir o número da compilação cada vez que incrementa a versão do aplicativo.

Última coisa: se você usar o arquivo morto, poderá desativar com segurança:

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

Como o número da compilação será incrementado somente quando você arquivar ...

EDIT: Corrija o que eu disse, as pré-ações no arquivo morto acontecem após a compilação (mas antes do arquivamento), para que o número da compilação seja incrementado para o próximo arquivo ... Mas você pode criar um novo esquema e adicionar essa ação na compilação (pré- ações) deste novo esquema. e use esse esquema quando desejar criar uma nova compilação

Eu uso a última revisão SVN para o número da compilação. Se você alterar o Info.plist no diretório de construção, não afetará a fonte 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}'`

Sinto como se tivesse encontrado minha tribo. Tribo, espero que você esteja divertido com o VersionX.

Há uma década, enquanto trabalhava em um espaço de trabalho com mais de 25 projetos Xcode, aproveitei a oportunidade para automatizar a versão e criar atualizações de strings a um grau que pode parecer absurdo, se você estiver mantendo apenas um ou dois projetos com atualizações ocasionais.

VersãoX:

• está ciente do tipo de construção (Release / Debug)
• reúne informações em tempo de compilação no repositório (suporte ao git incluído, mas pode ser personalizado para hg, svn ou o que você usar)
• forneceu seqüências de caracteres de versão de marketing sofisticadas e facilmente personalizáveis ​​(que tinham muito mais variações antes da App Store impor uma convenção) para que você pudesse incrementar automaticamente as seqüências de caracteres que incluíam símbolos para um "beta" usando uma convenção de tag git, por exemplo.
• inclui uma classe preenchida com variáveis ​​de instância que contêm informações de versão e confirmação. Isso é útil para preencher o painel sobre e construir seqüências de logs, relatórios de falhas ou relatórios de erros de e-mail do usuário com informações pré-preenchidas.

Foi divertido de fazer. Aprendi muito sobre o sistema de compilação do Xcode.

Aqui está um exemplo do tipo de Versão sofisticada e das seqüências de compilação que o VersionX poderia gerar automaticamente.

VersãoX 1.0.1 β7 (c5959a3 “Limpo”)

Versão de marketing: VersãoX 1.0.1 β7 O "1.0.1 é derivado da tag para confirmação, enquanto o" Beta 7 "é gerado automaticamente pela contagem de confirmação ou contagem de compilação (por exemplo).

Versão de compilação: (c5959a3 “Limpo”) Exibe o hash de confirmação curto e informa que o diretório de compilação teve zero alterações não confirmadas.

VersionX (fonte no GitHub) - um sistema barroco para incrementar automaticamente a versão e criar strings em projetos Xcode.

A documentação do VersionX.

Você pode querer verificar uma nova ferramenta que desenvolvo chamada Xcodebump. Ele pode lidar com a atualização de CFBundleShortVersionString e CFBundleVersion. Como etapa final, ele também fará check-in para git e marcará o commit para corresponder aos valores do CFBundle.

O projeto Xcodebump está localizado aqui:

https://github.com/markeissler/Xcodebump

Eu atualizo build numberseguindo o método.

$INFO_FILEé o caminho do arquivo plist. E $build_numberé um novo número de compilação para este edifício.

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

Geralmente, meu $build_numberé composto por majore minorpartes. O minorveio de informações do projeto. Então, eu descrevo como gerar a majorpeça.

## 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}"

Eu tenho 2 estratégias para decidir o $build_number .

Primeira estratégia

Essa estratégia usa a git tagcontagem para decidir o majorde build number. Se houver 53tags do projeto, ele retornará53 seguindo o script de shell.

Geralmente, está aumentando. E forçará o desenvolvedor a colocar uma tag git antes de publicar.

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

Segunda estratégia

Deixe o sistema Jenkins CI decidir a majorpeça. Tem uma variável de ambiente BUILD_NUMBER. Está aumentando automaticamente ao desenvolver o sistema de IC. Essas informações são úteis para rastrear o histórico do projeto no sistema de IC.

major_number=${BUILD_NUMBER}

Heres uma versão atualizada. Isso funciona a partir do Xcode 9.3.1, iOS 11.

Clique em 'Build Fhases' no destino do aplicativo, clique no ícone + para adicionar um novo script de execução e, na caixa, cole este código.

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}"

Vá para o arquivo Info.plist e defina a 'Versão do pacote' como 1 e a string 'Versões do pacote, curta' para 1, você deve estar definido.

Crie o projeto com o Info.plist em exibição e você verá a alteração da versão do pacote (número da compilação).

• Observe que, a partir do Xcode 9.3.1, você não poderá ver essas alterações na guia geral, mas verá as alterações ao arquivar uma compilação e no Info.plist

Aqui está a minha solução. Se você é como eu: amigável ao terminal, como ruby, como versionamento semântico, tente isso.

Crie um arquivo nomeado Rakefileque contenha isso:

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
}

Preparar: gem install xcodeproj versionomy

Execute: rake increment:majorou rake increment:minorou rake increment:tinyquando quiser.

Acho mais conveniente usar Automatizando versão e compilar números usando o agvtool .

Tente o seguinte:

1. Configure-o conforme descrito na documentação da Apple vinculada acima.
2. Adicione o script como Pré-ação ao Projeto -> Editar esquema ... -> Arquivar (ou outro, se preferir)
3. Definir: fornecer configurações de compilação de <your_app_target>

O script (a primeira linha é opcional):

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

Vamos fazer isso da maneira da Apple. Aumentará o número da compilação após cada compilação bem-sucedida

Vou guiá-lo através de 5 imagens, basta passar por isso.

1. Selecione 'Editar esquema ...' na lista suspensa, quando você seleciona o nome do projeto localizado no lado direito do botão Stop_build_button. Verifique o primeiro passo

2. No menu leftSide, expanda a opção 'Build' e selecione 'Post-actions' Verificar segundo passo

3. Aqui você pode adicionar os códigos (scripts) desejados que deseja executar após a compilação bem-sucedida do seu programa. É o local em que precisamos adicionar uma pequena quantidade de código para que nossa automação funcione perfeitamente. >> 1. selecione o botão 'adicionar (+)' no canto esquerdo para adicionar um novo arquivo de script >> 2. Agora, no menu suspenso, selecione 'Nova ação de execução de script' Verifique a terceira etapa

4. Possui 3 campos >> 1. o shell já está atribuído a você >> 2. agora para 'Fornecer configurações de criação em' Selecione o nome do seu projeto. >> 3. Existe um grande campo para adicionar seu Script, basta copiar e colar esse código: Verifique o Quarto Passo

   PLIST = "$ {PROJECT_DIR} / $ {INFOPLIST_FILE}" PLB = / usr / libexec / PlistBuddy LAST_NUMBER = $ ($ PLB -c "Imprimir CFBundleVersion" "$ PLIST") NEW_VERSION = $ (($ LAST_NUMBER + 1)) $ PLB -c "Conjunto: CFBundleVersion $ NEW_VERSION" "$ PLIST"

5. Depois de concluir a quarta etapa, basta selecionar 'Fechar' para fechar a janela e temos que fazer a última etapa, Vá para o arquivo 'plist.info' no menu Arquivo do projeto e verifique se a tecla 'Bundle Version' na seção 'Key' contém mais Quinto passo da verificação de valor numérico