Welche iOS-App-Versions- / Build-Nummer (n) MÜSSEN bei der Veröffentlichung im App Store erhöht werden?

Zu den Versions- / Buildfeldern für eine iOS-App gehören:

• "Version" CFBundleShortVersionString (String - iOS, OS X) gibt die Versionsnummer des Bundles an, die eine freigegebene Iteration der App identifiziert. Die Versionsnummer der Version ist eine Zeichenfolge, die aus drei durch Punkte getrennten Ganzzahlen besteht.

• "Build" CFBundleVersion (String - iOS, OS X) gibt die Build-Versionsnummer des Bundles an, die eine Iteration (freigegeben oder unveröffentlicht) des Bundles identifiziert. Die Build-Versionsnummer sollte eine Zeichenfolge sein, die aus drei nicht negativen, durch Perioden getrennten Ganzzahlen besteht, wobei die erste Ganzzahl größer als Null ist. Die Zeichenfolge sollte nur numerische (0-9) und Punktzeichen (.) Enthalten. Führende Nullen werden von jeder Ganzzahl abgeschnitten und ignoriert (dh 1.02.3 entspricht 1.2.3). Dieser Schlüssel ist nicht lokalisierbar.

• "iTunes Connect-Versionsnummer" : Versionsnummer, die Sie beim Erstellen einer neuen Version der App in iTunes Connect angeben.

Meine Frage ist:

Welche Versions- / Build-Nummern müssen erhöht werden, wenn eine neue Version der App auf iTunes Connect hochgeladen und / oder im App Store veröffentlicht wird?

Kann entweder "Version" CFBundleShortVersionStringoder "Build" CFBundleVersionzwischen App-Updates gleich bleiben?

Zusätzliche Punkte für Apple-Quellen oder die genauen Fehlermeldungen, die iTunesConnect beim Hochladen einer ungültigen Versions- / Build-Nummer anzeigt.

Android / Google Play Hinweis:

Die Diskussion, die diese Frage aufwirft, ist, dass die öffentliche "Version" einer Android-App im Google Play Store nicht inkrementiert werden muss und in keiner Weise validiert wird. Die android:versionNamekönnen zwischen Releases, Upgrades, Downgrades oder beliebigen Zeichenfolgen gleich bleiben und nicht als gültige "Versionsnummer" erscheinen.

android:versionName - Ein Zeichenfolgenwert, der die Release-Version des Anwendungscodes darstellt, wie sie den Benutzern angezeigt werden soll.

Der Wert ist eine Zeichenfolge, sodass Sie die Anwendungsversion als <major>.<minor>.<point>Zeichenfolge oder als eine andere Art von absoluter oder relativer Versionskennung beschreiben können.

Unterschied zwischen versionName und versionNumber in Android

Während android:versionCodeerzwungen wird, eine inkrementierende Ganzzahl bei Freigabe zu sein.

Apple-Dokumentation

Wie in der neu akzeptierten Antwort erwähnt , hat Apple kürzlich einen technischen Hinweis veröffentlicht, in dem die Version und das Build-Nummernschema aufgeführt sind:

Apple Technical Note TN2420 - Versionsnummern und Build-Nummern

Apple Technical Note TN2420, Versionsnummern und Build-Nummern

Zusammenfassung:

• Das Paar ( Version, Build number) muss eindeutig sein.
  • Die Reihenfolge ist gültig: (1.0.1, 12) -> (1.0.1, 13) -> (1.0.2, 13) -> (1.0.2, 14) ...
• Version( CFBundleShortVersionString ) muss in aufsteigender Reihenfolge vorliegen.
• Build number( CFBundleVersion ) muss in aufsteigender Reihenfolge vorliegen.

Checkliste für Versionsnummer und Build-Nummer

Hier sind einige Dinge, die Sie überprüfen können, wenn Sie einen neuen Build an den App Store senden. Wenn Sie sicherstellen, dass Ihre Versionsnummer und Build-Nummer richtig eingestellt sind, können Sie vermeiden, dass Ihre App automatisch abgelehnt wird, weil sie nicht ordnungsgemäß konfiguriert wurde.

