98

Questo è il mio primo invio di app iOS e non voglio che la mia app venga rifiutata.

Questo è da Apple Docs:

CFBundleVersion (String - iOS, OS X) specifica il numero di versione build del bundle, che identifica un'iterazione (rilasciata o non rilasciata) del bundle. Il numero di versione della build deve essere una stringa composta da tre numeri interi non negativi separati da punti con il primo numero intero maggiore di zero. La stringa deve contenere solo caratteri numerici (0-9) e punto (.). Gli zeri iniziali vengono troncati da ogni numero intero e verranno ignorati (ovvero 1.02.3 è equivalente a 1.2.3). Questa chiave non è localizzabile.

CFBundleShortVersionString (String - iOS, OS X) specifica il numero di versione di rilascio del bundle, che identifica un'iterazione rilasciata dell'app. Il numero di versione del rilascio è una stringa composta da tre numeri interi separati da punti. Il primo numero intero rappresenta le revisioni principali dell'app, ad esempio le revisioni che implementano nuove funzionalità o modifiche importanti. Il secondo numero intero denota revisioni che implementano caratteristiche meno prominenti. Il terzo numero intero rappresenta le versioni di manutenzione.

Il valore di questa chiave è diverso dal valore di "CFBundleVersion", che identifica un'iterazione (rilasciata o non rilasciata) dell'app. Questa chiave può essere localizzata includendola nei file InfoPlist.strings.

Ma sembra un po 'strano. La mia interpretazione per questo è mettere entrambi i valori uguali, ovvero:

CFBundleVersion: 1.0.0
CFBundleShortVersionString: 1.0.0

Qualcuno può confermare al 100% che è quello che dovrei mettere?

ios

— Bbx
fonte

1

In base a ciò, CFBundleShortVersionString può essere localizzato. Ma se deve essere tre numeri interi separati da punti, quale localizzazione è possibile?

— Rick

@ Rick, suppongo che questo significhi che puoi convertirlo per lingue che in realtà hanno numeri diversi, come l'arabo?

— shiser

@shiser Giusto per essere pedanti, i "numeri arabi" sono in realtà i numeri che usiamo nel mondo occidentale e anche in molti altri posti. Ma capisco cosa intendi, e ci sono alcune parti del mondo arabo che non usano "numeri arabi". en.wikipedia.org/wiki/Arabic_numerals

— RenniePet

1

Un'altra risposta qui. stackoverflow.com/q/21125159/419348

— AechoLiu

77

Pensala in questo modo: la "versione breve" ( CFBundleShortVersionString) è il numero della versione pubblica. La "versione" ( CFBundleVersion) è più un numero di versione interno che potrebbe cambiare molto più frequentemente rispetto alla "versione breve" pubblica. Personalmente uso lo stesso per entrambi ma molte persone aggiornano la "versione" su ogni build. In entrambi i casi, in genere aggiorni la "versione breve" quando rilasci ad Apple. La frequenza con cui aggiorni la "versione" dipende da te e dalle tue esigenze.

— rmaddy
fonte

14

Tieni presente che la versione del bundle (CFBundleVersion) deve superare numericamente la versione del bundle della tua app precedente o riceverà un errore durante l'invio all'App Store. Vedi stackoverflow.com/questions/4933093/… .

— Phil

3

Simile a quello che dice Phil sopra, al giorno d'oggi, se invii nuovamente una build fallita (non approvata da App Store), sembra che tu debba urtare CFBundleVersion su ogni invio ora , quindi probabilmente questi numeri divergeranno a meno che tu non sia sempre perfetto, o non ti dispiace urtare la tua versione pubblica (CFBundleShortVersionString) # su qualsiasi modifica necessaria per l'invio corretto all'App Store.

— come il

106

CFBundleShortVersionString ti fornisce la versione della tua app. Di solito viene incrementato ogni volta che pubblichi la tua app nell'App Store. Questa è la versione visibile nella sezione "Versione" della pagina App Store della tua applicazione.

CFBundleVersion fornisce il numero di build utilizzato per lo sviluppo e il test, ovvero per scopi "tecnici". L'utente finale è raramente interessato al numero di build, ma durante lo sviluppo potrebbe essere necessario sapere cosa viene sviluppato e risolto in ogni build. Questo è tipicamente incrementato ad ogni iterazione del rilascio interno. E puoi utilizzare strumenti di integrazione continua come Jenkins per aumentare automaticamente il numero di build su ogni build.

I due numeri non dipendono l'uno dall'altro ma è bene mantenerli paralleli per evitare confusione. Tieni presente che una volta che la tua app ha superato la revisione dell'App Store, devi aumentare il numero di build come hanno dichiarato Phil e likeTheSky, indipendentemente dal fatto che tu la pubblichi o meno.

Caso d'uso: diciamo che hai una build ben collaudata, pronta per l'invio. Il numero di versione è 1.0.0 e il numero di build è 1.0.0.32 . Dopo aver inviato la tua app, devi aggiornare la versione come 1.0.1 e il numero di build come 1.0.1.0 .

