Version vs. Build in Xcode

Question

Ich habe eine Anwendung, die ich mit Xcode 3 entwickelt habe und seit kurzem mit Xcode 4 bearbeite. In der Zielzusammenfassung habe ich das iOS-Anwendungszielformular mit folgenden Feldern: Bezeichner, Version, Build, Geräte und Bereitstellungsziel. Das Versionsfeld ist leer und das Build-Feld ist 3.4.0 (was der Version der App entspricht, als ich noch mit Xcode 3 gearbeitet habe).

Meine Fragen sind:

1. Was ist der Unterschied zwischen den Feldern Version und Build?

2. Warum war das Versionsfeld leer, nachdem ich auf Xcode 4 aktualisiert hatte?

Answer 1

Apple hat die Felder sozusagen neu angeordnet/umgeleitet.

Wenn Sie in Zukunft auf der Registerkarte "Info" für Ihr Anwendungsziel nachsehen, sollten Sie "Bundle versions string, short" als Version (z. B. 3.4.0) und "Bundle version" als Build (z. B. 500 oder 1A500) verwenden. Wenn Sie diese beiden Angaben nicht sehen, können Sie sie hinzufügen. Diese werden dann den entsprechenden Textfeldern "Version" und "Build" auf der Registerkarte "Zusammenfassung" zugeordnet; es handelt sich um dieselben Werte.

Wenn Sie auf der Registerkarte Info mit der rechten Maustaste klicken und Raw Keys/Werte anzeigen werden Sie sehen, dass die tatsächlichen Namen lauten CFBundleShortVersionString (Version) und CFBundleVersion (Bauen).

Die Version wird in der Regel so verwendet, wie Sie sie mit Xcode 3 verwendet zu haben scheinen. Ich bin nicht sicher, auf welcher Ebene Sie über die Version / Build Unterschied fragen, so werde ich es philosophisch zu beantworten.

Es gibt alle möglichen Schemata, aber ein beliebtes ist:

{HauptVersion}.{MinorVersion}.{Revision}

• Hauptversion - Größere Änderungen, Umgestaltungen und Funktionalitäten Änderungen
• Kleinere Version - Kleinere Verbesserungen, Ergänzungen der Funktionalität
• Revision - Eine Patch-Nummer für Fehlerbehebungen

Dann wird das Build separat verwendet, um die Gesamtzahl der Builds für eine Version oder für die gesamte Produktlebensdauer anzugeben.

Viele Entwickler beginnen die Build-Nummer bei 0, und jedes Mal, wenn sie einen Build erstellen, erhöhen sie die Nummer um eins, und zwar für immer. In meinen Projekten habe ich ein Skript, das die Build-Nummer bei jedem Build automatisch erhöht. Anweisungen dazu finden Sie weiter unten.

• Release 1.0.0 könnte Build 542 sein. Es brauchte 542 Builds, um zu einer Version 1.0.0 zu kommen.
• Release 1.0.1 könnte Build 578 sein.
• Release 1.1.0 könnte Build 694 sein.
• Release 2.0.0 könnte Build 949 sein.

Andere Entwickler, einschließlich Apple, haben eine Build-Nummer, die sich aus einer Hauptversion + Nebenversion + Anzahl der Builds für die Version zusammensetzt. Dies sind die tatsächlichen Versionsnummern der Software, im Gegensatz zu den für das Marketing verwendeten Werten.

Wenn Sie zu Xcode Menü > Über Xcode sehen Sie die Versions- und Build-Nummern. Wenn Sie auf die Mehr Info... werden Sie eine Reihe von verschiedenen Versionen sehen. Da die Mehr Info... Schaltfläche in Xcode 5 entfernt wurde, sind diese Informationen auch in der Software > Entwickler Abschnitt der System-Informationen App, verfügbar durch Öffnen von Apfel Menü > Über diesen Mac > Systembericht... .

Zum Beispiel, Xcode 4.2 (4C139). Marketingversion 4.2 ist Build-Hauptversion 4, Build-Nebenversion C und Build-Nummer 139. Die nächste Version (vermutlich 4.3) wird wahrscheinlich Build-Version 4D sein, und die Build-Nummer wird bei 0 beginnen und von dort aus hochgezählt.

