Które wersje / numery kompilacji aplikacji na iOS MUSZĄ zostać zwiększone po wydaniu App Store?

107

Pola wersji / kompilacji aplikacji na iOS obejmują:

  • „Wersja” CFBundleShortVersionString (String - iOS, OS X) określa numer wersji pakietu, który identyfikuje wydaną iterację aplikacji. Numer wersji wydania to ciąg składający się z trzech liczb całkowitych oddzielonych kropkami.

  • „Build” CFBundleVersion (String - iOS, OS X) określa numer wersji kompilacji pakietu, który identyfikuje iterację (wydaną lub niewydaną) pakietu. Numer wersji kompilacji powinien być ciągiem składającym się z trzech nieujemnych liczb całkowitych oddzielonych kropkami, przy czym pierwsza liczba całkowita jest większa od zera. Ciąg powinien zawierać tylko cyfry (0-9) i kropki (.). Zera wiodące są obcinane z każdej liczby całkowitej i zostaną zignorowane (to znaczy 1.02.3 jest równoważne 1.2.3). Tego klucza nie można zlokalizować.

  • „Numer wersji połączenia iTunes” : numer wersji określany podczas tworzenia nowej wersji aplikacji w iTunes Connect.

Moje pytanie brzmi:

Które numery wersji / kompilacji należy zwiększyć, gdy nowa wersja aplikacji zostanie przesłana do iTunes Connect i / lub opublikowana w App Store?

Czy „wersja” CFBundleShortVersionStringlub „kompilacja” mogą CFBundleVersionpozostać niezmienione między aktualizacjami aplikacji?

Dodatkowe punkty za źródła Apple lub dokładne komunikaty o błędach, które iTunesConnect wyświetla po przesłaniu nieprawidłowej wersji / numeru kompilacji.


Uwaga na Androida / Google Play:

Dyskusja, która powoduje to pytanie, dotyczy tego, że publiczna „wersja” aplikacji na Androida w sklepie Google Play nie musi być zwiększana i nie jest w żaden sposób weryfikowana. android:versionNameMoże pozostać taka sama między wersjami, upgrade, downgrade, albo być dowolny losowy ciąg znaków, a nie coś, co wydaje się być poprawny „numer wersji”.

android:versionName - Wartość ciągu, która reprezentuje wersję kodu aplikacji w wersji, w jakiej powinien być pokazywany użytkownikom.

Wartość jest ciągiem, dzięki czemu można opisać wersję aplikacji jako <major>.<minor>.<point>ciąg znaków lub jako dowolny inny typ bezwzględnego lub względnego identyfikatora wersji.

Różnica między versionName i versionNumber w systemie Android

Podczas gdy android:versionCodejest wymuszane jako liczba całkowita zwiększająca się przy wydaniu.


Dokumentacja Apple

Jak zauważono w nowo zaakceptowanej odpowiedzi , firma Apple niedawno opublikowała uwagę techniczną, w której szczegółowo opisano ich wersję i schemat numeru kompilacji:

Uwaga techniczna Apple TN2420 - Numery wersji i numery kompilacji

pkamb
źródło
Szczegółowa odpowiedź ze zrzutem ekranu: stackoverflow.com/a/31921249/936957
Yunus Nedim Mehel

Odpowiedzi:

115

Uwaga techniczna Apple TN2420, numery wersji i numery kompilacji

Podsumowanie:

  • Para ( Version, Build number) musi być unikalna.
    • Sekwencja jest prawidłowa: (1.0.1, 12) -> (1.0.1, 13) -> (1.0.2, 13) -> (1.0.2, 14) ...
  • Version( CFBundleShortVersionString ) musi być w kolejności rosnącej.
  • Build number( CFBundleVersion ) musi być w kolejności rosnącej.

Lista kontrolna numeru wersji i numeru kompilacji

Oto kilka rzeczy, które możesz sprawdzić, przesyłając nową kompilację do App Store. Upewnienie się, że numer wersji i numer kompilacji są prawidłowo ustawione, pomoże Ci uniknąć automatycznego odrzucania aplikacji z powodu nieprawidłowej konfiguracji.

  1. Dla każdej nowej wersji aplikacji musisz wymyślić nowy numer wersji. Ta liczba powinna być większa niż ostatni używany numer wersji. Chociaż możesz dostarczyć wiele kompilacji dla dowolnego konkretnego wydania swojej aplikacji, wystarczy użyć jednego nowego numeru wersji dla każdego nowego wydania aplikacji.
  2. Nie można ponownie używać numerów wersji.
  3. Dla każdej nowej kompilacji, którą prześlesz, będziesz musiał wymyślić nowy numer kompilacji, którego wartość jest większa niż ostatnio użyty numer kompilacji (dla tej samej wersji).
  4. Możesz ponownie użyć numerów kompilacji w różnych pociągach do wydania, ale nie możesz ponownie użyć numerów kompilacji w tym samym pociągu do wydania. W przypadku aplikacji macOS nie można ponownie używać numerów kompilacji w żadnym pociągu wydań.

