He estado usando un script de shell como parte de mi proceso de compilación de Xcode para incrementar el número de compilación dentro del archivo plist , sin embargo, hace que Xcode 4.2.1 se bloquee con frecuencia (con un error sobre el objetivo que no pertenece a un proyecto; supongo El cambio del archivo plist confunde Xcode de alguna manera).

El script de shell hizo esto para que el número de compilación solo se incremente agvtoolcuando un archivo es más nuevo que el archivo plist (por lo que solo la construcción no incrementó el valor):

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

¿Hay alguna manera de incrementar el número de compilación (en el archivo plist o en cualquier otro lugar) que no rompa Xcode?

EDICIÓN FINAL : ahora hago este tipo de cosas usando un script de Python que acabo de hacer público en github . No está bien documentado, pero no debería ser difícil de resolver. Como beneficio adicional, este repositorio también contiene una secuencia de comandos útil para agrupar automáticamente la biblioteca de terceros en un paquete de aplicaciones.

Si entiendo su pregunta correctamente, ¿desea modificar el Project-Info.plistarchivo, que es parte de la plantilla de proyecto estándar de Xcode?

La razón por la que pregunto esto es que Project-Info.plistnormalmente está bajo control de versión, y modificarlo significa que se marcará como, bueno, modificado.

Si eso está bien con usted, entonces el siguiente fragmento actualizará el número de compilación y marcará el archivo como modificado en el proceso, donde get_build_numberhay algún script (es decir, un marcador de posición en este ejemplo) para obtener el número de compilación (posiblemente incrementado) que quiere 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

PlistBuddy le permite configurar cualquier clave en un archivo plist, no solo el número de versión. Puede crear todos los archivos plist que desee e incluirlos en los recursos si es necesario. Luego se pueden leer desde el paquete.

En cuanto a su necesidad de mostrar la versión en el panel Acerca de y otros lugares, también puede consultar la configuración CFBundleGetInfoStringy CFBundleShortVersionString.

He jugado muchas de las respuestas a esta pregunta, y ninguna de ellas me satisfizo. Sin embargo, finalmente se me ocurrió una mezcla que realmente me gusta.

Hay dos pasos, uno al principio y otro al final de las fases de construcción.

Al principio:

# 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

Al final:

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

Al mirar Info.plist en Xcode, verá que el número de versión es "DESARROLLO", pero la aplicación desarrollada tendrá un número de compilación en constante aumento. (Siempre y cuando siempre hagas tus compilaciones desde la misma rama).

Establecer el número de versión nuevamente en una cadena constante al final evita que el archivo Info.plist se cambie al compilar la aplicación.

Por qué me gusta este método:

• Fácil
• No contamina el historial de versiones de Git
• CFBundleVersion es totalmente automático
• El bonito número de versión se puede modificar cuando quiera

He usado esta lista. Funciona como se esperaba. https://gist.github.com/sekati/3172554 (todo el crédito va al autor original)

Scripts que modifiqué con el tiempo.

xcode-versionString-generator.sh ,

xcode-build-number-generator.sh

Como estos aspectos esenciales están ayudando a la comunidad de desarrolladores, hice que el proyecto GitHub fuera de él. Así que desarrollémoslo bien. Aquí está el proyecto GitHub: https://github.com/alokc83/Xcode-build-and-version-generator

He actualizado el código para ambas secuencias de comandos un poco de mejora. en lugar de usar a continuación, tome lo último de GitHub

Para la versión:

# 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 construir:

# 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 esta entrada fue extremadamente útil. Utilicé este truco pero configuré mi script como un enlace posterior a la confirmación en GIT, por lo que CFBundleVersion se incrementa después de cada confirmación exitosa. El script de gancho va en .git / hooks. Se deja un registro en el directorio del proyecto.

Esto cumple con mi criterio más básico. Quiero poder extraer una versión de GIT y reconstruir la compilación exacta que tenía anteriormente. Cualquier incremento realizado durante el proceso de compilación no hace esto.

Aquí está mi guión:

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

No sé cuál es la mejor, pero publicaré la respuesta de Apple en caso de que alguien la esté buscando ...

De acuerdo con esta publicación de preguntas y respuestas de Apple :

Automatización de versiones y números de compilación utilizando agvtool

Las teclas de versión y número de compilación especifican respectivamente las versiones de marketing e internas de su aplicación. agvtool es una herramienta de línea de comandos que le permite incrementar automáticamente estos números al siguiente número más alto o a un número específico.

El número de compilación identifica una versión inédita o lanzada de su aplicación. Se almacena en la lista de información de su aplicación comoCFBundleVersion (versión de paquete).

