Ho usato uno script di shell come parte del mio processo di compilazione di Xcode per incrementare il numero di build all'interno del file plist , tuttavia sta causando l'arresto frequente di Xcode 4.2.1 (con un errore sulla destinazione non appartenente a un progetto; suppongo la modifica del file plist confonde Xcode in qualche modo).

Lo script shell ha fatto questo in modo che il numero di build sia incrementato solo agvtoolquando un file è più recente del file plist (quindi solo la costruzione non ha incrementato il valore):

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

C'è un modo per aumentare il numero di build (nel file plist o altrove) che non rompe Xcode?

FINAL EDIT : ora faccio questo tipo di cose usando uno script Python che ho appena reso pubblico su Github . Non è ben documentato ma non dovrebbe essere difficile da capire. Come bonus questo repository contiene anche un utile script per raggruppare automaticamente la libreria di terze parti in un pacchetto di app.

Se capisco correttamente la tua domanda, vuoi modificare il Project-Info.plistfile, che fa parte del modello di progetto standard di Xcode?

Il motivo per cui lo chiedo è che Project-Info.plistnormalmente è sotto il controllo della versione e modificarlo significa che verrà contrassegnato come, bene, modificato.

Se per te va bene, il frammento seguente aggiornerà il numero di build e contrassegnerà il file come modificato nel processo, dove get_build_numberè presente uno script (ovvero un segnaposto in questo esempio) per ottenere il numero di build (eventualmente incrementato) che vuoi usare:

#!/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 ti consente di impostare qualsiasi chiave in un file plist, non solo il numero di versione. È possibile creare tutti i file plist desiderati e includerli nelle risorse, se necessario. Possono quindi essere letti dal pacchetto.

Per quanto riguarda la necessità di mostrare la versione nel riquadro Informazioni e in altri luoghi, è possibile anche esaminare l'impostazione CFBundleGetInfoStringe CFBundleShortVersionString.

Ho incasinato molte risposte su questa domanda, e nessuna di esse mi ha soddisfatto. Tuttavia, ho finalmente trovato una miscela che mi piace molto!

Ci sono due passaggi, uno all'inizio e uno alla fine delle fasi di costruzione.

All'inizio:

# 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

Alla fine:

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

Guardando la Info.plist in Xcode vedrai che il numero di versione è "SVILUPPO", ma l'app costruita avrà un numero di build in costante aumento. (Fintanto che fai sempre le tue build dallo stesso ramo.)

L'impostazione del numero di versione su una stringa costante alla fine impedisce la modifica del file Info.plist creando l'app.

Perché mi piace questo metodo:

• Facile
• Non inquina la cronologia delle versioni di Git
• CFBundleVersion è totalmente automatico
• Il grazioso numero di versione può essere modificato ogni volta che voglio

Ho usato questo luccichio. Funziona come previsto. https://gist.github.com/sekati/3172554 (tutto il merito va all'autore originale)

Script che ho modificato nel tempo.

xcode-versionString-generator.sh ,

xcode-build-number-generator.sh

Dato che queste informazioni stanno aiutando la comunità degli sviluppatori, ho realizzato il progetto GitHub. Quindi sviluppiamolo bene. Ecco il progetto GitHub: https://github.com/alokc83/Xcode-build-and-version-generator

Ho aggiornato il codice per entrambi gli script un po 'di miglioramento. invece di usare di seguito prendi le ultime novità da GitHub

Per la versione:

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

Per costruire:

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

L'intera voce è stata estremamente utile. Ho usato questo trucco ma ho impostato il mio script come hook post-commit in GIT, quindi CFBundleVersion viene incrementato dopo ogni commit riuscito. Lo script hook va in .git / hooks. Un registro viene lasciato nella directory del progetto.

Questo soddisfa il mio criterio più elementare. Voglio essere in grado di estrarre una versione da GIT e ricostruire l'esatta build che avevo in precedenza. Qualsiasi incremento fatto durante il processo di compilazione non lo fa.

Ecco la mia sceneggiatura:

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

Non so quale sia il modo migliore, ma posterò la risposta di Apple nel caso in cui qualcuno la stia cercando ...

Secondo questo post di domande e risposte di Apple :

Automatizzare i numeri di versione e build utilizzando agvtool

Le chiavi di versione e numero di build specificano rispettivamente le versioni di marketing e interne dell'applicazione. agvtool è uno strumento da riga di comando che consente di incrementare automaticamente questi numeri al successivo numero più alto o a un numero specifico.

Il numero di build identifica una versione non rilasciata o rilasciata dell'applicazione. È memorizzato nel Info.plist dell'applicazione come CFBundleVersion(Versione bundle).