Na podstawie listy kontrolnej (Version, Build Number)obowiązuje również następująca sekwencja.

  • Przypadek: ponowne użycie Build Numberw różnych pociągach do wydania. (UWAGA: NIE aplikacja macOS)

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

AechoLiu
źródło
Jestem zmieszany. Jednym z warunków jest „Nie można ponownie użyć numerów wersji”, ale w ostatnim przykładzie numery wersji pozostają takie same, podczas gdy numery kompilacji rosną. Czy coś źle interpretuję?
Emil
@Emil, myślę, że tej pary (wersja, numer kompilacji) nie można ponownie wykorzystać.
AechoLiu
6
Numery wersji @EmilParikh można przesyłać do Apple kilka razy przed wydaniem , każda z unikalnym numerem kompilacji. Ale po wydaniu nie można ponownie użyć tego numeru wersji.
pkamb
1
TN2420 mówi, że „Numery wersji i numery kompilacji mogą mieć maksymalnie trzy składniki oddzielone kropkami”, a następnie podaje następujący niedozwolony przykład 1.10000.1.5 . Wygląda jednak na to, że wiele aplikacji, w tym Chrome, używa numeru wersji zawierającego 4 komponenty (np. 68.0.3440.83 ). Wydaje mi się, że można to wytłumaczyć faktem, że strona TN2420 wspomina „ Ważne: ten dokument nie jest już aktualizowany. Jednak nie udało mi się znaleźć zaktualizowanego dokumentu, który definiuje nowe zasady. Czy ktoś jeszcze jest zdezorientowany?
catanman
@catanman Podoba mi się ta wersja semantyczna . Niech wersja będzie skomponowana z (major, minor, patch)manierą. Wcześniej korzystałem z 4 komponentów, ale App Store nie akceptuje tego formatu z 4 komponentami.
AechoLiu,
38

Plik CFBundleShortVersionStringPowinna odpowiadać liczbie wersji dajesz iTunes Connect. Jest to również numer wersji, który pojawia się, gdy użytkownik przegląda Twoją aplikację w App Store.

Numer wersji jest wyświetlany w sklepie i ta wersja powinna być zgodna z numerem wersji wprowadzonym później w iTunes Connect.

Źródło

Plik CFBundleVersion jest wyświetlany w App Store, ale jest używany przez iTunes do określenia, kiedy Twoja aplikacja została zaktualizowana.

Jeśli zaktualizujesz ciąg kompilacji zgodnie z opisem w „Ustawianie numeru wersji i ciągu kompilacji”, iTunes rozpozna, że ​​ciąg kompilacji się zmienił i prawidłowo zsynchronizuje nowy pakiet iOS App Store z urządzeniami testowymi.

Źródło

Odpowiadając bardziej szczegółowo na Twoje pytania ...

Które numery wersji / kompilacji należy zwiększyć, gdy nowa wersja aplikacji jest przesyłana do sklepu z aplikacjami?

Obie. Jedna jest wyświetlana w App Store, a druga jest używana przez iTunes do aktualizacji aplikacji.

Czy CFBundleShortVersionString lub CFBundleVersion mogą pozostać takie same między aktualizacjami aplikacji?

Nie. (Metapytanie, jaki byłby tu przypadek użycia? Jeśli zmodyfikowałeś ładunek w jakikolwiek sposób, kompilacja będzie inna, a użytkownik będzie chciał o tym wiedzieć). Jeśli spróbujesz, zobaczysz komunikaty o błędach, takie jak poniżej:

Komunikaty o błędach

A może są one porównywane z poprzednią odpowiednią liczbą, aby zapewnić, że w nowej wersji aplikacji zostanie przesłana większa liczbowo liczba?

Tak. Korzystanie z semver.org standardu .

Czy numery CFBundleShortVersionString i CFBundleVersion są w jakikolwiek sposób porównywane ze sobą?