Debe completar los siguientes pasos en su proyecto Xcode:

1. Habilitar agvtool

Navegue hasta el panel Configuración de compilación de su destino, luego actualícelo para todas sus configuraciones de compilación de la siguiente manera:

• Establezca la Versión del proyecto actual en el valor que elija.

Su archivo de datos del proyecto Xcode, project.pbxproj, incluye una CURRENT_PROJECT_VERSIONconfiguración de compilación (Versión actual del proyecto), que especifica la versión actual de su proyecto. agvtool busca project.pbxproj para CURRENT_PROJECT_VERSION. Continúa ejecutándose si CURRENT_PROJECT_VERSIONexiste y deja de ejecutarse, de lo contrario. Su valor se utiliza para actualizar el número de compilación.

• Establezca el Sistema de versiones en Apple Generic.

Por defecto, Xcode no utiliza ningún sistema de versiones. Establecer el sistema de control de versiones en Apple Generic garantiza que Xcode incluirá toda la información de versión generada por agvtool en su proyecto.

2. Configure su versión y números de compilación

agvtool busca en la lista Info.plist de su aplicación su versión y números de compilación. Los actualiza si existen y no hace nada, de lo contrario. Asegúrese de que las teclas CFBundleVersion(Versión de paquete) y CFBundleShortVersionString(Cadena de versiones de paquete, abreviadas) existan en su Lista de información como se ve en la imagen a continuación:

Salga de Xcode, luego navegue al directorio que contiene su archivo de proyecto .xcodeproj en la aplicación Terminal antes de ejecutar cualquiera de los siguientes comandos. El archivo de proyecto .xcodeproj contiene project.pbxproj, que es utilizado por agvtool. (Esta es la parte que puede ejecutar en un script en lugar de la línea de comando).

Actualización del número de versión

Para actualizar el número de versión a una versión específica, ejecute

xcrun agvtool new-marketing-version <your_specific_version>

Ejemplo: actualice el número de versión a 2.0

xcrun agvtool new-marketing-version 2.0

Actualización del número de compilación

Para incrementar automáticamente su número de compilación, ejecute

xcrun agvtool next-version -all

Para establecer el número de compilación de su aplicación en una versión específica, ejecute

xcrun agvtool new-version -all <your_specific_version>

Ejemplo: establezca el número de compilación en 2.6.9

xcrun agvtool new-version -all 2.6.9

Prima:

Para ver el número de versión actual, ejecute

xcrun agvtool what-marketing-version

Para ver el número de compilación actual, ejecute

xcrun agvtool what-version

FWIW: esto es lo que estoy usando actualmente para aumentar el número de compilación solo para las versiones de lanzamiento (que incluye el archivado). Funciona bien bajo Xcode 5.1.

Simplemente copie / pegue el fragmento en una fase de compilación del script de ejecución directamente en 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;

Gracias por el guion. Funciona muy bien

Mi Info.plist está en un subdirectorio con un nombre que contiene espacios, así que tuve que modificar el script de ejecución con comillas alrededor de la ruta de plist:

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

y el script de shell de la misma manera con comillas alrededor de todas las rutas:

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

El guión que estoy usando actualmente está muy basado en Alix , arriba. Mi adaptación, a continuación, agrega una verificación para hacer solo el incremento automático en una versión / archivo de compilación.

Sin ese cambio, habrá conflictos de control de versión ya que cada desarrollador incrementará el número de compilación a su propio ritmo. Y el hecho de que el historial de git se contaminaría innecesariamente con el número de compilación cambiando todo el tiempo.

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

También está disponible (en un formato un poco más fácil de copiar y pegar) como una esencia de GitHub .

Recomendaría el uso de autorrevisión .

Xcode permite un archivo de encabezado (que se puede generar automáticamente en el momento de la compilación y no en las vcs) para proporcionar valores que se expandirán en info.plist en el momento de la compilación. Puede encontrar un tutorial para configurar esto en el sitio web de revisión automática .

La revisión automática tiene un tipo de salida orientado a estos tipos de archivos de encabezado para ayudar exactamente en estas situaciones.

Un problema con algunas de estas soluciones es que Launch Services solo reconoce cuatro cinco dígitos principales en la versión de paquete . Tengo un proyecto con un número de compilación que está en los miles, por lo que quería usar algunos de los dígitos menos significativos.

Este script de Perl incrementa todos los Info.plists en el proyecto, no solo el del objetivo actual, por lo que todos los números de compilación permanecen en el bloque. También usa un dígito de parche y dos dígitos menores, por lo que la compilación 1234 recibe la versión 1.23.4. Lo uso como un comportamiento previo a la compilación, por lo que se aplica a todos los proyectos que construyo.