Die Versions-/Build-Nummern des iPhone-Simulators sind die gleichen wie die des iPhones, Macs usw.

• 3.2: (7W367a)
• 4.0: (8A400)
• 4.1: (8B117)
• 4.2: (8C134)
• 4.3: (8H7)

Update : Hier sind die Schritte, um ein Skript zu erstellen, das jedes Mal ausgeführt wird, wenn Sie Ihre App in Xcode erstellen, um die Build-Nummer zu lesen, zu erhöhen und sie in die App zurückzuschreiben. {App}-Info.plist Datei. Es gibt optionale, zusätzliche Schritte, wenn Sie Ihre Versions-/Build-Nummern in Ihre Datenbank schreiben wollen. Settings.bundle/Root*.plist Datei(en).

Dies ist eine Erweiterung des Anleitungsartikels aquí .

In Xcode 4.2 - 5.0:

1. Laden Sie Ihr Xcode-Projekt.

2. Klicken Sie im linken Fensterbereich auf Ihr Projekt ganz oben in der Hierarchie. Dadurch wird der Editor für die Projekteinstellungen geladen.

3. Klicken Sie auf der linken Seite des mittleren Fensterbereichs auf Ihre Anwendung unter dem Menüpunkt TARGETS Überschrift. Sie müssen diese Einstellung für jedes Projektziel konfigurieren.

4. Wählen Sie die Bauphasen tab.

5. • Klicken Sie in Xcode 4 unten rechts auf die Schaltfläche Bauphase hinzufügen Taste und wählen Sie Skript ausführen hinzufügen .
   • Wählen Sie in Xcode 5 Herausgeber Menü > Bauphase hinzufügen > Skriptausführungsphase hinzufügen .

6. Ziehen Sie per Drag-and-Drop die neue Skript ausführen Phase zu verschieben, um sie kurz vor die Ressourcen des Kopierpakets Phase (wenn die Datei app-info.plist mit Ihrer Anwendung gebündelt wird).

7. In der neuen Skript ausführen Phase, einstellen Shell : /bin/bash .

8. Kopieren Sie den folgenden Text und fügen Sie ihn in den Skriptbereich für ganzzahlige Build-Nummern ein:

   buildNumber=$(/usr/libexec/PlistBuddy -c "Print CFBundleVersion" "$INFOPLIST_FILE")
   buildNumber=$(($buildNumber + 1))
   /usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildNumber" "$INFOPLIST_FILE"

   Wie @Bdebeez feststellte, ist die Generisches Versionierungswerkzeug von Apple ( agvtool ) ist ebenfalls verfügbar. Wenn Sie es stattdessen verwenden möchten, müssen Sie zunächst ein paar Dinge ändern:

   • Wählen Sie die Build-Einstellungen tab.
   • Im Rahmen der Versionierung Abschnitt, setzen Sie die Aktuelle Projektversion auf die ursprüngliche Build-Nummer, die Sie verwenden möchten, z. B., 1 .
   • Zurück auf der Bauphasen und ziehen Sie per Drag-and-Drop Ihre Skript ausführen Phase nach der Ressourcen des Kopierpakets Phase, um eine Race Condition zu vermeiden, wenn Sie versuchen, die Quelldatei, die Ihre Build-Nummer enthält, sowohl zu erstellen als auch zu aktualisieren.

   Beachten Sie, dass mit dem agvtool Methode können Sie immer noch regelmäßig fehlgeschlagene/abgebrochene Builds ohne Fehler erhalten. Aus diesem Grund empfehle ich nicht die Verwendung von agvtool mit diesem Skript.

   Dennoch, in Ihrem Skript ausführen Phase können Sie das folgende Skript verwenden:

   "${DEVELOPER_BIN_DIR}/agvtool" next-version -all

   El next-version Argument erhöht die Build-Nummer ( bump ist ebenfalls ein Alias für dieselbe Sache), und -all Aktualisierungen Info.plist mit der neuen Build-Nummer.