1. Für jede neue Version Ihrer App müssen Sie eine neue Versionsnummer erfinden. Diese Nummer sollte größer sein als die zuletzt verwendete Versionsnummer. Obwohl Sie möglicherweise viele Builds für eine bestimmte Version Ihrer App bereitstellen, müssen Sie für jede neue Version Ihrer App nur eine neue Versionsnummer verwenden.
2. Sie können Versionsnummern nicht wiederverwenden.
3. Für jeden neuen Build, den Sie einreichen, müssen Sie eine neue Build-Nummer erfinden, deren Wert größer ist als die zuletzt verwendete Build-Nummer (für dieselbe Version).
4. Sie können Build-Nummern in verschiedenen Release-Zügen wiederverwenden, aber Sie können Build-Nummern nicht in demselben Release-Zug wiederverwenden. Für macOS-Apps können Sie Build-Nummern in keinem Release-Zug wiederverwenden.

Basierend auf der Checkliste gilt auch die folgende (Version, Build Number)Reihenfolge.

• Fall: Wiederverwendung Build Numberin verschiedenen Freigabezügen. (HINWEIS: NICHT MacOS App)

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

Das CFBundleShortVersionStringsollte mit der Versionsnummer übereinstimmen, die Sie iTunes Connect geben. Dies ist auch die Versionsnummer, die angezeigt wird, wenn der Benutzer Ihre App im App Store betrachtet.

Die Versionsnummer wird im Store angezeigt und diese Version sollte mit der Versionsnummer übereinstimmen, die Sie später in iTunes Connect eingeben.

Quelle

Das CFBundleVersionwird nicht im App Store angezeigt, sondern von iTunes verwendet, um festzustellen, wann Ihre App aktualisiert wurde.

Wenn Sie die Build-Zeichenfolge aktualisieren, wie unter „Festlegen der Versionsnummer und der Build-Zeichenfolge“ beschrieben, erkennt iTunes, dass sich die Build-Zeichenfolge geändert hat, und synchronisiert das neue iOS App Store-Paket ordnungsgemäß mit Testgeräten.

Quelle

Beantworten Sie Ihre Fragen genauer ...

Welche Versions- / Build-Nummern müssen erhöht werden, wenn eine neue Version der App in den App Store hochgeladen wird?

Beide. Einer wird im App Store angezeigt, der andere wird von iTunes zum Aktualisieren der App verwendet.

Kann entweder CFBundleShortVersionString oder CFBundleVersion zwischen App-Updates gleich bleiben?

Nein. (Meta-Frage, was wäre der Anwendungsfall hier? Wenn Sie die Nutzdaten in irgendeiner Weise bearbeitet haben, ist der Build anders und der Benutzer möchte etwas darüber wissen.) Wenn Sie es versuchen, werden folgende Fehlermeldungen angezeigt:

Oder werden sie mit der vorherigen Nummer verglichen, um sicherzustellen, dass mit der neuen Version der App eine numerisch größere Nummer hochgeladen wird?

Ja. Verwendung des semver.org- Standards.

Sind die CFBundleShortVersionString- und CFBundleVersion-Nummern in irgendeiner Weise miteinander verglichen?

Nein.

CFBundleShortVersionString ist der öffentliche "Name" der Version (Beispiel: "2.5" oder "3.8.1"). Sie müssen es bei jeder Version erhöhen .

CFBundleVersion ist die private Build- Nummer. Es wird im AppStore nicht angezeigt. Sie müssen es bei jedem Upload erhöhen . Wenn Sie eine Binärdatei jemals ablehnen, bevor sie online geht, und eine neue Binärdatei hochladen möchten, hat sie denselben CFBundleShortVersionString , muss jedoch eine höhere CFBundleVersion haben (Beispiel: public "2.5", private "2.5" und dann binär ablehnen und private "2.5.1" erneut hochladen)

Bearbeiten am 16. November 2016:

/ ! \ Die CFBundleVersion- Eigenschaft wird auch (zusammen mit CFBundleName ) in dem User-Agentvon NSURLConnection in Ihrem Code gesendeten Header verwendet.

Beispiel: Wenn CFBundleName ist MyApp und CFBundleVersion ist 2,21, dann ist jede programmatische HTTP - Abfrage direkt von Ihrem Code gesendet mit NSURLConnection den Header einbetten:

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

