Це моє перше подання на додаток для iOS, і я не хочу, щоб моє додаток було відхилено.

Це з Документів Apple:

CFBundleVersion (String - iOS, OS X) вказує номер версії збірки в комплекті, який ідентифікує ітерацію (випущена чи невипущена) пакету. Номер версії збірки повинен бути рядок, що складається з трьох невід’ємних цілих чисел, розділених періодом, причому перше ціле число перевищує нуль. Рядок повинен містити лише числові (0-9) та символи періоду (.). Провідні нулі обрізаються з кожного цілого числа і будуть ігноровані (тобто 1,02.3 еквівалентно 1.2.3). Цей ключ не піддається локалізації.

CFBundleShortVersionString (String - iOS, OS X) визначає номер версії версії пакета, який ідентифікує випущену ітерацію програми. Номер версії випуску - це рядок, що складається з трьох цілих чисел, розділених періодом. Перше ціле число являє собою основні зміни програми, такі як версії, що впроваджують нові функції або основні зміни. Друге ціле число позначає версії, що реалізують менш помітні функції. Третє ціле число представляє випуски технічного обслуговування.

Значення цього ключа відрізняється від значення "CFBundleVersion", яке ідентифікує ітерацію (випущена чи невипущена) програми. Цей ключ можна локалізувати, включивши його у файли InfoPlist.strings.

Але це здається трохи дивним. Моя інтерпретація цього полягає в тому, щоб обидві значення були однаковими, тобто:

CFBundleVersion: 1.0.0
CFBundleShortVersionString: 1.0.0

Чи може хтось підтвердити 100% те, що я маю сказати?

Подумайте про це так: "Коротка версія" ( CFBundleShortVersionString) - це номер публічної версії. "Версія" ( CFBundleVersion) - це більше внутрішній номер версії, який може змінюватися набагато частіше, ніж загальнодоступна "коротка версія". Особисто я використовую те саме для обох, але багато людей оновлюють "версію" для кожної збірки. У будь-якому випадку ви зазвичай оновлюєте "коротку версію", коли ви переходите на Apple. Як часто ви оновлюєте "версію", залежить від вас та ваших потреб.

CFBundleShortVersionString надає версію свого додатка. Зазвичай збільшується щоразу, коли ви публікуєте свою програму в App Store. Це версія, яку видно у розділі «Версія» на сторінці App Store вашої програми.

CFBundleVersion дає вам номер збірки, який використовується для розробки та тестування, а саме "технічних" цілей. Кінцевий користувач рідко цікавиться номером збірки, але під час розробки вам може знадобитися знати, що розробляється та фіксується на кожній збірці. Зазвичай це збільшується при кожній ітерації внутрішнього вивільнення. І ви можете використовувати засоби безперервної інтеграції, як Дженкінс, для автоматичного збільшення номера збірки для кожної збірки.

Ці два числа не залежать одне від одного, але добре їх тримати паралельно, щоб уникнути плутанини. Майте на увазі, що після того, як ваш додаток пройде огляд магазину додатків, вам потрібно збільшити номер збірки, як Phil і ​​likeTheSky, заявив він, незалежно від того, публікуєте ви його чи ні.

Приклад використання: Скажімо, у вас добре перевірена збірка, готова до подання. Номер версії - 1.0.0, а номер збірки - 1.0.0.32 . Після подачі програми вам потрібно оновити версію як 1.0.1 та номер збірки як 1.0.1.0 .

Відповідь на rmaddy правильно. Додам ще дві думки.

Номер третьої версії

Будьте в курсі третього номера версії, вказаного на веб-сайті iTunesConnect, як частини визначення вашої програми. Якщо це число відрізняється від двох у Xcode, Apple видає вам попередження. Ви можете ігнорувати попередження, оскільки це не стоп-шоу (не "помилка").

Дата-час як версія

Також не потрібно використовувати три цифри з розділовими знаками. Це може бути сенсом для деяких додатків, де традиційно зміни в першому номері вказують на якусь різку зміну, яка зазвичай впливає на сумісність.

Для інших програм ви можете просто використовувати значення дати в часі у стандартному стилі формату ISO 8601 (YYYYMMDDHHMM). Наприклад, 201606070620. Цей порядок року-місяця-дати-години-хвилини робить постійно зростаюче число, завжди однакову довжину через нульовий пробій, що при сортуванні в алфавітному порядку також є хронологічним.

Я успішно використовував цей стиль номерів версій у програмі iOS для доставки, що працює в iOS 7, 8 та 9.

Ви навіть можете автоматизувати генерацію цього значення. У вашому проекті Target> Build Phases> Run Scriptпанелі:

1. Вкажіть у Shellполі:/bin/sh
2. Вставте наступний сценарій з 5 рядків, показаний нижче.
3. (Не обов’язково) Поставте Show environment variables in build logпрапорець.
4. Зніміть прапорець біля поля Run script only when installing.

Кожен раз, коли ви створюєте збірку, фіксується поточний час у часовому поясі UTC . -uПрапор в сценарії використовує UTC , а не поточний час по замовчуванням зони. Як правило, найкраще для програмістів та системних адміністраторів використовувати та думати в UTC, а не в локальних часових поясах.

#!/bin/bash
buildNumber=$(date -u "+%Y%m%d%H%M")
/usr/libexec/PlistBuddy -c "Set :CFBundleShortVersionString $buildNumber" "$INFOPLIST_FILE"  # Version number
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildNumber" "$INFOPLIST_FILE"  # Build number
echo "DateTime for app version number: $buildNumber"