Nie.

Andy
źródło
2
Racja, wiem, jak używane są te dwie liczby. Pytanie brzmi: czy oba z nich muszą być zwiększane podczas wydawania nowej wersji aplikacji?
pkamb
2
Tak, jeśli spróbujesz wypchnąć aplikację do App Store bez aktualizacji obu, zobaczysz komunikat o błędzie, np. Stackoverflow.com/questions/19367893/ ...
Andy
Dzięki, świetna edycja. Szczególnie dla tego linku. Walidator organizatora wyświetla błędy „musi zawierać wyższą wersję” zarówno dla CFBundleVersion, jak i CFBundleShortVersionString.
pkamb
1
+1 dla linku SemVer ... Biorąc pod uwagę numer wersji MAJOR.MINOR.PATCH, zwiększ: wersję MAJOR, gdy wprowadzasz niekompatybilne zmiany API, wersję MINOR, gdy dodajesz funkcje w sposób zgodny z poprzednimi wersjami i wersję PATCH, gdy robisz wstecz -kompatybilne poprawki błędów.
jeet.chanchawat
W związku z tym: jaki byłby tu przypadek użycia? Jeśli w jakikolwiek sposób edytowałeś ładunek, kompilacja będzie inna, a użytkownik będzie chciał o tym wiedzieć . Mój przypadek użycia jest taki, że moja aplikacja została pomyślnie sprawdzona przez Apple, ale nigdy wcześniej nie została wydana w App Store. Znalazłem błąd i chcę go naprawić - bez zmian CFBundleShortVersionString. czy to możliwe? Chcę odrzucić moją własną aplikację.
testowanie
31

CFBundleShortVersionString to publiczna „nazwa” wersji (na przykład: „2.5” lub „3.8.1”). Musisz ją zwiększać przy każdym wydaniu .

CFBundleVersion to prywatny numer kompilacji . Nie widać tego w AppStore. Musisz go zwiększać przy każdym przesyłaniu . Oznacza to, że jeśli kiedykolwiek odrzucisz plik binarny przed przejściem do trybu online i chcesz przesłać nowy plik binarny, będzie on miał ten sam ciąg CFBundleShortVersionString, ale musi mieć wyższą wartość CFBundleVersion (przykład: publiczny „2,5”, prywatny „2,5”, a następnie binarne odrzucenie i ponowne przesłanie prywatnego „2.5.1”)

Edycja 16 listopada 2016 r .:

/ ! \ Właściwość CFBundleVersion jest również używana (wraz z CFBundleName ) w User-Agentnagłówku wysyłanym przez NSURLConnection w kodzie.

Przykład: jeśli CFBundleName jest MojaApl i CFBundleVersion 2.21, wtedy każdy programowy zapytania HTTP wysyłane bezpośrednio przez kod przy użyciu NSURLConnection osadzi nagłówek:

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

(Nie dotyczy to żądań wysyłanych automatycznie przez UIWebView).

Gabriel
źródło
2
Duże rozróżnienie między wymaganiami dotyczącymi przesyłania / wydawania.
pkamb
@gabriel, próbowałem ustawić numer kompilacji na XX-rc2, ale walidator Organizatora nie pozwala mi ustawić niczego innego niż XYZ, gdzie X, Y i Z to liczby całkowite: S. Byłoby wspaniale mieć numer kompilacji -rc2, czy byłbyś kiedykolwiek w stanie przesłać z nim jedno wydanie?
Néstor
1
@nestor Masz rację, myliłem się. Dozwolone są tylko liczby. Pozwól mi edytować moją odpowiedź.
Gabriel
@gabriel używam skryptu do analizowania X.X-rc2w celu X.X.2, dla systemu CI, aby wygenerować buildNumberdo wysłania ich do iTunesConnect.
AechoLiu
5

CFBundleVersion i CFBundleShortVersionString muszą być większe niż numer ostatniej wersji aplikacji. Dobrą praktyką jest utrzymanie ich bez zmian. Powinieneś je znaleźć na swojej -info.plist.

Podczas próby sprawdzenia poprawności aplikacji w organizatorze zgłosi błąd, jeśli którykolwiek z nich nie został zwiększony. Przydarzyło mi się zeszłej nocy.