(Dies gilt nicht für Anforderungen, die automatisch von UIWebView ausgegeben werden.)

CFBundleVersion und CFBundleShortVersionString müssen größer sein als die letzte Versionsnummer der App. Es ist eine gute Praxis, sie gleich zu halten. Sie sollten sie in Ihrer -info.plist finden.

Wenn Sie versuchen, die App im Organizer zu validieren, wird ein Fehler ausgegeben, wenn eine der beiden nicht erhöht wurde. Ist mir letzte Nacht passiert.

Beide CFBundleVersionund CFBundleShortVersionString MÜSSEN erhöht werden, wenn eine neue Version im App Store veröffentlicht wird.

Außerdem muss eine der Zeichenfolgen mit der in iTunes Connect angegebenen Version übereinstimmen.

Diese Frage enthält den obigen Screenshot des Validators des Xcode Organizers, der sich weigert, die App zu validieren, wenn die CFBundleVersionund CFBundleShortVersionStringnicht erhöht wurden.

• Dieses Bundle ist ungültig. Der Wert für Schlüssel CFBundleVersion[1.0] in der Datei Info.plist muss eine höhere Version enthalten als die zuvor hochgeladene Version [1.134].

• Dieses Bundle ist ungültig. Der Wert für Schlüssel CFBundleShortVersionString[1.0] in der Datei Info.plist muss eine höhere Version enthalten als die zuvor hochgeladene Version [1.134].

Der Validator gibt außerdem einen Fehler aus, der beweist, dass eine der Zeichenfolgen mit der in iTunes Connect erstellten Version der App übereinstimmen muss.

• Versionskonflikt. Weder CFBundleVersion ['1.0'] noch CFBundleShortVersionString ['1.0'] in der Info.plist stimmen mit der in iTunes Connect ['1.4'] festgelegten Version der App überein.

Der aktuelle Apple Technical Note TN2420, Versionsnummern und Build-Nummern, sagt (meine Fettdruck):

4. Für iOS-Apps können Sie Build-Nummern in verschiedenen Release-Zügen wiederverwenden, Build-Nummern jedoch nicht innerhalb desselben Release-Zugs wiederverwenden. Für macOS-Apps können Sie Build-Nummern in keinem Release-Zug wiederverwenden .

Leider bedeutet dies, dass Sie eine Build-Nummer, die der Release-Zugnummer unter iOS entspricht, nicht wiederverwenden können, wenn Sie versuchen, denselben Build auf Mac Catalyst zu veröffentlichen.

In meinem Fall habe ich beispielsweise aufgrund einiger früherer Probleme 1.0.2 (4) als Mac Catalyst-App veröffentlicht, die 1.0.2 (1) unter iOS entsprach. Wenn Sie nun versuchen, 1.0.3 (1) für beide Versionen freizugeben, schlägt die Überprüfung der App unter MacOS aufgrund der Build-Nummer fehl, während die Überprüfung unter iOS bestanden wird.

Ich denke, jetzt, da ich routinemäßig dieselbe App auf iOS und MacOS veröffentliche, werde ich Build-Nummern übernehmen, die dem Datum entsprechen, wie 20200111, und mit einem Dezimalpunkt inkrementieren, wenn ich die Build-Nummer innerhalb einer bestimmten Version ändern muss.

Sie müssen beide erhöhen .

Wenn Sie eine neue Version hochladen, müssen Sie in iTunes Connect eine neue Version erstellen, die automatisch höher ist als die vorherigen Versionen. Diese Version in iTunes Connect erwartet eine Binärdatei mit derselben Versionsnummer und CFBundleShortVersionStringmuss daher erhöht werden.

Wenn Sie die Version aktualisieren, aber vergessen, die zu erhöhen CFBundleVersion, wird beim Hochladen ein Fehler angezeigt. Siehe die Antwort und den Screenshot von pkamb.

Einzelheiten zu CFBundleShortVersionStringund CFBundleVersionfinden Sie unter: https://stackoverflow.com/a/31921249/936957