È necessario completare i seguenti passaggi nel progetto Xcode:

1. Abilita agvtool

Passare al riquadro Impostazioni build del target, quindi aggiornarlo per tutte le configurazioni di build come segue:

• Imposta la versione corrente del progetto su un valore a tua scelta.

Il file di dati del progetto Xcode, project.pbxproj, include CURRENT_PROJECT_VERSIONun'impostazione di build (Versione progetto corrente), che specifica la versione corrente del progetto. agvtool cerca project.pbxproj per CURRENT_PROJECT_VERSION. Continua a funzionare se CURRENT_PROJECT_VERSIONesiste e smette di funzionare, altrimenti. Il suo valore viene utilizzato per aggiornare il numero di build.

• Imposta Versioning System su Apple Generic.

Per impostazione predefinita, Xcode non utilizza alcun sistema di controllo delle versioni. L'impostazione di Versioning System su Apple Generic garantisce che Xcode includerà tutte le informazioni sulla versione generate da agvtool nel progetto.

2. Imposta la tua versione e costruisci i numeri

agvtool cerca nella Info.plist dell'applicazione la tua versione e i numeri di build. Li aggiorna se esistono e non fa nulla, altrimenti. Assicurati che le chiavi CFBundleVersion(Versione bundle) e CFBundleShortVersionString(String versioni bundle, short) siano presenti nel tuo Info.plist come mostrato nell'immagine qui sotto:

Chiudere Xcode, quindi accedere alla directory contenente il file di progetto .xcodeproj nell'applicazione Terminale prima di eseguire uno dei seguenti comandi. Il file di progetto .xcodeproj contiene project.pbxproj, utilizzato da agvtool. (Questa è la parte che puoi eseguire in uno script anziché nella riga di comando.)

Aggiornamento del numero di versione

Per aggiornare il numero di versione a una versione specifica, eseguire

xcrun agvtool new-marketing-version <your_specific_version>

Es: aggiorna il numero di versione a 2.0

xcrun agvtool new-marketing-version 2.0

Aggiornamento del numero di build

Per aumentare automaticamente il numero di build, esegui

xcrun agvtool next-version -all

Per impostare il numero di build dell'applicazione su una versione specifica, eseguire

xcrun agvtool new-version -all <your_specific_version>

Es: imposta il numero di build su 2.6.9

xcrun agvtool new-version -all 2.6.9

Bonus:

Per visualizzare il numero di versione corrente, eseguire

xcrun agvtool what-marketing-version

Per visualizzare il numero di build corrente, eseguire

xcrun agvtool what-version

