Nomor versi / versi aplikasi iOS mana yang HARUS ditambahkan setelah App Store dirilis?

107

Bidang versi / build untuk aplikasi iOS meliputi:

"Version" CFBundleShortVersionString (String - iOS, OS X) menentukan nomor versi rilis bundel, yang mengidentifikasi iterasi yang dirilis dari aplikasi. Nomor versi rilis adalah string yang terdiri dari tiga bilangan bulat yang dipisahkan oleh periode.
CFBundleVersion "Build" (String - iOS, OS X) menentukan nomor versi build dari bundel, yang mengidentifikasi iterasi (dirilis atau tidak dirilis) bundel. Nomor versi build harus berupa string yang terdiri dari tiga bilangan bulat non-negatif yang dipisahkan titik dengan bilangan bulat pertama lebih besar dari nol. String hanya boleh berisi karakter numerik (0-9) dan titik (.). Nol di depan dipotong dari setiap bilangan bulat dan akan diabaikan (yaitu, 1.02.3 setara dengan 1.2.3). Kunci ini tidak dapat dilokalkan.
"Nomor Versi iTunes Connect" : nomor versi yang Anda tentukan saat membuat versi baru aplikasi di iTunes Connect.

Pertanyaanku adalah:

Nomor versi / build mana yang perlu ditambahkan saat versi baru aplikasi diunggah ke iTunes Connect dan / atau dirilis ke App Store?

Bisakah "versi" CFBundleShortVersionStringatau "build" CFBundleVersiontetap sama di antara pembaruan aplikasi?

Poin ekstra untuk sumber Apple atau pesan kesalahan persis yang ditampilkan iTunesConnect saat mengunggah nomor versi / build yang tidak valid.

Catatan Android / Google Play:

Diskusi yang memunculkan pertanyaan ini adalah bahwa "versi" publik dari aplikasi Android di Google Play Store tidak perlu ditambah dan sama sekali tidak divalidasi. The android:versionNamedapat tetap sama antara rilis, upgrade, downgrade, atau berupa string acak bukan sesuatu yang muncul untuk menjadi "nomor versi" valid.

android:versionName - Nilai string yang mewakili versi rilis kode aplikasi, sebagaimana harus ditampilkan kepada pengguna.

Nilainya adalah string sehingga Anda dapat mendeskripsikan versi aplikasi sebagai <major>.<minor>.<point>string, atau sebagai jenis pengenal versi absolut atau relatif lainnya.

Perbedaan antara versionName dan versionNumber di Android

Sedangkan yang android:versionCodediberlakukan menjadi integer incrementing-on-release.

Dokumentasi Apple

Seperti disebutkan dalam jawaban yang baru diterima , Apple baru-baru ini menerbitkan Catatan Teknis yang merinci versi dan skema nomor build mereka:

Catatan Teknis Apple TN2420 - Nomor Versi dan Nomor Build

— pkamb
sumber

Jawaban rinci dengan tangkapan layar: stackoverflow.com/a/31921249/936957

— Yunus Nedim Mehel

115

Catatan Teknis Apple TN2420, Nomor Versi dan Nomor Build

Ringkasan:

Pasangan ( Version, Build number) harus unik.
- Urutannya valid: (1.0.1, 12) -> (1.0.1, 13) -> (1.0.2, 13) -> (1.0.2, 14) ...
Version( CFBundleShortVersionString ) harus dalam urutan berurutan menaik.
Build number( CFBundleVersion ) harus dalam urutan menaik.

Nomor Versi dan Daftar Periksa Nomor Bangun

Berikut beberapa hal yang dapat Anda periksa saat mengirimkan build baru ke App Store. Memastikan Anda memiliki Nomor Versi dan Nomor Bangun yang disetel dengan benar akan membantu Anda dengan menghindari Aplikasi Anda ditolak secara otomatis karena tidak dikonfigurasi dengan benar.

Untuk setiap versi baru Aplikasi Anda, Anda perlu menemukan Nomor Versi baru. Angka ini harus lebih besar dari pada Nomor Versi terakhir yang Anda gunakan. Meskipun Anda dapat menyediakan banyak build untuk rilis tertentu dari Aplikasi Anda, Anda hanya perlu menggunakan satu Nomor Versi baru untuk setiap rilis baru Aplikasi Anda.

Anda tidak dapat menggunakan kembali Nomor Versi.

