J'ai utilisé un script shell dans le cadre de mon processus de construction Xcode pour incrémenter le numéro de construction dans le fichier plist , mais cela fait fréquemment planter Xcode 4.2.1 (avec une erreur concernant la cible n'appartenant pas à un projet; je suppose le changement du fichier plist est en quelque sorte déroutant Xcode).

Le script shell a fait cela pour que le numéro de build ne soit incrémenté que agvtoollorsqu'un fichier est plus récent que le fichier plist (donc juste la construction n'a pas incrémenté la valeur):

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

Existe-t-il un moyen d'incrémenter le numéro de build (dans le fichier plist , ou ailleurs) qui ne rompt pas Xcode?

EDIT FINAL : Je fais maintenant ce genre de choses en utilisant un script python que je viens de rendre public sur github . Ce n'est pas bien documenté mais ne devrait pas être difficile à résoudre. En prime, ce dépôt contient également un script utile pour regrouper automatiquement une bibliothèque tierce dans un ensemble d'applications.

Si je comprends bien votre question, vous souhaitez modifier le Project-Info.plistfichier, qui fait partie du modèle de projet standard de Xcode?

La raison pour laquelle je pose cette question est que Project-Info.plistnormalement est sous contrôle de version, et le modifier signifie qu'il sera marqué comme, bien, modifié.

Si cela vous convient, alors l'extrait de code suivant mettra à jour le numéro de build et marquera le fichier comme modifié dans le processus, où se get_build_numbertrouve un script (c'est-à-dire un espace réservé dans cet exemple) pour obtenir le numéro de build (éventuellement incrémenté) que vous voulez utiliser:

#!/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 vous permet de définir n'importe quelle clé dans un fichier plist, pas seulement le numéro de version. Vous pouvez créer tous les fichiers plist de votre choix et les inclure dans les ressources si nécessaire. Ils peuvent ensuite être lus à partir du bundle.

Quant à votre besoin d'afficher la version dans le volet à propos et à d'autres endroits, vous pouvez également examiner les paramètres CFBundleGetInfoStringet CFBundleShortVersionString.

J'ai dérangé beaucoup de réponses à cette question, et aucune d'entre elles ne m'a tout à fait satisfait. Cependant, j'ai finalement trouvé un mélange que j'aime beaucoup!

Il y a deux étapes, une au début et une à la fin de vos phases de construction.

Au début:

# 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

À la fin:

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

En regardant Info.plist dans Xcode, vous verrez que le numéro de version est "DEVELOPMENT", mais l'application construite aura un numéro de version en constante augmentation. (Tant que vous faites toujours vos builds à partir de la même branche.)

La définition du numéro de version sur une chaîne constante à la fin empêche le fichier Info.plist d'être modifié en créant l'application.

Pourquoi j'aime cette méthode:

• Facile
• Ne pollue pas l'historique des versions de Git
• CFBundleVersion est totalement automatique
• Le joli numéro de version peut être modifié quand je veux

J'ai utilisé cette lueur. Cela fonctionne comme prévu. https://gist.github.com/sekati/3172554 (tout le mérite revient à l'auteur original)

Des scripts que j'ai modifiés au fil du temps.

xcode-versionString-generator.sh ,

xcode-build-number-generator.sh

Comme ces éléments essentiels aident la communauté des développeurs, j'en ai fait un projet GitHub. Alors développons-le bien. Voici le projet GitHub: https://github.com/alokc83/Xcode-build-and-version-generator

J'ai mis à jour le code pour les deux scripts un peu d'amélioration. au lieu d'utiliser ci-dessous, récupérez la dernière sur GitHub

Pour la version:

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

Pour construire:

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

Toute cette entrée a été extrêmement utile. J'ai utilisé cette astuce mais j'ai configuré mon script en tant que hook post-commit dans GIT, donc CFBundleVersion est incrémenté après chaque validation réussie. Le script hook va dans .git / hooks. Un journal est laissé dans le répertoire du projet.