— Yunus Nedim Mehel
fonte

4

Quindi, è sicuro ignorare quel bit nei documenti (citato nella domanda) su CFBundleVersion come valori separati da " tre " punti?

— big_m

Penso che dipenda da te. Se non pubblichi frequentemente una versione o se non devi seguire rigorosamente le correzioni di bug attraverso frequenti cicli di test; potresti anche usare 3 cifre per entrambi.

— Yunus Nedim Mehel

quindi CFBundleVersion può essere 0 per una build di app store? Apple lo rifiuterà?

— kraftydevil

3

Sì, puoi utilizzare valori diversi da 3 numeri con punteggiatura. Ho utilizzato un valore di data e ora come 201606070620in un'app iOS di spedizione.

— Basil Bourque

3

@BasilBourque, se non segui le linee guida, potresti incorrere in un problema se utilizzi gli acquisti in-app. Vedi nota tecnica 2413

— DanSkeel

16

La risposta di rmaddy è corretta. Aggiungerò altri due pensieri.

Terzo numero di versione

Fai attenzione al terzo numero di versione, specificato sul sito web iTunesConnect come parte della definizione della tua app. Se quel numero è diverso dai due in Xcode, Apple ti dà un avviso. È possibile ignorare l'avvertenza, poiché non è uno spettacolo (non un "errore").

Data-ora come versione

Inoltre, non è necessario utilizzare tre numeri con punteggiatura. Ciò potrebbe avere senso per alcune app, dove tradizionalmente i cambiamenti nel primo numero indicavano una sorta di cambiamento radicale che di solito influisce sulla compatibilità.

Per altre app potresti voler utilizzare semplicemente un valore di data e ora nello stile di formato standard ISO 8601 (AAAAMMGGHHMM). Ad esempio 201606070620,. Quell'ordine di anno-mese-data-ora-minuto restituisce un numero sempre crescente, sempre della stessa lunghezza a causa del riempimento zero, che se ordinato alfabeticamente è anche cronologico.

Ho utilizzato con successo questo stile di numeri di versione su un'app iOS di spedizione funzionante in iOS 7, 8 e 9.

Puoi persino automatizzare la generazione di questo valore. In del progetto Target> Build Phases> Run ScriptPannello:

Specificare nel Shellcampo:/bin/sh
Incolla il seguente script di 5 righe visto di seguito.
(facoltativo) Seleziona la Show environment variables in build logcasella di controllo.
Deseleziona la Run script only when installingcasella di controllo.

Ogni volta che esegui una build , viene acquisita la data e l'ora corrente nel fuso orario UTC . Il -uflag nello script utilizza UTC anziché il fuso orario predefinito corrente. Generalmente è meglio per programmatori e amministratori di sistema utilizzare e pensare in UTC piuttosto che in fusi orari locali.

#!/bin/bash
buildNumber=$(date -u "+%Y%m%d%H%M")
/usr/libexec/PlistBuddy -c "Set :CFBundleShortVersionString $buildNumber" "$INFOPLIST_FILE"  # Version number
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildNumber" "$INFOPLIST_FILE"  # Build number
echo "DateTime for app version number: $buildNumber"

Oppure fai un ibrido, con un convenzionale 1.2.3per il numero di versione e una data-ora come numero di build. Per fare l'ibrido, commenta semplicemente la CFBundleShortVersionStringlinea con una #davanti.

— Basil Bourque
fonte

8

Lo schema più sensato per me è quello di utilizzare il numero di versione (es. CFBundleShortVersionString) Per il numero di versione effettivo, quindi utilizzare il numero di build (es. CFBundleVersion) Per rappresentare la presentazione all'App Store. Quindi, a meno che non ci siano problemi e quindi si invii nuovamente, questo numero è sempre 1. Per una nuova versione, resetto a 1 se la precedente ha avuto problemi nei test di TestFlight o in revisione.

I numeri di build forniscono un modo per nominare ciascuno degli invii forniti per una particolare release. Come descritto nelle definizioni precedenti, la raccolta di tutte le build che fornisci per una particolare versione della tua app è chiamata "release train" di quella versione. Per le app iOS, i numeri di build devono essere univoci all'interno di ogni release train, ma non è necessario che siano univoci nei diversi release train [enfasi mia]. Vale a dire, per le app iOS puoi utilizzare di nuovo gli stessi numeri di build in diversi release train, se lo desideri.

Dalla nota tecnica TN2420: numeri di versione e numeri di build .

— plindberg
fonte

1

Bello vedere una risposta che fornisce un riferimento ufficiale che conferma le interpretazioni presentate in altre risposte in questa pagina.

— user2067021

6

Uso CFBundleVersion per indicare la build interna per CFBundleShortVersionString . Uso il volo di prova per inviare build per i miei tester, quindi la differenza tra loro è stata estremamente utile.