xoail
źródło
Wspomniałem o obu tych klawiszach w swoim pytaniu. Czy Twoja odpowiedź jest tutaj, że obie te wartości muszą zostać zwiększone? Czy możesz lepiej poprzeć swoją odpowiedź?
pkamb
Tak, oba muszą zostać zwiększone. Ostatniej nocy, kiedy próbowałem złożyć przed ich zwiększeniem, narzekałem na oba klucze.
xoail
Dzięki za dodatkowe info. Zmień swoją odpowiedź, aby dodać swoje wrażenia podczas przesyłania kompilacji.
pkamb
6
„Dobrą praktyką jest utrzymywanie ich bez zmian” - to niekoniecznie jest prawdą. Jeśli masz testerów pracujących nad Twoją aplikacją, możesz chcieć zwiększyć numer kompilacji w miarę wprowadzania zmian, ale zachowaj ten sam numer wersji. Korzystając z ciągłej integracji, możesz na przykład zaktualizować numer kompilacji przed wdrożeniem u testerów.
Andy
@Andy masz rację, ma sens. Dziękuję za wskazanie przypadku użycia. Myślałem tylko o pojedynczym środowisku programisty / testera.
xoail
5

Zarówno CFBundleVersioni CFBundleShortVersionString koniecznością być zwiększane podczas publikowania nowej wersji w App Store.

Ponadto jeden z ciągów musi być zgodny z wersją określoną w programie iTunes Connect.

Błąd Xcode Organizer Validator: należy zwiększyć numer wersji.

To pytanie zawiera powyższy zrzut ekranu przedstawiający Validator Xcode Organizer odmawiający sprawdzenia poprawności aplikacji, gdy CFBundleVersioni CFBundleShortVersionStringnie zostały zwiększone.

  • Ten pakiet jest nieprawidłowy. Wartość klucza CFBundleVersion[1.0] w pliku Info.plist musi zawierać wyższą wersję niż wersja przesłana poprzednio [1.134].

  • Ten pakiet jest nieprawidłowy. Wartość klucza CFBundleShortVersionString[1.0] w pliku Info.plist musi zawierać wyższą wersję niż wersja przesłana poprzednio [1.134].

Walidator zgłasza również błąd potwierdzający, że jeden z ciągów musi pasować do wersji aplikacji utworzonej w iTunes Connect.

  • Niezgodność wersji. Ani CFBundleVersion ['1.0'], ani CFBundleShortVersionString ['1.0'] w Info.plist nie odpowiadają wersji aplikacji ustawionej w iTunes Connect ['1.4'].
pkamb
źródło
2

Obecna uwaga techniczna Apple TN2420, numery wersji i numery kompilacji mówi (moje pogrubienie):

  1. W przypadku aplikacji na iOS można ponownie używać numerów kompilacji w różnych pociągach wydań, ale nie można ponownie używać numerów kompilacji w tym samym pociągu wydań. W przypadku aplikacji macOS nie można ponownie używać numerów kompilacji w żadnym pociągu wydań .

Niestety, oznacza to, że nie możesz ponownie użyć numeru kompilacji, który śledzi numer wersji pociągu na iOS, gdy próbujesz wydać tę samą kompilację na Mac Catalyst.

W moim przypadku, na przykład, z powodu kilku wcześniejszych problemów, ostatecznie wydałem 1.0.2 (4) jako aplikację Mac Catalyst, która odpowiadała 1.0.2 (1) na iOS. Teraz, gdy próbujesz wydać 1.0.3 (1) na obu, aplikacja nie przechodzi weryfikacji w systemie MacOS z powodu numeru kompilacji, podczas gdy przechodzi weryfikację w systemie iOS.

Wydaje mi się, że teraz, gdy rutynowo wypuszczam tę samą aplikację na iOS i MacOS, przyjmę numery kompilacji, które odpowiadają dacie, na przykład 20200111 i zwiększę o kropkę dziesiętną, jeśli muszę zmienić numer kompilacji w danej wersji.

Steve Harris
źródło
1

Musisz zwiększyć oba .

Przesyłając nową wersję, musisz utworzyć nową wersję w iTunes Connect, która automatycznie będzie wyższa niż poprzednie wersje. Ta wersja w iTunes Connect będzie oczekiwała pliku binarnego o tym samym numerze wersji, dlatego CFBundleShortVersionStringnależy ją zwiększyć.

Jeśli zaktualizujesz wersję, ale zapomnisz o zwiększeniu CFBundleVersion , wystąpi błąd podczas przesyłania. Zobacz odpowiedź i zrzut ekranu pkamb.

Aby uzyskać szczegółowe informacje na temat CFBundleShortVersionStringi CFBundleVersion, zobacz: https://stackoverflow.com/a/31921249/936957