Cela répond à mon critère le plus élémentaire. Je veux pouvoir extraire une version de GIT et reconstruire la version exacte que j'avais précédemment. Tout incrément effectué pendant le processus de génération ne le fait pas.

Voici mon 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

Je ne sais pas quel est le meilleur moyen, mais je publierai la réponse d'Apple au cas où quelqu'un la chercherait ...

Selon cet article de questions-réponses d'Apple :

Automatiser les numéros de version et de build à l'aide d'agvtool

Les clés de version et de numéro de build spécifient respectivement les versions marketing et interne de votre application. agvtool est un outil de ligne de commande qui vous permet d'incrémenter automatiquement ces nombres jusqu'au nombre le plus élevé suivant ou à un nombre spécifique.

Le numéro de build identifie une version non publiée ou publiée de votre application. Il est stocké dans Info.plist de votre application en tant que CFBundleVersion(version Bundle).

Vous devez effectuer les étapes suivantes dans votre projet Xcode:

1. Activer agvtool

Accédez au volet Paramètres de construction de votre cible, puis mettez-le à jour pour toutes vos configurations de construction comme suit:

• Définissez la version actuelle du projet sur une valeur de votre choix.

Le fichier de données de votre projet Xcode, project.pbxproj, comprend un CURRENT_PROJECT_VERSIONparamètre de construction (Version actuelle du projet), qui spécifie la version actuelle de votre projet. agvtool recherche project.pbxproj CURRENT_PROJECT_VERSION. Il continue de fonctionner s'il CURRENT_PROJECT_VERSIONexiste et s'arrête, sinon. Sa valeur est utilisée pour mettre à jour le numéro de build.

• Définissez le système de gestion des versions sur Apple Generic.

Par défaut, Xcode n'utilise aucun système de contrôle de version. La définition du système de gestion des versions sur Apple Generic garantit que Xcode inclura toutes les informations de version générées par agvtool dans votre projet.

2. Configurez votre version et vos numéros de build

agvtool recherche dans l'Info.plist de votre application votre version et les numéros de build. Il les met à jour s'ils existent et ne fait rien, sinon. Assurez-vous que les clés CFBundleVersion(Bundle version) et CFBundleShortVersionString(Bundle versions string, short) existent dans votre Info.plist, comme indiqué dans l'image ci-dessous:

Quittez Xcode, puis accédez au répertoire contenant votre fichier de projet .xcodeproj dans l'application Terminal avant d'exécuter l'une des commandes suivantes. Le fichier de projet .xcodeproj contient project.pbxproj, qui est utilisé par agvtool. (C'est la partie que vous pouvez exécuter dans un script au lieu de la ligne de commande.)

Mise à jour du numéro de version

Pour mettre à jour le numéro de version vers une version spécifique, exécutez

xcrun agvtool new-marketing-version <your_specific_version>

Ex: mettez à jour le numéro de version à 2.0

xcrun agvtool new-marketing-version 2.0

Mise à jour du numéro de build

Pour incrémenter automatiquement votre numéro de build, exécutez

xcrun agvtool next-version -all

Pour définir le numéro de build de votre application sur une version spécifique, exécutez

xcrun agvtool new-version -all <your_specific_version>

Ex: définissez le numéro de build sur 2.6.9

xcrun agvtool new-version -all 2.6.9

Prime:

Pour afficher le numéro de version actuel, exécutez

xcrun agvtool what-marketing-version

Pour afficher le numéro de version actuel, exécutez

xcrun agvtool what-version