El guión es bastante fuerza bruta, pero funciona para mí.

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

Podrías usar las versiones genéricas de Apple . Básicamente, todo lo que tiene que hacer es llamar agvtool next-version -alldesde el directorio que aloja su archivo .xcproj. Para obtener más detalles, consulte la url anterior.

Sobre la base de la solución de Wil Gieseler , solo tenía un cambio que quería hacer. Su solución pone el recuento de git commits en el número de compilación. Útil, pero sigue siendo un poco difícil encontrar la confirmación real que creó esa compilación. No me importaba demasiado si el número de compilación aumentaba monotónicamente, por lo que eliminé ese requisito para poder acceder más fácilmente a la confirmación que generó un binario dado.

Con ese fin, modifiqué su primer script a lo siguiente:

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

Esto convierte la versión corta del git SHA actual en decimal. Los caracteres hexadecimales no funcionan bien con los requisitos de número de compilación de Apple, por lo que tuve que hacer esto. Para volver a convertirlo, simplemente ejecuta algo como esto:

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

en bash, ¿dónde <build number>está el número de compilación que obtuviste de un binario? Luego, solo corre git checkout $SHAy listo.

Como se trata de una adaptación de la solución de Wil Gieseler , como se mencionó anteriormente, también necesitará el siguiente script posterior a la compilación:

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

que mantiene limpio tu historial de git.

Intenté el procedimiento modificado y no funcionó porque: -

1. Xcode 4.2.1 cambia el subdirectorio xcuserdata en .xcodeproj

2. git observa el cambio anterior en Project-Info.plist

La siguiente modificación hace que se ignoren y solo marca cambios genuinos: -

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

Es posible que desee hacer esto solo cuando archiva (y carga a TF, por ejemplo). De lo contrario, su número de versión podría subir muy rápido.

En el esquema (Producto / Editar esquema / Archivar / Pre-acciones) puede agregar un script que se ejecutará solo cuando archiva.

Además, es posible que desee restablecer el número de compilación cada vez que incremente la versión de la aplicación.

Lo último, si usa el archivo en su lugar, puede deshabilitar de forma segura:

# 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 el número de compilación se incrementará solo cuando archives ...

EDITAR: corrija lo que dije, las acciones previas en el archivo ocurren después de la compilación (pero antes del archivo), por lo que el número de compilación se incrementará para el próximo archivo ... Pero puede crear un nuevo esquema y agregar esta acción en la compilación (pre acciones) de este nuevo esquema. y usa este esquema cuando quieras crear una nueva compilación

Yo uso la última revisión SVN para el número de compilación. Si cambia Info.plist en el directorio de compilación, no afectará la fuente 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}'`

Siento que he encontrado a mi tribu. Tribu, espero que VersionX te divierta.

Hace una década, mientras trabajaba en un espacio de trabajo que tenía más de 25 proyectos de Xcode, aproveché la oportunidad para automatizar la versión y crear actualizaciones de cadenas en un grado que podría parecer absurdo, si solo mantiene uno o dos proyectos con actualizaciones ocasionales.

VersionX:

• conoce el tipo de compilación (Release / Debug)
• recopila información en el momento de la compilación desde el repositorio (se incluye soporte de git, pero se puede personalizar para hg, svn o lo que sea que use)
• proporcionó cadenas de versiones de marketing sofisticadas y fácilmente personalizables (que tenían mucha más variación antes de que la App Store impusiera una convención) para que pudiera incrementar automáticamente las cadenas que incluían símbolos para una "beta" usando una convención de etiqueta git, por ejemplo.
• incluye una clase poblada con variables de instancia que contienen información de versión y confirmación. Esto es útil para completar el panel Acerca de y construir cadenas de registro, informes de fallos o informes de errores de correo electrónico del usuario con información previamente rellenada.

Fue divertido hacerlo. Aprendí mucho sobre el sistema de construcción Xcode.

Aquí hay un ejemplo del tipo de versión elegante y cadenas de compilación que VersionX podría generar automáticamente.

VersiónX 1.0.1 β7 (c5959a3 "Limpio")

Versión de marketing: VersiónX 1.0.1 β7 El "1.0.1 se deriva de la etiqueta para la confirmación, mientras que la" Beta 7 "se genera automáticamente por el recuento de confirmación o el recuento de compilación (por ejemplo).

Versión de compilación: (c5959a3 "Limpio") Muestra el hash de confirmación breve y le informa que el directorio de compilación no tuvo cambios no confirmados.