9. Wenn Sie ein Einstellungsbündel haben, in dem Sie die Version und den Build anzeigen, können Sie am Ende des Skripts Folgendes hinzufügen, um die Version und den Build zu aktualisieren. Hinweis: Ändern Sie die PreferenceSpecifiers Werte an Ihre Einstellungen anpassen. PreferenceSpecifiers:2 bedeutet, dass Sie sich den Eintrag bei Index 2 unter dem PreferenceSpecifiers Array in Ihrer plist-Datei, also für einen 0-basierten Index, ist das die 3.

   productVersion=$(/usr/libexec/PlistBuddy -c "Print CFBundleShortVersionString" "$INFOPLIST_FILE")
   /usr/libexec/PlistBuddy -c "Set PreferenceSpecifiers:2:DefaultValue $buildNumber" Settings.bundle/Root.plist
   /usr/libexec/PlistBuddy -c "Set PreferenceSpecifiers:1:DefaultValue $productVersion" Settings.bundle/Root.plist

   Wenn Sie Folgendes verwenden agvtool anstatt die Info.plist direkt zu verwenden, können Sie stattdessen Folgendes in Ihr Skript aufnehmen:

   buildNumber=$("${DEVELOPER_BIN_DIR}/agvtool" what-version -terse)
   productVersion=$("${DEVELOPER_BIN_DIR}/agvtool" what-marketing-version -terse1)
   /usr/libexec/PlistBuddy -c "Set PreferenceSpecifiers:2:DefaultValue $buildNumber" Settings.bundle/Root.plist
   /usr/libexec/PlistBuddy -c "Set PreferenceSpecifiers:1:DefaultValue $productVersion" Settings.bundle/Root.plist

10. Und wenn Sie eine Universal-App für iPad und iPhone haben, können Sie auch die Einstellungen für die iPhone-Datei festlegen:

    /usr/libexec/PlistBuddy -c "Set PreferenceSpecifiers:2:DefaultValue $buildNumber" Settings.bundle/Root~iphone.plist    
    /usr/libexec/PlistBuddy -c "Set PreferenceSpecifiers:1:DefaultValue $productVersion" Settings.bundle/Root~iphone.plist

Answer 2

(Ich lasse dies hier nur für meine eigene Referenz.) Dies zeigt Version und Build für die "Version" und "Build" Felder, die Sie in einem Xcode Ziel sehen:

- (NSString*) version {
    NSString *version = [[[NSBundle mainBundle] infoDictionary] objectForKey:@"CFBundleShortVersionString"];
    NSString *build = [[[NSBundle mainBundle] infoDictionary] objectForKey:@"CFBundleVersion"];
    return [NSString stringWithFormat:@"%@ build %@", version, build];
}

In Mauersegler

func version() -> String {
    let dictionary = NSBundle.mainBundle().infoDictionary!
    let version = dictionary["CFBundleShortVersionString"] as? String
    let build = dictionary["CFBundleVersion"] as? String
    return "\(version) build \(build)"
}

Answer 3

Die Build-Nummer ist eine interne Nummer, die den aktuellen Stand der Anwendung angibt. Sie unterscheidet sich von der Versionsnummer dadurch, dass sie in der Regel nicht benutzerorientiert ist und keine Unterschiede/Funktionen/Upgrades angibt, wie es eine Versionsnummer normalerweise tun würde.

Stellen Sie sich das folgendermaßen vor:

• Bauen ( CFBundleVersion ): Die Nummer des Builds. Normalerweise fängt man mit 1 an und erhöht sie mit jedem Build der App um 1. So lässt sich schnell vergleichen, welcher Build der aktuellste ist, und es zeigt den Fortschritt der Codebasis an. Dies kann sehr wertvoll sein, wenn man mit der Qualitätssicherung zusammenarbeitet und sicher sein muss, dass Fehler mit den richtigen Builds protokolliert werden.
• Marketing Version ( CFBundleShortVersionString ): Die benutzerseitige Nummer, die Sie zur Bezeichnung dieser Version Ihrer Anwendung verwenden. Normalerweise folgt dies einem Major-Minor-Versionsschema (z. B. MyAwesomeApp 1.2), damit die Benutzer wissen, welche Versionen kleinere Wartungsupdates und welche große neue Funktionen sind.