Або гібрид із звичайним 1.2.3для версії номером та датою, як номер збірки. Щоб зробити гібрид, просто прокоментуйте CFBundleShortVersionStringлінію з #передньою.

Найбільш розумна для мене схема - використовувати номер версії (тобто CFBundleShortVersionString) для фактичного номера версії, а потім використовувати номер збірки (тобто CFBundleVersion) для представлення подання в App Store. Тож, якщо немає проблем, і, отже, повторно подається, це число завжди 1. Для нового випуску я скидаю до 1, якщо в попередньому виникли проблеми при тестуванні TestFlight або в огляді.

Номери складання - це спосіб назвати кожен із поданих вами матеріалів для певного випуску. Як описано у вищезазначених визначеннях, колекція всіх складових, які ви надаєте для певної версії свого додатка, називається "програмою випуску" цієї версії. Для додатків iOS номери побудови повинні бути унікальними в кожному поїзді випуску, але вони не повинні бути унікальними для різних поїздів випуску [мій акцент]. Тобто, для iOS Apps ви можете знову використовувати ті ж номери збірки у різних поїздах випусків.

З технічної примітки TN2420: Номери версій та номери збірки .

Я використовую CFBundleVersion для вказівки внутрішньої збірки для CFBundleShortVersionString . Я використовую тестовий політ, щоб подати збірки для своїх тестерів, тому різниця між ними була надзвичайно корисною.

В документах Apple сказано, що CFBundleVersion "повинен бути рядок, що складається з 3 невід'ємних цілих чисел, розділених періодом", але насправді це може бути БОЛЬШЕ, ніж 3 частини (як показано вище). Я використовую це для позначення складання моєї розробки, скажімо, що мій CFBundleShortVersionString - це 1.0.0, я можу використовувати 1.0.0.11 для CFBundleVersion, щоб вказати, що це моя 11-я збірка для випуску 1.0.0

Кожен CFBundleVersion, поданий у магазин додатків, повинен бути більшим, ніж раніше, інакше ви отримаєте ПОМИЛУ ITMS-90478 : "Недійсна версія. Збірка з версією" xxx "неможливо імпортувати, оскільки пізніша версія закрита для подання нових збірок. Виберіть інший номер версії. "

CFBundleShortVersionString може мати лише 3 частини, інакше ви отримаєте ПОМИЛУ ITMS-90060. Значення для ключа CFBundleShortVersionString 'xxx' у файлі Info.plist має бути розділеним періодом не більше ніж трьома негативними цілими числами. "

Третій номер , що Василь Бурк згадується, тобто число показує версію на iTunesConnect , де речі можуть отримати складно.

Я використовую інший номер iTunesConnect, ніж CFBundleShortVersionString, тому що коли я вперше подав свою програму в магазин додатків, у нас вже є багато раундів внутрішніх релізів. Тому я використав 1,0 для номера iTunesConnect і 5.x для CFBundleShortVersionString. У наступному випуску до магазину додатків я надав функцію перевірити, чи є нова версія в магазині додатків, і зрозумів, що у мене зараз проблеми, тому що я можу отримати лише номер iTunesConnect (використовуючи http://itunes.apple.com/lookup?bundleId=), тому мені потрібно зробити якийсь розрахунок, перш ніж порівняти його з номером CFBundleShortVersionString.

Я спробував це виправити, використовуючи номер iTunesConnect як мій CFBundleShortVersionString, але отримав помилку, ПОМИЛКА ITMS-90062 : "Цей пакет недійсний. Значення для ключа CFBundleShortVersionString [xxx] у файлі Info.plist має містити вищу версію, ніж ця попередньо затвердженої версії [xxx]. "

Тому я пропоную завжди робити їх однаковими.

Щось я ніколи не бачив обговорювати - це максимальна кількість для кожного поля в CFBundleVersion?

Встановивши CFBundleVersion у додатку на 1.1.1 та переглянувши шістнадцятковий параметр для версії у "lsregister -dump", я визначив, що максимальне значення для першого поля - (2 ^ 22) -1 або 4194303, а максимальне значення для другого та третього полів становлять (2 ^ 21) -1 або 2097151.

3 поля містять до 64 біт.

Це має значення для тих із нас, хто використовує CFBundleVersion залежно від дати та часу.

Я задав перше поле для РРРРММДД. Це завжди більше, ніж максимум дозволених версій, і, принаймні, це призводило до непередбачуваних результатів, коли Launch Services вирішував, яку версію програми запускати, коли у вас встановлено кілька версій і використовуєте щось на кшталт "відкрито-ім'я додатка 'з командного рядка.

Будь ласка, поширюйте це широко. Я впевнений, що багато людей з цим стикаються.

Відтепер документація Apple дляCFBundleVersion держав [акцент моя]:

Версія збірки, яка ідентифікує ітерацію пакету.

...

Цей ключ є машиночитаним рядком, що складається з одного до трьох цілих чисел , розділених періодом , наприклад 10.14.1. Рядок може містити лише числові символи (0-9) та періоди.

...

Ви можете включити більше цілих чисел, але система їх ігнорує.

Для CFBundleShortVersionString[акцент моє]:

Номер випуску або версії пакета.

...

Цей ключ є видимою для користувача рядком для версії пакету. Необхідний формат - це три цілі числа , розділені періодом , наприклад 10.14.1. Рядок може містити лише числові символи (0-9) та періоди.

Я пропоную просто збільшувати автоматично CFBundleVersionдля кожної збірки (або кожного випуску на TestFlight) і скидати її до 0, коли ви змінюєте CFBundleShortVersionString.

Ви повинні чітко планувати або розробити послідовні засоби оновлення видимої для користувача версії в CFBundleShortVersionString.