VersionX (fuente en GitHub): un sistema barroco para incrementar automáticamente la versión y crear cadenas en proyectos de Xcode.

La documentación de VersionX.

Es posible que desee ver una nueva herramienta que he estado desarrollando llamada Xcodebump. Puede manejar la actualización de CFBundleShortVersionString y CFBundleVersion. Como paso final, también registrará git y etiquetará el commit para que coincida con esos valores de CFBundle.

El proyecto Xcodebump se encuentra aquí:

https://github.com/markeissler/Xcodebump

Actualizo build numbersiguiendo el método.

$INFO_FILEes la ruta del archivo plist. Y $build_numberes un nuevo número de compilación para este edificio.

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

En general, my $build_numberestá compuesto por majory minorpartes. El minorproviene de la información del proyecto. Así que describo cómo generar la majorparte.

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

Tengo 2 estrategias para decidir el $build_number .

Primera estrategia

Esta estrategia utiliza el git tagrecuento para decidir el majorde build number. Si hay 53etiquetas del proyecto, regresará 53siguiendo el script de shell.

En general, está aumentando. Y obligará al desarrollador a poner una etiqueta git antes de publicar.

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

Segunda estrategia

Deje que el sistema Jenkins CI decida la majorparte. Tiene una variable de entorno BUILD_NUMBER. Está aumentando automáticamente cuando se construye en el sistema CI. Esta información es útil para rastrear el historial del proyecto en el sistema CI.

major_number=${BUILD_NUMBER}

Heres una versión actualizada. Esto funciona a partir de Xcode 9.3.1, iOS 11.

Haga clic en 'Crear fases' desde el objetivo de su aplicación, haga clic en el icono + para agregar un nuevo script de ejecución y, en el cuadro, pegue 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}"

Vaya al archivo Info.plist y configure la 'Versión del paquete' en 1, y la 'Cadena de versiones del paquete, corta' en 1, debe estar configurado.

Cree el proyecto con Info.plist a la vista, y debería ver el cambio de la versión del paquete (número de compilación).

• Tenga en cuenta que a partir de Xcode 9.3.1, no podrá ver estos cambios desde la pestaña general, pero verá los cambios cuando archive una compilación y en Info.plist

Aquí está mi solución. Si eres como yo: terminal amigable, como rubí, como versiones semánticas, prueba esto.

Haga un archivo llamado Rakefileque contenga esto:

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

Ejecutar: rake increment:majoro rake increment:minoro rake increment:tinysiempre que lo desee.

Me resulta más conveniente utilizar la versión de automatización y los números de compilación utilizando agvtool .

Prueba esto:

1. Configúrelo como se describe en la documentación de Apple vinculada anteriormente.
2. Agregue script como Pre-acción al Proyecto -> Editar esquema ... -> Archivar (u otro si lo prefiere)
3. Establecer: Proporcionar configuraciones de compilación de <your_app_target>

El script (la primera línea es opcional):

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

Hagamos esto a la manera de Apple. Aumentará el número de compilación después de cada compilación exitosa

Te guiaré a través de 5 imágenes, solo hazlo.

1. Seleccione 'Editar esquema ...' en el menú desplegable, cuando seleccione el nombre de su proyecto ubicado en el lado derecho del botón Stop_build_button. Verificar primer paso

2. Desde el menú lateral izquierdo, expanda la opción 'Construir' y seleccione 'Acciones posteriores' Verifique el segundo paso

3. Aquí puede agregar sus códigos deseados (scripts) que desea ejecutar después de la compilación exitosa de su programa. Es el lugar donde tenemos que agregar una pequeña cantidad de código para que nuestra automatización funcione perfectamente. >> 1. seleccione el botón 'agregar (+)' de la esquina lateral izquierda para agregar un nuevo archivo de secuencia de comandos >> 2. Ahora, desde el menú desplegable, seleccione 'Nueva acción de ejecución de secuencia de comandos' Verifique el tercer paso

4. Tiene 3 campos >> 1. Shell ya está asignado para usted >> 2. ahora para 'Proporcionar configuraciones de compilación desde' Seleccione su nombre de proyecto. >> 3. Hay un gran campo para agregar su secuencia de comandos, simplemente copie y pegue este código allí: Marque el cuarto paso

   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. Después de completar el cuarto paso, simplemente seleccione 'Cerrar' para cerrar la ventana y tenemos que hacer el último paso, vaya a su archivo 'plist.info' en el menú Archivo de proyecto y asegúrese de que la clave 'Versión de paquete' en la sección 'Clave' contenga más un control numérico del quinto paso