FWIW: questo è quello che sto attualmente utilizzando per aumentare il numero di build solo per build di rilascio (che include l'archiviazione). Funziona bene con Xcode 5.1.

Basta copiare / incollare lo snippet in una fase di creazione dello script Esegui direttamente in 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;

Grazie per la sceneggiatura. Funziona benissimo.

My Info.plist si trova in una sottodirectory con un nome contenente spazi, quindi ho dovuto modificare lo script di esecuzione con virgolette attorno al percorso del plist:

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

e lo script della shell allo stesso modo con le virgolette attorno a tutti i percorsi:

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

La sceneggiatura che sto attualmente usando è molto basata su Alix , sopra. Il mio adattamento, di seguito, aggiunge un controllo per eseguire solo l'incremento automatico in una build di rilascio / archivio.

Senza tale modifica ci saranno conflitti di controllo della versione poiché ogni sviluppatore incrementerà il numero di build alla propria velocità. E il fatto che la storia di Git sarebbe stata inutilmente inquinata con il numero di build che cambiava continuamente.

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

È anche disponibile (in un formato leggermente più facile da copiare e incollare) come git Gub .

Consiglierei l'uso di autorevisione .

Xcode consente un file di intestazione (che può essere generato automaticamente al momento della compilazione e non nel vcs stesso) per fornire valori che verranno espansi nella finestra info.plist al momento della compilazione. È possibile trovare una procedura dettagliata per l'impostazione sul sito Web di autorevision .

Autorevision ha un tipo di output orientato verso questi tipi di file header per aiutare esattamente in queste situazioni.

Un problema con alcune di queste soluzioni è che Launch Services riconosce solo quattro cinque cifre principali nella versione bundle . Ho un progetto con un numero di build che è in migliaia, quindi volevo usare alcune delle cifre meno significative.

Questo script Perl incrementa tutte le Info.plist nel progetto, non solo quella per la destinazione corrente, quindi i numeri di build restano tutti bloccati. Utilizza anche una cifra di patch e due cifre minori, quindi la build 1234 ha la versione 1.23.4. Lo uso come comportamento pre-build, quindi si applica a tutti i progetti che costruisco.

La sceneggiatura è piuttosto bruta, ma funziona per me.

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

È possibile utilizzare il versioning generico di Apple . Fondamentalmente tutto ciò che devi fare è chiamare agvtool next-version -alldalla directory che ospita il tuo file .xcproj. Per maggiori dettagli, consulta l'URL sopra.

Sulla soluzione di Wil Gieseler , ho avuto solo un cambio ho voluto fare. La sua soluzione inserisce il numero di commit git nel numero di build. Utile, ma comunque un po 'doloroso trovare il vero impegno che ha creato quella build. Non mi importava troppo se il numero di build stava aumentando monotonicamente, quindi ho lasciato cadere quel requisito in modo da poter accedere più facilmente al commit che ha generato un dato binario.

A tal fine, ho modificato il suo primo script nel modo seguente:

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

Questo converte la versione breve dell'attuale SHA git in decimale. I personaggi esadecimali non giocano bene con i requisiti del numero di build di Apple, motivo per cui ho dovuto farlo. Per riconvertirlo, avresti semplicemente eseguito qualcosa del genere:

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

in bash, dove si <build number>trova il numero di build ottenuto da un file binario. Quindi, corri git checkout $SHAe basta .

Poiché si tratta di un adattamento della soluzione di Wil Gieseler , come menzionato sopra, avrai anche bisogno del seguente script post-build:

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

che mantiene pulita la tua cronologia git.

Ho provato la procedura modificata e non ha funzionato, perché: -

1. Xcode 4.2.1 modifica la sottodirectory xcuserdata in .xcodeproj

2. git nota la precedente modifica in Project-Info.plist

La seguente modifica fa sì che vengano ignorate e contrassegna solo le modifiche autentiche: -

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

Potresti voler fare questo solo quando archivi (e carica su TF per esempio). Altrimenti il ​​tuo numero di versione potrebbe aumentare molto rapidamente ..

Nello schema (Prodotto / Modifica schema / Archivio / Pre-azioni) è possibile aggiungere uno script che verrà eseguito solo durante l'archiviazione.

Inoltre, potresti voler reimpostare il numero di build ogni volta che aumenti la versione dell'app.

L'ultima cosa, se usi invece l'archivio, puoi disabilitare in sicurezza:

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

Poiché il numero di build verrà incrementato solo quando si archivia ...

EDIT: correggi ciò che ho detto, le pre-azioni in archivio avvengono dopo la compilazione (ma prima dell'archiviazione), quindi il numero di build sarà incrementato per il prossimo archivio ... Ma puoi creare un nuovo schema e aggiungere questa azione nella build (pre azioni) di questo nuovo schema. e utilizzare questo schema quando si desidera creare una nuova build

Uso l'ultima revisione SVN per il numero di build. Se modifichi il file Info.plist nella directory di build, non influenzerai il file Info.plist di origine:

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

Mi sento come se avessi trovato la mia tribù. Tribe, spero che tu sia divertito da VersionX.

Un decennio fa, mentre lavoravo su un'area di lavoro che conteneva oltre 25 progetti Xcode, ho colto l'occasione per automatizzare la versione e creare aggiornamenti delle stringhe a un livello che potrebbe sembrare assurdo, se stai mantenendo solo un progetto o due con aggiornamenti occasionali.

VersionX:

• è a conoscenza del tipo di build (Release / Debug)
• raccoglie informazioni in fase di compilazione dal repository (supporto git incluso, ma può essere personalizzato per hg, svn o qualunque cosa tu usi)
• fornito stringhe di versione di marketing di fantasia facilmente personalizzabili (che avevano molte più variazioni prima che l'App Store imponesse una convenzione) in modo da poter aumentare automaticamente le stringhe che includevano simboli per una "beta" usando ad esempio una convenzione tag git.
• include una classe popolata con variabili di istanza contenenti informazioni sulla versione e sul commit. Questo è utile per popolare il tuo pannello informativo e costruire stringhe di registrazione, rapporti sugli arresti anomali o rapporti sui bug e-mail degli utenti con informazioni precompilate.

E 'stato divertente da fare. Ho imparato un carico in barca sul sistema di compilazione Xcode.

Ecco un esempio del tipo di versione fantasia e stringhe Build che VersionX potrebbe generare automaticamente.

VersioneX 1.0.1 β7 (c5959a3 “Clean”)

Versione di marketing: VersionX 1.0.1 β7 "1.0.1 deriva dal tag per il commit, mentre" Beta 7 "viene generato automaticamente dal conteggio del commit o dal conteggio delle build (ad esempio).

Versione build: (c5959a3 "Clean") Visualizza l'hash di commit breve e informa che la directory di build non ha apportato modifiche senza commit.

VersionX (fonte di GitHub) - un sistema barocco per incrementare automaticamente la versione e costruire stringhe nei progetti Xcode.

La documentazione di VersionX.

Potresti voler dare un'occhiata a un nuovo strumento che ho sviluppato chiamato Xcodebump. Può gestire l'aggiornamento di CFBundleShortVersionString e CFBundleVersion. Come passaggio finale, controllerà anche git e taggerà il commit in modo che corrisponda a quei valori di CFBundle.

Il progetto Xcodebump si trova qui:

https://github.com/markeissler/Xcodebump

Aggiornamento build numbercon il seguente metodo.

$INFO_FILEè il percorso del file plist. Ed $build_numberè un nuovo numero di build per questo edificio.

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

Generalmente, my $build_numberè composta da majore minorparti. Il minorè venuto da informazioni relative al progetto. Quindi descrivo come generare 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}"

Ho 2 strategie per decidere il $build_number .

Prima strategia

Questa strategia utilizza il git tagconteggio per decidere majordi build number. Se ci sono 53tag del progetto, tornerà 53seguendo lo script della shell.

In generale, sta aumentando. E costringerà lo sviluppatore a mettere un tag git prima della pubblicazione.

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

Seconda strategia

Lascia che il sistema CI Jenkins decida la majorparte. Ha una variabile d'ambiente BUILD_NUMBER. Aumenta automaticamente quando si basa sul sistema CI. Queste informazioni sono utili per tracciare la cronologia del progetto sul sistema CI.

major_number=${BUILD_NUMBER}

Ecco una versione aggiornata. Funziona con Xcode 9.3.1, iOS 11.

Fai clic su "Crea fasi" dalla destinazione dell'applicazione, fai clic sull'icona + per aggiungere un nuovo script di esecuzione e, nella casella, incolla questo codice.

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

Vai nel file Info.plist e imposta 'Bundle version' su 1, e 'Bundle version string, short' su 1, dovresti essere impostato.

Costruisci il progetto con Info.plist in vista e dovresti vedere la modifica della versione del pacchetto (numero build).

• Nota che a partire da Xcode 9.3.1, non sarai in grado di vedere queste modifiche dalla scheda generale, ma vedrai le modifiche quando archivi una build e in Info.plist

Ecco la mia soluzione Se sei come me: terminale amichevole, come ruby, come versione semantica, prova questo.

Crea un file chiamato Rakefileche contenga questo:

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
}

Preparare: gem install xcodeproj versionomy

Esegui: rake increment:majoro rake increment:minoro rake increment:tinyquando vuoi.

Trovo più comodo usare la versione automatizzata e i numeri di build usando agvtool .

Prova questo:

1. Configuralo come descritto nella documentazione di Apple collegata sopra.
2. Aggiungi lo script come Pre-azione al Progetto -> Modifica schema ... -> Archivia (o altro se preferisci)
3. Set: fornisce le impostazioni di build da <your_app_target>

Lo script (la prima riga è facoltativa):

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

Facciamolo a modo di Apple. Aumenterà il numero di build dopo ogni build riuscita

Ti guiderò attraverso 5 immagini, basta esaminarle.

1. Seleziona "Modifica schema ..." dal menu a discesa, quando selezioni il nome del tuo progetto situato nella parte destra del pulsante Stop_build_button. Controlla il primo passo

2. Dal menu LeftSide espandi l'opzione 'Build' e seleziona 'Post-actions' Controlla il secondo passaggio

3. Qui è possibile aggiungere i codici (script) desiderati che si desidera eseguire dopo la corretta compilazione del programma. È il luogo in cui dobbiamo aggiungere una piccola quantità di codice per far funzionare perfettamente la nostra automazione. >> 1. seleziona il pulsante 'aggiungi (+)' dall'angolo sinistro per aggiungere un nuovo file di script >> 2. Ora dal menu a discesa seleziona 'Nuova azione script di esecuzione' Controlla il terzo passaggio

4. Ha 3 campi >> 1. la shell è già stata assegnata per te >> 2. ora per 'Fornisci le impostazioni da' Seleziona il nome del tuo progetto. >> 3. C'è un grande campo per aggiungere il tuo script, basta copiare e incollare questo codice lì: Controlla il quarto passaggio

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

5. Dopo aver completato il quarto passaggio, seleziona "Chiudi" per chiudere la finestra e dobbiamo fare l'ultimo passaggio, vai al tuo file "plist.info" nel menu File di progetto e assicurati che la chiave "Versione pacchetto" nella sezione "Chiave" contenga la maggior parte a Valore numerico Controllare il quinto passaggio