Untuk setiap build baru yang Anda kirimkan, Anda perlu menemukan Build Number baru yang nilainya lebih besar dari Build Number terakhir yang Anda gunakan (untuk versi yang sama).

Anda dapat menggunakan kembali Nomor Build di rangkaian rilis yang berbeda, tetapi Anda tidak dapat menggunakan kembali Nomor Build dalam rangkaian rilis yang sama. Untuk aplikasi macOS, Anda tidak dapat menggunakan kembali nomor build di rangkaian rilis mana pun.

Berdasarkan checklist, (Version, Build Number)urutan berikut juga valid.

Kasus: digunakan kembali Build Numberdi rangkaian rilis yang berbeda. (CATATAN: BUKAN aplikasi macOS)

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

— AechoLiu
sumber

Saya bingung. Salah satu ketentuannya adalah "Anda tidak dapat menggunakan kembali Nomor Versi", tetapi dalam contoh terakhir, nomor versi tetap sama sementara nomor versi meningkat. Apakah saya salah menafsirkan sesuatu?

— Emil

@Emil, saya pikir pasangan (Versi, Nomor Bangun) itu tidak dapat digunakan kembali.

— AechoLiu

6

Nomor Versi @EmilParikh dapat diunggah ke Apple beberapa kali sebelum dirilis , masing-masing dengan nomor Build unik. Tetapi setelah dirilis, Anda tidak dapat menggunakan kembali nomor Versi itu.

— pkamb

1

TN2420 mengatakan "Nomor versi dan nomor versi mungkin memiliki hingga tiga komponen yang dipisahkan oleh titik" dan kemudian memberikan contoh ilegal berikut 1.10000.1.5 . Namun, sepertinya banyak aplikasi, termasuk chrome, menggunakan nomor versi yang berisi 4 komponen (mis. 68.0.3440.83 ). Saya kira ini dapat dijelaskan oleh fakta bahwa halaman TN2420 menyebutkan " Penting: Dokumen ini tidak lagi diperbarui. " Namun saya belum dapat menemukan dokumen yang diperbarui yang mendefinisikan aturan baru. Ada lagi yang bingung?

— catanman

@ Setanman saya suka ini Versi Semantik . Biarlah versi disusun dengan (major, minor, patch)cara. Dan saya telah menggunakan 4 komponen sebelumnya, tetapi App store tidak menerima format tersebut dengan 4 komponen.

— AechoLiu

38

The CFBundleShortVersionStringharus sesuai dengan nomor versi yang Anda berikan iTunes Connect. Ini juga merupakan nomor versi yang muncul saat pengguna melihat Aplikasi Anda di App Store.

Nomor versi ditampilkan di toko dan versi itu harus cocok dengan nomor versi yang Anda masukkan nanti di iTunes Connect.

Sumber

Tidak CFBundleVersionditampilkan di App Store, tetapi digunakan oleh iTunes untuk menentukan kapan App Anda telah diperbarui.

Jika Anda memperbarui string build, seperti yang dijelaskan di "Mengatur Nomor Versi dan String Build," iTunes mengenali bahwa string build berubah dan menyinkronkan Paket App Store iOS baru dengan benar untuk menguji perangkat.

Sumber

Menjawab pertanyaan Anda lebih spesifik ...

Nomor versi / build mana yang perlu ditambahkan saat versi baru aplikasi diupload ke App Store?

Kedua. Satu ditampilkan di App Store, yang lainnya digunakan oleh iTunes untuk memperbarui App.

Dapatkah CFBundleShortVersionString atau CFBundleVersion tetap sama di antara pembaruan aplikasi?

Tidak. (Pertanyaan meta, kasus penggunaan apa di sini? Jika Anda telah mengedit payload dengan cara apa pun, build akan berbeda, dan pengguna ingin mengetahuinya). Jika Anda mencoba, Anda akan melihat pesan kesalahan seperti di bawah ini:

Pesan kesalahan

Atau apakah mereka dibandingkan dengan masing-masing nomor sebelumnya untuk memastikan bahwa nomor yang secara numerik lebih besar diunggah dengan versi baru aplikasi?

Iya. Menggunakan standar semver.org .

Apakah angka CFBundleShortVersionString dan CFBundleVersion dengan cara apa pun dibandingkan satu sama lain?

Tidak.

— Andy
sumber

2