Yunus Nedim Mehel
źródło
1

Mogę potwierdzić, po wypróbowaniu tego w obie strony, że sekwencja wersji i numerów kompilacji, takich jak ...

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

... zostanie zaakceptowany w przypadku aplikacji na iOS, ale w przypadku aplikacji na Maca (Catalyst) zwraca ten błąd:

BŁĄD ITMS-90061: „Ten pakiet jest nieprawidłowy. Wartość klucza CFBundleVersion [1] w pliku Info.plist musi zawierać wyższą wersję niż wersja przesłana wcześniej [2]”.

Wersja Mac i numery kompilacji musiałyby wyglądać jak ...

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

W przypadku iOS zwykłem wprowadzać numery kompilacji jako numer wersji oraz czwartą cyfrę, na przykład ...

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

... ale nie jest to również dozwolone w przypadku aplikacji na komputery Mac. Kiedy próbowałem przesłać moją pierwszą aplikację Mac (Catalyst), Apple akceptował tylko numer kompilacji składający się z trzech lub mniej cyfr:

BŁĄD ITMS-9000: „Ten pakiet jest nieprawidłowy. Wartość klucza CFBundleVersion [1.0.0.1] w pliku Info.plist musi być listą rozdzielaną kropkami, składającą się maksymalnie z trzech nieujemnych liczb całkowitych.”

Więc zmieniłem na pojedynczą liczbę, która zwiększa się dla każdej kompilacji i kontynuuje zwiększanie się według numerów wersji.

arlomedia
źródło
Czy masz któryś z komunikatów o błędach, które Ci przekazał? Jeśli tak, zacytuj je!
pkamb
0

Przygotowuję się do wydania nowej aplikacji Mac App Store. Korzystanie z formatowania CalVerYEAR.release (build) .

Wysłałem kilka buduje: 2020.0 (1), 2020.0 (2), itd. I wreszcie złożone 2020.0 (8)do App Store Review. Ten przeszedł przegląd i jest w stanie Oczekujące na wydanie programisty .

Chciałem naprawić kilka rzeczy przed zwolnieniem, więc dodałam nowy build do tego samego pociągu wydaniu: 2020.0 (9).

Powoduje to błąd:

Błąd operacji połączenia ze sklepem App Store

BŁĄD ITMS-90062 : „Ten pakiet jest nieprawidłowy. Wartość klucza CFBundleShortVersionString[2020.0] w pliku Info.plist musi zawierać wyższą wersję niż wersja wcześniej zatwierdzona [2020.0]. Więcej informacji na ten temat można znaleźć CFBundleShortVersionStringpod adresem https: // developer.apple.com/documentation/bundleresources/information_property_list/cfbundleshortversionstring "

co jest denerwujące, ponieważ moja 2020.0wersja nigdy nie została wydana . Z przyjętej odpowiedzi na to pytanie odniosłem wrażenie, że do czasu udostępnienia aplikacji w App Store można było nadal wydawać nowe kompilacje w tej samej wersji.

Wydaje się, że rozwiązaniem jest to, że „pociągu wydania” (ta sama wersja + nowa kompilacja) nie może zostać zaktualizowany, jeśli stan aplikacji to Oczekujące wydanie programisty . Zwolnij istniejącą kompilację, a następnie zwiększ wersję, lub Anuluj to wydanie w App Store Connect, aby umożliwić dalsze przesyłanie dla tego pociągu wersji.

pkamb
źródło
-2

AFAIK, myślę, że musisz tylko zwiększyć numer kompilacji CFBundleVersion. Zwiększanie krótkiego ciągu wersji niekoniecznie jest potrzebne, ale prawdopodobnie powinieneś go zwiększyć, ponieważ informuje użytkownika, że ​​aplikacja jest nowa. Apple twierdzi, że numeracja powinna być zgodna z tradycyjnymi konwencjami wersjonowania oprogramowania, a iTunes Connect może narzekać, jeśli spróbujesz ponownie przesłać już istniejącą wersję.

Krótko mówiąc, może działać, ale prawdopodobnie nie.

SevenBits
źródło
Poszukiwanie autorytatywnych odpowiedzi na temat kluczy, które należy zwiększać. Jeśli CFBundleShortVersionStringnie jest wymagane zwiększenie wartości, „tę samą” wersję przeznaczoną dla użytkownika można następnie wielokrotnie przesyłać do App Store?
pkamb