Quale versione / numero di build dell'app iOS DEVE essere incrementato al rilascio dell'App Store?

I campi versione / build per un'app iOS includono:

• "Versione" 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.

• "Build" 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.

• "Numero versione iTunes Connect" : numero di versione specificato durante la creazione di una nuova versione dell'app su iTunes Connect.

La mia domanda è:

Quali numeri di versione / build devono essere incrementati quando una nuova versione dell'app viene caricata su iTunes Connect e / o rilasciata su App Store?

La "versione" CFBundleShortVersionStringo la "build" possono CFBundleVersionrimanere le stesse tra gli aggiornamenti dell'app?

Punti extra per le fonti Apple o gli esatti messaggi di errore visualizzati da iTunesConnect al caricamento di una versione / numero di build non valido.

Nota per Android / Google Play:

La discussione che fa sorgere questa domanda è che la "versione" pubblica di un'app Android nel Google Play Store non ha bisogno di essere incrementata e non è in alcun modo convalidata. Il android:versionNamepossono rimanere le stesse tra le release, aggiornamento, downgrade, o essere qualsiasi stringa casuale piuttosto che qualcosa che sembra essere un "numero di versione" valido.

android:versionName - Un valore stringa che rappresenta la versione di rilascio del codice dell'applicazione, come dovrebbe essere mostrato agli utenti.

Il valore è una stringa in modo che sia possibile descrivere la versione dell'applicazione come <major>.<minor>.<point>stringa o come qualsiasi altro tipo di identificatore di versione assoluto o relativo.

Differenza tra versionName e versionNumber in Android

Considerando che il android:versionCodeè forzato per essere un numero intero incrementale al rilascio.

Documentazione Apple

Come notato nella risposta recentemente accettata , Apple ha recentemente pubblicato una nota tecnica che descrive in dettaglio la loro versione e lo schema del numero di build:

Nota tecnica Apple TN2420 - Numeri di versione e numeri di build

Nota tecnica Apple TN2420, numeri di versione e numeri di build

Sommario:

• La coppia ( Version, Build number) deve essere unica.
  • La sequenza è valida: (1.0.1, 12) -> (1.0.1, 13) -> (1.0.2, 13) -> (1.0.2, 14) ...
• Version( CFBundleShortVersionString ) deve essere in ordine sequenziale crescente.
• Build number( CFBundleVersion ) deve essere in ordine sequenziale crescente.

Elenco di controllo del numero di versione e del numero di build

Ecco alcune cose che puoi controllare quando invii una nuova build all'App Store. Assicurarsi di avere impostato correttamente il numero di versione e il numero di build ti aiuterà evitando che la tua app venga rifiutata automaticamente per averli configurati in modo errato.

1. Per ogni nuova versione della tua app, devi inventare un nuovo numero di versione. Questo numero dovrebbe essere un valore maggiore dell'ultimo numero di versione utilizzato. Sebbene tu possa fornire molte build per una particolare versione della tua app, devi solo utilizzare un nuovo numero di versione per ogni nuova versione della tua app.
2. Non è possibile riutilizzare i numeri di versione.
3. Per ogni nuova build che invii, dovrai inventare un nuovo numero build il cui valore sia maggiore dell'ultimo numero build che hai usato (per quella stessa versione).
4. Puoi riutilizzare i numeri build in diversi release train, ma non puoi riutilizzare i numeri build all'interno dello stesso release train. Per le app macOS, non puoi riutilizzare i numeri di build in nessun treno di rilascio.

In base alla lista di controllo, (Version, Build Number)è valida anche la seguente sequenza.

• Caso: riutilizzo Build Numberin diversi release train. (NOTA: NON app macOS)

  (1.0.0, 1) -> (1.0.0, 2) -> ... -> (1.0.0, 11) -> ( 1.0.1 , 1 ) -> (1.0.1, 2)

Il CFBundleShortVersionStringdeve corrispondere al numero di versione si dà iTunes Connect. È anche il numero di versione che appare quando l'utente guarda la tua app nell'App Store.

Il numero di versione è mostrato nello store e quella versione dovrebbe corrispondere al numero di versione che inserisci successivamente in iTunes Connect.

fonte

Il CFBundleVersionnon viene visualizzato nell'App Store, ma viene utilizzato da iTunes per determinare quando la tua app è stata aggiornata.

Se aggiorni la stringa di build, come descritto in "Impostazione del numero di versione e della stringa di build", iTunes riconosce che la stringa di build è cambiata e sincronizza correttamente il nuovo pacchetto iOS App Store per testare i dispositivi.

fonte