Benar, saya tahu bagaimana kedua angka itu digunakan. Pertanyaannya adalah: apakah keduanya diperlukan untuk bertambah ketika merilis versi baru dari aplikasi?

— pkamb

2

Ya, jika Anda mencoba memasukkan Aplikasi ke App Store tanpa memperbarui keduanya, Anda akan melihat pesan kesalahan misalnya stackoverflow.com/questions/19367893/…

— Andy

Terima kasih, hasil edit yang bagus. Khusus untuk tautan itu. Validator penyelenggara menunjukkan kesalahan "harus berisi versi yang lebih tinggi" untuk CFBundleVersion dan CFBundleShortVersionString.

— pkamb

1

+1 untuk tautan SemVer ... Diberikan nomor versi MAJOR.MINOR.PATCH, tingkatkan: versi MAJOR saat Anda membuat perubahan API yang tidak kompatibel, versi MINOR saat Anda menambahkan fungsionalitas dengan cara yang kompatibel mundur, dan versi PATCH saat Anda membuat mundur -perbaikan bug yang kompatibel.

— jeet.chanchawat

Mengenai ini: kasus penggunaannya seperti apa di sini? Jika Anda telah mengedit payload dengan cara apa pun, build akan berbeda, dan pengguna ingin mengetahuinya . Kasus penggunaan saya adalah aplikasi saya berhasil ditinjau oleh Apple, tetapi tidak pernah dirilis sebelumnya di App Store. Saya menemukan kesalahan dan saya ingin memperbaikinya - tanpa mengubahnya CFBundleShortVersionString. Apakah ini mungkin? Saya ingin menolak aplikasi saya sendiri.

— pengujian

31

CFBundleShortVersionString adalah "nama" publik dari versi tersebut (contoh: "2.5", atau "3.8.1"). Anda harus meningkatkannya di setiap rilis .

CFBundleVersion adalah nomor build pribadi . Itu tidak terlihat di AppStore. Anda harus meningkatkannya di setiap unggahan . Ini berarti bahwa jika Anda pernah menolak biner sebelum online, dan Anda ingin mengunggah biner baru, itu akan memiliki CFBundleShortVersionString yang sama tetapi harus memiliki CFBundleVersion yang lebih tinggi (contoh: publik "2.5", pribadi "2.5", dan kemudian penolakan biner, dan unggah ulang pribadi "2.5.1")

Edit pada 16 November 2016:

/ ! \ Properti CFBundleVersion juga digunakan (bersama dengan CFBundleName ) di User-Agentheader yang dikirim oleh NSURLConnection dalam kode Anda.

Contoh: jika CFBundleName adalah MyApp dan CFBundleVersion adalah 2.21, maka semua permintaan HTTP terprogram yang dikirim langsung oleh kode Anda menggunakan NSURLConnection akan menyematkan header:

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

(Ini tidak berlaku untuk permintaan yang dikeluarkan secara otomatis oleh UIWebView).

— Gabriel
sumber

2

Perbedaan besar antara persyaratan upload / rilis.

— pkamb

@ gabriel, saya sudah mencoba menyetel nomor build ke XX-rc2 tetapi validator Organizer tidak mengizinkan saya menyetel sesuatu yang berbeda dari XYZ di mana X, Y, dan Z adalah bilangan bulat: S. Sangat menyenangkan memiliki nomor build -rc2, pernahkah Anda bisa mengirimkan satu rilis dengannya?

— Néstor

1

@nestor Anda benar, saya salah. Hanya angka yang diperbolehkan. Biarkan saya mengedit jawaban saya.

— Gabriel

@gabriel, saya menggunakan script untuk mengurai X.X-rc2untuk X.X.2, untuk sistem CI untuk menghasilkan buildNumberuntuk meng-upload ke iTunesConnect.

— AechoLiu

5

CFBundleVersion dan CFBundleShortVersionString harus lebih besar dari nomor versi terakhir aplikasi. Merupakan praktik yang baik untuk menjaga mereka tetap sama. Anda harus menemukannya di -info.plist Anda.

Ketika Anda mencoba untuk memvalidasi aplikasi dalam penyelenggara, itu akan menimbulkan kesalahan jika salah satu dari mereka belum bertambah. Terjadi padaku tadi malam.

— xoail
sumber

Saya menyebutkan kedua kunci itu dalam pertanyaan saya. Apakah jawaban Anda di sini bahwa kedua nilai tersebut harus ditambah? Bisakah Anda lebih mendukung jawaban Anda?