FWIW - c'est ce que j'utilise actuellement pour augmenter le numéro de version uniquement pour les versions de version (qui comprend l'archivage). Fonctionne très bien sous Xcode 5.1.

Copiez / collez simplement l'extrait de code dans une phase de création de script d' exécution directement dans 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;

Merci pour le script. Cela fonctionne très bien.

Mon Info.plist se trouve dans un sous-répertoire avec un nom contenant des espaces, j'ai donc dû modifier le Run Script avec des guillemets autour du chemin plist:

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

et le script shell de la même manière avec des guillemets autour de tous les chemins:

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

Le script que j'utilise actuellement est très basé sur celui d' Alix , ci-dessus. Mon adaptation, ci-dessous, ajoute une vérification pour ne faire l'auto-incrémentation que sur une version de version / archive.

Sans ce changement, il y aura des conflits de contrôle de version car chaque développeur incrémentera le numéro de build à son propre rythme. Et le fait que l'historique de git serait inutilement pollué avec le numéro de build changeant tout le temps.

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

Il est également disponible (dans un format légèrement plus facile à copier et coller) sous la forme d'un gist GitHub .

Je recommanderais l'utilisation de l' autorevision .

Xcode permet à un fichier d'en-tête (qui peut être généré automatiquement au moment de la construction et non dans le vcs lui-même) pour fournir des valeurs qui seront développées dans le fichier info.plist au moment de la construction. Vous pouvez trouver une procédure pas à pas pour configurer cela sur le site Web de la visualisation automatique .

Autorevision a un type de sortie orienté vers ces types de fichiers d'en-tête pour aider exactement dans ces situations.

Un problème avec certaines de ces solutions est que Launch Services ne reconnaît que quatre cinq chiffres majeurs dans la version du bundle . J'ai un projet avec un numéro de build qui se chiffre en milliers, donc je voulais utiliser certains des chiffres les moins significatifs.

Ce script Perl incrémente tous les Info.plists dans le projet, pas seulement celui de la cible actuelle, de sorte que les numéros de build restent tous au même niveau. Il utilise également un chiffre de correctif et deux chiffres mineurs, donc la version 1234 est donnée à la version 1.23.4. Je l'utilise comme comportement pré-build, donc il s'applique à tous les projets que je construis.

Le script est assez brutal, mais cela fonctionne pour moi.

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

Vous pouvez utiliser le contrôle de version générique d'Apple . En gros, tout ce que vous avez à faire est d'appeler agvtool next-version -alldepuis le répertoire qui héberge votre fichier .xcproj. Pour plus de détails, consultez l'url ci-dessus.

En m'appuyant sur la solution de Wil Gieseler , je n'avais qu'un seul changement à apporter. Sa solution place le nombre de commits git dans le numéro de build. Utile, mais toujours un peu pénible pour trouver le commit réel qui a créé cette construction. Je ne me souciais pas trop de savoir si le numéro de build augmentait de manière monotone, et j'ai donc abandonné cette exigence afin de pouvoir accéder plus facilement au commit qui générait un binaire donné.

À cette fin, j'ai modifié son premier script comme suit:

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

Cela convertit la version courte de l'actuel git SHA en décimal. Les caractères hexadécimaux ne fonctionnent pas bien avec les exigences de numéro de version d'Apple, c'est pourquoi j'ai dû le faire. Pour le reconvertir, exécutez simplement quelque chose comme ceci:

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

dans bash, où <build number>est le numéro de build que vous avez obtenu d'un binaire. Ensuite, courez git checkout $SHA, et voilà.

Comme il s'agit d'une adaptation de la solution de Wil Gieseler , comme mentionné ci-dessus, vous aurez également besoin du script post-build suivant:

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

ce qui garde votre historique git propre.

J'ai essayé la procédure modifiée et cela n'a pas fonctionné, car: -

1. Xcode 4.2.1 modifie le sous-répertoire xcuserdata dans .xcodeproj

2. git note le changement précédent dans Project-Info.plist

La modification suivante les fait ignorer et ne signale que les changements authentiques: -

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

Vous voudrez peut-être faire cela uniquement lorsque vous archivez (et téléchargez sur TF par exemple). Sinon, votre numéro de version pourrait augmenter très rapidement.

Dans le schéma (Produit / Modifier le schéma / Archiver / Pré-actions), vous pouvez ajouter un script qui ne sera exécuté que lors de l'archivage.

En outre, vous souhaiterez peut-être réinitialiser le numéro de version chaque fois que vous incrémentez la version de l'application.

Dernière chose, si vous utilisez plutôt l'archive, vous pouvez désactiver en toute sécurité:

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

Comme le numéro de build ne sera incrémenté que lorsque vous archivez ...

EDIT: Corrigez ce que j'ai dit, les pré-actions dans l'archive se produisent après la construction (mais avant l'archivage), donc le numéro de build sera incrémenté pour la prochaine archive ... Mais vous pouvez créer un nouveau schéma et ajouter cette action dans la build (pré- actions) de ce nouveau schéma. et utilisez ce schéma lorsque vous souhaitez créer une nouvelle version

J'utilise la dernière révision SVN pour le numéro de build. Si vous modifiez le fichier Info.plist dans le répertoire de construction, vous n'affecterez pas le fichier Info.plist source:

# 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}'`

J'ai l'impression d'avoir trouvé ma tribu. Tribe, j'espère que vous êtes amusé par VersionX.

Il y a dix ans, alors que je travaillais sur un espace de travail contenant plus de 25 projets Xcode, j'ai profité de l'occasion pour automatiser la version et créer des mises à jour de chaînes à un degré qui peut sembler absurde, si vous ne maintenez qu'un ou deux projets avec des mises à jour occasionnelles.

VersionX:

• est conscient du type de construction (Release / Debug)
• recueille des informations au moment de la construction à partir du référentiel (support git inclus, mais peut être personnalisé pour hg, svn ou tout ce que vous utilisez)
• fourni des chaînes de version marketing de fantaisie facilement personnalisables (qui avaient beaucoup plus de variations avant que l'App Store n'impose une convention) afin que vous puissiez automatiquement incrémenter les chaînes qui incluaient des symboles pour une "bêta" en utilisant une convention de balise git, par exemple.
• inclut une classe remplie de variables d'instance contenant des informations de version et de validation. Ceci est utile pour remplir votre panneau À propos et créer des chaînes de journalisation, des rapports d'incident ou des rapports de bogue par e-mail d'utilisateur avec des informations pré-remplies.

C'était amusant à faire. J'ai appris beaucoup de choses sur le système de construction Xcode.

Voici un exemple du type de chaînes de version fantaisie et de construction que VersionX pourrait générer automatiquement.

VersionX 1.0.1 β7 (c5959a3 «Clean»)

Version marketing: VersionX 1.0.1 β7 Le "1.0.1 est dérivé de la balise pour le commit, tandis que le" Beta 7 "est automatiquement généré par le nombre de commit, ou le nombre de build (par exemple).

Version de build: (c5959a3 «Clean») Affiche le hachage de validation court et vous informe que le répertoire de build ne comportait aucune modification non validée.

VersionX (source sur GitHub) - un système baroque pour incrémenter automatiquement la version et créer des chaînes dans les projets Xcode.

La documentation VersionX.

Vous voudrez peut-être consulter un nouvel outil que j'ai développé appelé Xcodebump. Il peut gérer la mise à jour de CFBundleShortVersionString et CFBundleVersion. En guise d'étape finale, il vérifiera également git et marquera le commit pour qu'il corresponde à ces valeurs CFBundle.

Le projet Xcodebump se trouve ici:

https://github.com/markeissler/Xcodebump

Je mets à jour build numberen suivant la méthode.

$INFO_FILEest le chemin du fichier plist. Et $build_numberc'est un nouveau numéro de construction pour ce bâtiment.

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

Généralement, my $build_numberest composé de majoret de minorparties. Cela minorprovient des informations du projet. Je décris donc comment générer la majorpièce.

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

J'ai 2 stratégies pour décider du $build_number.

Première stratégie

Cette stratégie utilise le git tagdécompte pour décider du majorde build number. S'il y a des 53balises du projet, il reviendra 53en suivant le script shell.

Généralement, il augmente. Et cela obligera le développeur à mettre une balise git avant la publication.

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

Deuxième stratégie

Laissez le système Jenkins CI décider de la majorpièce. Il a une variable d'environnement BUILD_NUMBER. Il augmente automatiquement lors de la construction du système CI. Ces informations sont utiles pour retracer l'historique du projet sur le système CI.

major_number=${BUILD_NUMBER}

Voici une version mise à jour. Cela fonctionne à partir de Xcode 9.3.1, iOS 11.

Cliquez sur 'Build Phases' à partir de votre application cible, cliquez sur l'icône + pour ajouter un nouveau script d'exécution, et dans la case, collez ce code.

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

Allez dans le fichier Info.plist et définissez la «version du bundle» sur 1 et la «chaîne de versions du bundle, courte» sur 1, vous devriez être défini.

Générez le projet avec Info.plist en vue, et vous devriez voir le changement de version du bundle (numéro de build).

• Notez qu'à partir de Xcode 9.3.1, vous ne pourrez pas voir ces modifications à partir de l'onglet général, mais vous verrez les modifications lorsque vous archivez une compilation et dans Info.plist

Voici ma solution. Si vous êtes comme moi: compatible avec les terminaux, comme ruby, comme le versionnage sémantique, essayez ceci.

Créez un fichier nommé Rakefilequi contient ceci:

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
}

Préparer: gem install xcodeproj versionomy

Exécutez: rake increment:majorou rake increment:minorou rake increment:tinyquand vous le souhaitez.

Je trouve plus pratique d'utiliser l' automatisation des numéros de version et de construction à l'aide d'agvtool .

Essaye ça:

1. Configurez-le comme décrit dans la documentation Apple liée ci-dessus.
2. Ajouter un script comme pré-action au projet -> Modifier le schéma ... -> Archiver (ou autre si vous préférez)
3. Définir: fournir les paramètres de construction à partir de <your_app_target>

Le script (la première ligne est facultative):

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

Faisons cela à la manière d'Apple. Cela augmentera le nombre de build après chaque build réussi

Je vais vous guider à travers 5 images, parcourez-les.

1. Sélectionnez 'Edit Scheme ...' dans la liste déroulante, lorsque vous sélectionnez le nom de votre projet situé à droite du bouton Stop_build_button. Vérifiez la première étape

2. Dans le menu de gauche, développez l'option 'Construire' et sélectionnez 'Post-actions' Vérifiez la deuxième étape

3. Ici, vous pouvez ajouter les codes (scripts) que vous souhaitez exécuter après la construction réussie de votre programme. C'est l'endroit où nous devons ajouter un peu de code pour que notre automatisation fonctionne parfaitement. >> 1. sélectionnez le bouton "ajouter (+)" dans le coin gauche pour ajouter un nouveau fichier de script >> 2. Maintenant, dans le menu déroulant, sélectionnez "Nouvelle action de script d'exécution" Vérifiez la troisième étape

4. Il a 3 champs >> 1. shell est déjà assigné pour vous >> 2. maintenant pour «Fournir les paramètres de construction à partir de» Sélectionnez le nom de votre projet. >> 3. Theres un grand champ pour ajouter votre script, copiez et collez simplement ce code là: Vérifiez la quatrième étape

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

5. Après avoir terminé la 4ème étape, sélectionnez simplement `` Fermer '' pour fermer la fenêtre et nous devons faire la dernière étape, accédez à votre fichier `` plist.info '' dans le menu Fichier du projet et assurez-vous que la clé `` Version du bundle '' sous la section `` Clé '' contient le plus a Vérification de la valeur numérique Cinquième étape