Rispondere alle tue domande in modo più specifico ...

Quali numeri di versione / build devono essere incrementati quando una nuova versione dell'app viene caricata nell'app store?

Tutti e due. Uno viene visualizzato nell'App Store, l'altro viene utilizzato da iTunes per aggiornare l'App.

CFBundleShortVersionString o CFBundleVersion possono rimanere gli stessi tra gli aggiornamenti dell'app?

No. (Meta domanda, quale sarebbe il caso d'uso qui? Se hai modificato il payload in qualche modo, la build sarà diversa e l'utente vorrà saperlo). Se ci provi, vedrai messaggi di errore come di seguito:

Oppure vengono confrontati con il rispettivo numero precedente per garantire che un numero numericamente maggiore venga caricato con la nuova versione dell'app?

Sì. Utilizzando semver.org standard .

I numeri CFBundleShortVersionString e CFBundleVersion sono in qualche modo confrontati tra loro?

No.

CFBundleShortVersionString è il "nome" pubblico della versione (esempio: "2.5" o "3.8.1"). È necessario aumentarlo ad ogni rilascio .

CFBundleVersion è il numero di build privato . Non si vede su AppStore. Devi aumentarlo ad ogni caricamento . Significa che se rifiuti un file binario prima che sia online e desideri caricarne uno nuovo, avrà lo stesso CFBundleShortVersionString ma deve avere un CFBundleVersion più alto (esempio: public "2.5", private "2.5" e poi rifiuto binario e ricarica "2.5.1" privato)

Modifica il 16 novembre 2016:

/ ! \ La proprietà CFBundleVersion viene utilizzata anche (insieme a CFBundleName ) User-Agentnell'intestazione inviata da NSURLConnection nel codice.

Esempio: se CFBundleName è MyApp e CFBundleVersion è 2.21, qualsiasi query HTTP programmatica inviata direttamente dal tuo codice utilizzando NSURLConnection incorporerà l'intestazione:

User-Agent: MyApp/2.21 CFNetwork/... Darwin/...

(Questo non si applica alle richieste emesse automaticamente da UIWebView).

CFBundleVersion e CFBundleShortVersionString devono essere maggiori dell'ultimo numero di versione dell'app. È una buona pratica mantenerli uguali. Dovresti trovarli nel tuo -info.plist.

Quando si tenta di convalidare l'app nell'organizer, verrà generato un errore se uno dei due non è stato incrementato. Mi è successo la scorsa notte.

Entrambi CFBundleVersione CFBundleShortVersionString MUST essere incrementati quando si rilascia una nuova versione nell'App Store.

Inoltre, una delle stringhe deve corrispondere alla versione specificata in iTunes Connect.

Questa domanda include lo screenshot sopra del Validator di Xcode Organizer che rifiuta di convalidare l'app quando CFBundleVersione CFBundleShortVersionStringnon sono stati incrementati.

• Questo pacchetto non è valido. Il valore per la chiave CFBundleVersion[1.0] nel file Info.plist deve contenere una versione superiore a quella della versione caricata in precedenza [1.134].

• Questo pacchetto non è valido. Il valore per la chiave CFBundleShortVersionString[1.0] nel file Info.plist deve contenere una versione superiore a quella della versione caricata in precedenza [1.134].

Il validatore genera anche un errore dimostrando che una delle stringhe deve corrispondere alla versione dell'app creata su iTunes Connect.

• Versione non corrispondente. Né CFBundleVersion ['1.0'] né CFBundleShortVersionString ['1.0'] in Info.plist corrispondono alla versione dell'app impostata in iTunes Connect ['1.4'].

L'attuale nota tecnica Apple TN2420, numeri di versione e numeri di build dice (il mio in grassetto):

4. Per le app iOS puoi riutilizzare i numeri di build in diversi release train, ma non puoi riutilizzare i numeri build all'interno dello stesso release train. Per le app macOS, non puoi riutilizzare i numeri di build in nessun treno di rilascio .

Sfortunatamente, questo significa che non puoi riutilizzare un numero di build che tiene traccia del numero del treno di rilascio su iOS quando stai tentando di rilasciare la stessa build su Mac Catalyst.

Nel mio caso, ad esempio, a causa di alcuni problemi precedenti, ho finito per rilasciare 1.0.2 (4) come app Mac Catalyst che corrispondeva a 1.0.2 (1) su iOS. Ora, quando si tenta di rilasciare 1.0.3 (1) su entrambi, l'app non supera la verifica su MacOS a causa del numero di build, mentre supera la verifica su iOS.