Um dies effektiv in Ihren Projekten zu nutzen, bietet Apple ein großartiges Werkzeug namens agvtool . Ich empfehle die Verwendung dieser Methode, da sie viel einfacher ist als die Skripterstellung von Plist-Änderungen. Damit können Sie sowohl die Build-Nummer als auch die Marketing-Version einfach einstellen. Es ist besonders nützlich bei der Erstellung von Skripten (z. B. zur einfachen Aktualisierung der Build-Nummer bei jedem Build oder zur Abfrage der aktuellen Build-Nummer). Es kann sogar exotischere Dinge tun, wie zum Beispiel Ihr SVN für Sie taggen, wenn Sie die Build-Nummer aktualisieren.

Zur Verwendung:

• Stellen Sie Ihr Projekt in Xcode unter Versionierung auf "Apple Generic" ein.
• Im Terminal
  • agvtool new-version 1 (Setzen Sie die Build-Nummer auf 1)
  • agvtool new-marketing-version 1.0 (Setzen Sie die Marketing-Version auf 1.0)

Siehe die Manpage von agvtool für eine Menge guter Informationen

Answer 4

Das Skript zum automatischen Erhöhen der Build-Nummer in der obigen Antwort funktionierte bei mir nicht, wenn die Build-Nummer eine Fließkommazahl ist, also habe ich es ein wenig geändert:

#!/bin/bash    
buildNumber=$(/usr/libexec/PlistBuddy -c "Print CFBundleVersion" "$INFOPLIST_FILE")
buildNumber=`echo $buildNumber +1|bc`
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildNumber" "$INFOPLIST_FILE"

Answer 5

Die Nummer der Vertriebsfreigabe ist für die Kunden bestimmt und heißt Versionsnummer . Es beginnt mit 1.0 und geht für größere Aktualisierungen auf 2.0 , 3.0 für kleinere Aktualisierungen von 1.1 , 1.2 und für Fehlerkorrekturen an 1.0.1 , 1.0.2 . Diese Nummer ist auf Veröffentlichungen und neue Funktionen ausgerichtet.

El Build-Nummer ist meist die interne Anzahl von Builds die bis dahin gemacht worden sind. Manche verwenden aber auch andere Zahlen wie die Zweignummer des Repositorys. Diese Nummer sollte sein einzigartig um die verschiedenen, fast gleichen Builds zu unterscheiden.

Wie Sie sehen können, ist die Build-Nummer ist nicht erforderlich, und es ist Ihnen überlassen, welche Build-Nummer die Sie verwenden möchten. Wenn Sie also Ihre Xcode auf eine Hauptversion, die bauen Feld ist leer. Die Version Feld darf nicht leer sein!.

---

Um die bauen Nummer als NSString variabel:

NSString * appBuildString = [[NSBundle mainBundle] objectForInfoDictionaryKey:@"CFBundleVersion"];

Um die Version Nummer als NSString variabel:

NSString * appVersionString = [[NSBundle mainBundle] objectForInfoDictionaryKey:@"CFBundleShortVersionString"];

Wenn Sie wollen beide in einem NSString :

NSString * versionBuildString = [NSString stringWithFormat:@"Version: %@ (%@)", appVersionString, appBuildString];

Dies wird getestet mit Xcode Version 4.6.3 (4H1503) . Die Build-Nummer wird oft in Klammern geschrieben. Die Build-Nummer wird in hexadezimaler oder dezimaler Form angegeben.

---

Unter Xcode können Sie automatisch die Build-Nummer als Dezimalzahl indem Sie Folgendes in die Datei Run script Erstellungsphase in den Projekteinstellungen

#!/bin/bash    
buildNumber=$(/usr/libexec/PlistBuddy -c "Print CFBundleVersion" "$INFOPLIST_FILE")
buildNumber=$(($buildNumber + 1))
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildNumber" "$INFOPLIST_FILE"

について hexadezimal Build-Nummer dieses Skript verwenden

buildNumber=$(/usr/libexec/PlistBuddy -c "Print CFBundleVersion" "$INFOPLIST_FILE")
buildNumber=$((0x$buildNumber)) 
buildNumber=$(($buildNumber + 1)) 
buildNumber=$(printf "%X" $buildNumber)
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildNumber" "$INFOPLIST_FILE"