Ich kann bestätigen, nachdem ich es gerade in beide Richtungen versucht habe, dass eine Folge von Versions- und Build-Nummern wie ...

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

... wird für iOS-Apps akzeptiert, für Mac (Catalyst) -Apps wird jedoch der folgende Fehler zurückgegeben:

FEHLER ITMS-90061: "Dieses Bundle ist ungültig. Der Wert für den Schlüssel CFBundleVersion [1] in der Datei Info.plist muss eine höhere Version als die zuvor hochgeladene Version [2] enthalten."

Die Mac-Version und die Build-Nummern müssten wie folgt aussehen ...

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

Für iOS habe ich Build-Nummern als Versionsnummer plus eine vierte Ziffer eingegeben, wie ...

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

... aber das ist auch für Mac Apps nicht erlaubt. Als ich versuchte, meine erste Mac (Catalyst) -App einzureichen, akzeptierte Apple nur eine Build-Nummer mit drei oder weniger Ziffern:

FEHLER ITMS-9000: "Dieses Bundle ist ungültig. Der Wert für den Schlüssel CFBundleVersion [1.0.0.1] in der Datei Info.plist muss eine durch Punkte getrennte Liste von höchstens drei nicht negativen Ganzzahlen sein."

Also habe ich zu einer einzelnen Nummer gewechselt, die für jeden Build inkrementiert und über die Versionsnummern hinweg weiter erhöht wird.

Ich bereite mich auf die Veröffentlichung einer neuen Mac App Store App vor. Verwenden der CalVer- Formatierung von YEAR.release (build).

Ich hochgeladen mehrere Builds: 2020.0 (1), 2020.0 (2)usw. ich endlich abgegeben 2020.0 (8)für App Store Review. Diese Prüfung wurde bestanden und befindet sich im Status " Ausstehende Entwicklerversion" .

Ich wollte vor der Veröffentlichung einige Probleme beheben, daher habe ich demselben Release-Zug einen neuen Build hinzugefügt : 2020.0 (9).

Das führt zu dem Fehler:

App Store Connect-Betriebsfehler

FEHLER ITMS-90062 : "Dieses Bundle ist ungültig. Der Wert für Schlüssel CFBundleShortVersionString[2020.0] in der Datei Info.plist muss eine höhere Version enthalten als die zuvor genehmigte Version [2020.0]. Weitere Informationen finden Sie CFBundleShortVersionStringunter https: // developer.apple.com/documentation/bundleresources/information_property_list/cfbundleshortversionstring "

Das ist ärgerlich, da meine 2020.0Version nie veröffentlicht wurde . Aufgrund der akzeptierten Antwort auf diese Frage hatte ich den Eindruck, dass Sie bis zur Verfügbarkeit der App im App Store weiterhin neue Builds mit derselben Version veröffentlichen können.

• Fehler ITMS-90062: Der Wert für den Schlüssel CFBundleShortVersionString muss eine höhere Version als die zuvor genehmigte Version enthalten
• Application Loader ERROR ITMS-90062: Der Wert für den Schlüssel CFBundleShortVersionString muss eine höhere Version enthalten

Die Lösung scheint zu sein, dass ein "Release-Zug" (gleiche Version + neuer Build) nicht aktualisiert werden kann, wenn der App-Status " Ausstehende Entwickler- Version" lautet . Geben Sie entweder Ihren vorhandenen Build frei und erhöhen Sie dann die Version, oder brechen Sie diese Version in App Store Connect ab, um weitere Uploads für diesen Release-Zug zu ermöglichen.

AFAIK, auf den ersten Blick müssen Sie nur die Build-Nummer erhöhen CFBundleVersion. Das Inkrementieren der kurzen Versionszeichenfolge ist nicht unbedingt erforderlich, obwohl Sie sie wahrscheinlich inkrementieren sollten, da dies dem Benutzer mitteilt, dass die App neu ist. Apple sagt jedoch, dass die Nummerierung den traditionellen Software-Versionskonventionen entsprechen sollte, und iTunes Connect kann sich beschweren, wenn Sie versuchen, eine bereits vorhandene Version erneut hochzuladen.

Lange Rede kurzer Sinn, es mag funktionieren, aber wahrscheinlich nicht.