— pkamb

Ya, keduanya perlu ditambah. Tadi malam ketika saya mencoba untuk mengirimkan sebelum menaikkan mereka, itu mengeluh untuk kedua kunci.

— xoail

Terima kasih atas info tambahannya. Anda harus mengedit jawaban Anda untuk menambah pengalaman Anda saat mengupload sebuah bangunan.

— pkamb

6

"Merupakan praktik yang baik untuk menjaga mereka tetap sama" - ini belum tentu benar. Jika Anda memiliki penguji yang bekerja di Aplikasi Anda, Anda mungkin ingin menaikkan nomor build Anda saat perubahan diterapkan, tetapi pertahankan nomor versi Anda tetap sama. Menggunakan integrasi berkelanjutan, Anda dapat membuatnya memperbarui nomor build untuk Anda sebelum menerapkannya ke penguji, misalnya.

— Andy

@Andy kamu benar, masuk akal. Terima kasih telah menunjukkan kasus penggunaan. Saya hanya berpikir dalam kerangka satu lingkungan pengembang / penguji.

— xoail

5

Keduanya CFBundleVersiondan CFBundleShortVersionString HARUS bertambah saat merilis versi baru ke App Store.

Selain itu, salah satu string harus cocok dengan versi yang ditentukan di iTunes Connect.

Kesalahan Xcode Organizer Validator: harus menambah nomor versi.

Pertanyaan ini termasuk tangkapan layar di atas dari Xcode Organizer's Validator yang menolak untuk memvalidasi aplikasi ketika CFBundleVersiondan CFBundleShortVersionStringbelum ditambahkan.

Paket ini tidak valid. Nilai untuk kunci CFBundleVersion[1.0] dalam file Info.plist harus berisi versi yang lebih tinggi daripada versi yang diunggah sebelumnya [1.134].
Paket ini tidak valid. Nilai untuk kunci CFBundleShortVersionString[1.0] dalam file Info.plist harus berisi versi yang lebih tinggi daripada versi yang diunggah sebelumnya [1.134].

Validator juga memberikan kesalahan yang membuktikan bahwa salah satu string harus cocok dengan versi aplikasi yang dibuat di iTunes Connect.

Versi Tidak Cocok. Baik CFBundleVersion ['1.0'] maupun CFBundleShortVersionString ['1.0'] di Info.plist tidak cocok dengan versi aplikasi yang disetel di iTunes Connect ['1.4'].

— pkamb
sumber

2

Saat Apel Catatan Teknis TN2420, Nomor Versi dan Nomor Build mengatakan (saya huruf tebal):

Untuk aplikasi iOS, Anda dapat menggunakan kembali nomor build di rangkaian rilis yang berbeda, tetapi Anda tidak dapat menggunakan kembali nomor build dalam rangkaian rilis yang sama. Untuk aplikasi macOS, Anda tidak dapat menggunakan kembali nomor build di rangkaian rilis mana pun .

Sayangnya, ini berarti Anda tidak dapat menggunakan kembali nomor build yang melacak nomor kereta rilis di iOS saat Anda mencoba merilis build yang sama di Mac Catalyst.

Dalam kasus saya, misalnya, karena beberapa masalah sebelumnya, saya akhirnya merilis 1.0.2 (4) sebagai aplikasi Mac Catalyst yang sesuai dengan 1.0.2 (1) di iOS. Sekarang ketika mencoba untuk merilis 1.0.3 (1) pada keduanya, aplikasi gagal verifikasi di MacOS karena nomor build, sementara lolos verifikasi di iOS.

Saya kira sekarang saya merilis aplikasi yang sama di iOS dan MacOS secara rutin, saya akan mengadopsi nomor build yang sesuai dengan tanggal, seperti 20200111 dan kenaikan dengan titik desimal jika saya perlu mengubah nomor build dalam rilis tertentu.

— Steve Harris
sumber

1

Anda perlu menaikkan keduanya .

Saat mengupload versi baru, Anda perlu membuat versi baru di iTunes Connect, yang secara otomatis akan lebih tinggi dari rilis sebelumnya. Versi ini di iTunes Connect akan mengharapkan biner dengan nomor versi yang sama, oleh karena itu CFBundleShortVersionStringperlu ditambah.

