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

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

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)

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:

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.

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).

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.

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.

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'].

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

4. 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.

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

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.

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.

• Błąd ITMS-90062: wartość klucza CFBundleShortVersionString musi zawierać wyższą wersję niż wersja poprzednio zatwierdzona
• Application Loader ERROR ITMS-90062: Wartość klucza CFBundleShortVersionString musi zawierać wyższą wersję

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.

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.