I documenti Apple dicono che CFBundleVersion "dovrebbe essere una stringa composta da 3 numeri interi separati da punti non negativi" Ma in realtà può essere PIÙ DI 3 parti (come mostra la risposta sopra). Lo uso per indicare la mia build di sviluppo, diciamo che il mio CFBundleShortVersionString è 1.0.0, posso usare 1.0.0.11 per CFBundleVersion per indicare che è la mia undicesima build per la versione 1.0.0

Ogni CFBundleVersion inviata all'app store dovrebbe essere più grande di prima o riceverai ERROR ITMS-90478 : "Versione non valida. La build con la versione" xxx "non può essere importata perché una versione successiva è stata chiusa per l'invio di nuove build. Scegli un numero di versione diverso. "

CFBundleShortVersionString può avere solo 3 parti o riceverai ERRORE ITMS-90060: il valore per la chiave CFBundleShortVersionString 'xxx' nel file Info.plist deve essere un elenco separato da punti di massimo tre numeri interi non negativi. "

Il terzo numero menzionato da Basil Bourque, ovvero il numero di versione mostrato su iTunesConnect, è dove le cose potrebbero complicarsi.

Uso un numero iTunesConnect diverso da CFBundleShortVersionString perché quando ho inviato la mia app per la prima volta all'app store abbiamo già molti round di versioni interne. Quindi ho usato 1.0 per il numero iTunesConnect e 5.x per CFBundleShortVersionString. Nella prossima versione dell'app store ho fornito una funzione per verificare se c'è una versione più recente nell'app store e mi sono reso conto di avere problemi ora perché posso ottenere solo il numero iTunesConnect (utilizzando http://itunes.apple.com/lookup?bundleId=) quindi devo fare qualche calcolo prima di confrontarlo con numero CFBundleShortVersionString.

Ho provato a risolverlo utilizzando il numero iTunesConnect come CFBundleShortVersionString, ma ho ricevuto l'errore, ERRORE ITMS-90062 : "Questo pacchetto non è valido. Il valore per la chiave CFBundleShortVersionString [xxx] nel file Info.plist deve contenere una versione superiore a quella della versione precedentemente approvata [xxx]. "

Quindi suggerirò di renderli sempre uguali.

— Qiulang
fonte

5

Qualcosa che non ho mai visto discusso da nessuna parte è qual è il numero massimo per ogni campo in un CFBundleVersion?

Impostando CFBundleVersion in un'app su 1.1.1 e osservando il valore esadecimale per la versione in "lsregister -dump", ho determinato che il valore massimo per il primo campo è (2 ^ 22) -1 o 4194303 e il valore massimo i valori per il secondo e il terzo campo sono (2 ^ 21) -1 o 2097151.

I 3 campi aggiungono fino a 64 bit.

Ciò ha implicazioni per quelli di noi che utilizzano CFBundleVersion in base a data e ora.

Stavo impostando il primo campo su AAAAMMGG. Questo è sempre maggiore del numero massimo di versioni consentite e portava a risultati imprevedibili, per non dire altro, quando Launch Services decideva quale versione di un'app eseguire quando erano installate più versioni e utilizzava qualcosa come 'open -a Appname 'dalla riga di comando.

Per favore diffondilo ampiamente. Sono sicuro che molte persone si stanno liberando di questo.

— Dave Evans
fonte

Ricordi cosa si fa se viene aggiunto un quarto campo (1.1.1.20191201) e cosa si finisce invece per usare? Vorrei davvero che Apple usasse lo stesso valore numerico che Android ha usato qui. PS grazie per aver cercato questo!

— tuta spaziale

Credo che la restrizione sia documentata qui ed è un po 'più restrittiva di quanto qui menzionato.

— saagarjha

3

A partire da ora, la documentazione Apple per gliCFBundleVersion stati [enfasi mia]:

La versione build che identifica un'iterazione del bundle.

...

Questa chiave è una stringa leggibile dalla macchina composta da uno a tre numeri interi separati da punti , come 10.14.1. La stringa può contenere solo caratteri numerici (0-9) e punti.

...

È possibile includere più numeri interi ma il sistema li ignora.

Per CFBundleShortVersionString[enfasi mia]:

La versione o il numero di versione del pacchetto.

...

Questa chiave è una stringa visibile all'utente per la versione del bundle. Il formato richiesto è tre numeri interi separati da punti , ad esempio 10.14.1. La stringa può contenere solo caratteri numerici (0-9) e punti.

Suggerirei di aumentare automaticamente CFBundleVersionper ogni build (o ogni versione di TestFlight) e di reimpostarlo a 0 ogni volta che si modifica CFBundleShortVersionString.

È necessario pianificare in modo esplicito o ideare un mezzo coerente per aggiornare la versione visibile all'utente in CFBundleShortVersionString.

— Kenny Evitt
fonte

Quali valori devo usare per CFBundleVersion e CFBundleShortVersionString?

Terzo numero di versione

Data-ora come versione