Immagino che ora che sto rilasciando la stessa app sia su iOS che su MacOS regolarmente, adotterò numeri di build che corrispondono alla data, come 20200111 e incrementerò con un punto decimale se ho bisogno di cambiare il numero di build all'interno di una data versione.

Devi incrementare entrambi .

Quando carichi una nuova versione, dovrai creare una nuova versione su iTunes Connect, che sarà automaticamente superiore alle versioni precedenti. Questa versione su iTunes Connect si aspetterà un binario con lo stesso numero di versione, quindi CFBundleShortVersionStringdeve essere incrementata.

Se aggiorni la versione ma dimentichi di incrementare la CFBundleVersion, riscontrerai un errore durante il caricamento. Vedi la risposta e lo screenshot di pkamb.

Per i dettagli su CFBundleShortVersionStringe CFBundleVersion, vedere: https://stackoverflow.com/a/31921249/936957

Posso confermare, dopo averlo provato in entrambi i modi, che una sequenza di numeri di versione e build come ...

1.0.0 (1)
1.0.1 (1)
1.0.2 (1)

... sarà accettato per le app iOS, ma per le app Mac (Catalyst) restituisce questo errore:

ERRORE ITMS-90061: "Questo pacchetto non è valido. Il valore per la chiave CFBundleVersion [1] nel file Info.plist deve contenere una versione successiva a quella della versione caricata in precedenza [2]."

La versione per Mac e i numeri di build dovrebbero andare come ...

1.0.0 (1)
1.0.1 (2)
1.0.2 (3)

Per iOS, inserivo i numeri di build come numero di versione più una quarta cifra, come ...

1.0.0 (1.0.0.1)
1.0.1 (1.0.1.1)
1.0.2 (1.0.2.1)

... ma questo non è consentito nemmeno per le app Mac. Quando ho provato a inviare la mia prima app per Mac (Catalyst), Apple accettava solo un numero di build con tre o meno cifre:

ERRORE ITMS-9000: "Questo pacchetto non è valido. Il valore per la chiave CFBundleVersion [1.0.0.1] nel file Info.plist deve essere un elenco separato da punti di massimo tre numeri interi non negativi."

Quindi sono passato a un singolo numero che aumenta per ogni build e continua ad aumentare attraverso i numeri di versione.

Mi sto preparando a rilasciare una nuova app per Mac App Store. Utilizzando la formattazione CalVer di YEAR.release (build).

Ho caricato diverse build: 2020.0 (1), 2020.0 (2), ecc ho finalmente presentato 2020.0 (8)in App Store Review. Che ha superato la revisione ed è nello stato Pending Developer Release .

Ho voluto risolvere un paio di cose prima del rilascio, così ho aggiunto una nuova build per lo stesso treno di rilascio: 2020.0 (9).

Ciò si traduce nell'errore:

Errore di operazione di connessione all'App Store

ERRORE ITMS-90062 : "Questo pacchetto non è valido. Il valore per la chiaveCFBundleShortVersionString [2020,0] nel file Info.plist deve contenere una versione superiore a quello della versione precedentemente approvato [2020,0] Si prega di trovare maggiori informazioni su. CFBundleShortVersionStringA https: // developer.apple.com/documentation/bundleresources/information_property_list/cfbundleshortversionstring "

che è fastidioso come il mio 2020.0 versione non è mai stata effettivamente rilasciata . Dalla risposta accettata a questa domanda avevo l'impressione che fino a quando l'app non fosse disponibile su App Store si potesse continuare a rilasciare nuove build con la stessa versione.

• Errore ITMS-90062: il valore per la chiave CFBundleShortVersionString deve contenere una versione superiore a quella della versione precedentemente approvata
• Application Loader ERROR ITMS-90062: il valore per la chiave CFBundleShortVersionString deve contenere una versione successiva

La soluzione sembra essere che un "treno di rilascio" (Stessa versione + Nuova build) non può essere aggiornato se lo stato dell'app è Pending Developer Release . Rilascia la build esistente e quindi aumenta la versione oppure Annulla questa versione in App Store Connect per consentire ulteriori caricamenti per questo treno di rilascio.

AFAIK, fuori dalla mia testa, devi solo aumentare il numero di build CFBundleVersion . L'incremento della stringa della versione breve non è necessariamente necessario, anche se probabilmente dovresti incrementarlo, poiché indica all'utente che l'app è nuova. Apple afferma che la numerazione dovrebbe seguire le tradizionali convenzioni di versione del software, tuttavia, e iTunes Connect potrebbe lamentarsi se provi a ricaricare una versione già esistente.

Per farla breve, potrebbe funzionare, ma probabilmente no.