Jika Anda memperbarui versinya tetapi lupa menaikkan CFBundleVersion , Anda akan mengalami kesalahan selama mengunggah. Lihat jawaban dan tangkapan layar pkamb.

Untuk detail tentang CFBundleShortVersionStringdan CFBundleVersion, silakan lihat: https://stackoverflow.com/a/31921249/936957

— Yunus Nedim Mehel
sumber

1

Saya dapat mengonfirmasi, baru saja mencoba kedua cara, bahwa urutan versi dan nomor build seperti ...

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

... akan diterima untuk aplikasi iOS, tetapi untuk aplikasi Mac (Catalyst) mengembalikan kesalahan ini:

ERROR ITMS-90061: "Paket ini tidak valid. Nilai untuk CFBundleVersion kunci [1] dalam file Info.plist harus berisi versi yang lebih tinggi daripada versi yang diunggah sebelumnya [2]."

Versi Mac dan nomor build harus seperti ...

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

Untuk iOS, saya biasa memasukkan nomor build sebagai nomor versi ditambah digit keempat, seperti ...

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

... tapi itu juga tidak diperbolehkan untuk aplikasi Mac. Ketika saya mencoba mengirimkan aplikasi Mac (Catalyst) pertama saya, Apple hanya akan menerima nomor build dengan tiga digit atau kurang:

ERROR ITMS-9000: "Paket ini tidak valid. Nilai untuk CFBundleVersion [1.0.0.1] dalam file Info.plist harus berupa daftar yang dipisahkan titik dari paling banyak tiga bilangan bulat non-negatif."

Jadi saya mengubah ke satu nomor yang bertambah untuk setiap build dan terus bertambah di nomor versi.

— arlomedia
sumber

Apakah Anda memiliki pesan kesalahan yang diberikannya? Tolong kutip mereka jika demikian!

— pkamb

0

Saya sedang bersiap untuk merilis aplikasi Mac App Store baru. Menggunakan format CalVerYEAR.release (build) .

Saya upload beberapa membangun: 2020.0 (1), 2020.0 (2), dll saya akhirnya diserahkan 2020.0 (8)untuk App Store Ulasan. Itu lulus tinjauan dan dalam status Tertunda Rilis Pengembang .

Saya ingin memperbaiki beberapa hal sebelum rilis, jadi saya menambahkan membangun baru untuk rilis kereta yang sama: 2020.0 (9).

Itu menghasilkan kesalahan:

Kesalahan Operasi App Store Connect

ERROR ITMS-90062 : "Paket ini tidak valid. Nilai untuk kunci CFBundleShortVersionString[2020.0] dalam file Info.plist harus berisi versi yang lebih tinggi daripada versi yang disetujui sebelumnya [2020.0]. Temukan informasi lebih lanjut tentang CFBundleShortVersionStringdi https: // developer.apple.com/documentation/bundleresources/information_property_list/cfbundleshortversionstring "

yang menjengkelkan karena 2020.0versi saya tidak pernah benar-benar dirilis . Dari jawaban yang diterima untuk pertanyaan ini, saya mendapat kesan bahwa hingga aplikasi tersedia di App Store, Anda dapat terus merilis versi baru dengan versi yang sama.

Solusinya adalah bahwa "rangkaian rilis" (Versi Sama + Versi Baru) tidak dapat diperbarui jika status aplikasi Menunggu Rilis Pengembang . Rilis build yang ada lalu tingkatkan versinya, atau Batalkan Rilis ini di App Store Connect untuk memungkinkan upload lebih lanjut untuk rangkaian rilis ini.

— pkamb
sumber

-2

AFAIK, di luar kepala saya, Anda hanya perlu menaikkan nomor build CFBundleVersion. Menambahkan string versi pendek tidak selalu diperlukan, meskipun Anda mungkin harus menaikkannya, karena hal itu memberi tahu pengguna bahwa aplikasi tersebut baru. Apple mengatakan bahwa penomoran harus mengikuti konvensi pembuatan versi perangkat lunak tradisional, dan iTunes Connect mungkin mengeluh jika Anda mencoba mengunggah ulang versi yang sudah ada.

Singkat cerita, ini mungkin berhasil, tetapi mungkin tidak.

— SevenBits
sumber

Mencari jawaban otoritatif yang kuncinya harus ditambah. Jika CFBundleShortVersionStringtidak perlu ditambahkan, versi untuk pengguna yang "sama" dapat diunggah ke App Store beberapa kali?

— pkamb