Question

iOS应用的版本/构建字段包括：

“版本” CFBundleShortVersionString （字符串 - iOS，OS X）指定捆绑包的发布版本号，该版本号标识应用程序的已发布迭代。发行版本号是由三个以句点分隔的整数组成的字符串。
“构建” CFBundleVersion （字符串 - iOS，OS X）指定捆绑包的构建版本号，该版本号标识捆绑包的迭代（已发布或未发布）。构建版本号应该是由三个非负的，周期分隔的整数组成的字符串，第一个整数大于零。该字符串应仅包含数字（0-9）和句点（。）字符。前导零从每个整数中截断，将被忽略（即1.02.3相当于1.2.3）。此密钥不可本地化。
“iTunes Connect版本号”：在iTunes Connect上创建新版应用时指定的版本号。

我的问题是：

当新版本的应用程序上传到iTunes Connect和/或发布到App Store时，哪些版本/内部版本号需要递增？

“版本”CFBundleShortVersionString或“构建”CFBundleVersion可以在应用更新之间保持不变吗？

Apple来源的额外积分或iTunesConnect在上传无效版本/内部版本号时显示的确切错误消息。

Android / Google Play注意：

提示此问题的讨论是，Google Play商店中Android应用的公开“版本”不需要递增并且无法验证。 android:versionName在版本，升级，降级或任何随机字符串之间可以保持不变，而不是看似有效的“版本号”。

android:versionName - 一个字符串值，表示应用程序代码的发布版本，因为它应该向用户显示。

该值为字符串，以便您可以将应用程序版本描述为<major>.<minor>.<point>字符串，或绝对或相对版本标识符的任何其他类型。

Difference between versionName and versionNumber in Android

而android:versionCode被强制为增量释放整数。

Apple文档

如the newly accepted answer所述，Apple最近发布了一份技术说明，详细说明了其版本和内部版本编号方案：

Apple Technical Note TN2420 - Version Numbers and Build Numbers

Answer 1

Apple Technical Note TN2420, Version Numbers and Build Numbers

要点：

该对（Version，Build number）必须是唯一的。
- 序列有效：（1.0.1,12） - ＆gt; （1.0.1,13） - ＆gt; （1.0.2,13） - ＆gt; （1.0.2,14）......
Version（ CFBundleShortVersionString ）必须按升序排列。
Build number（ CFBundleVersion ）必须按升序排列。

版本号和内部版本号清单

在向App Store提交新版本时，您可以检查以下内容。确保正确设置版本号和内部版本号可以帮助您避免让应用程序因配置不当而自动被拒绝。


对于每个新版本的应用，您需要发明一个新的版本号。此数字应该比您使用的最后一个版本号更大。虽然您可以为应用程序的任何特定版本提供许多构建，但您只需为每个新版本的应用程序使用一个新版本号。

您无法重复使用版本号。

对于您提交的每个新版本，您需要发明一个新的版本号，其值大于您使用的最后一个版本号（对于相同版本）。

您可以在不同的版本系列中重复使用Build Number，但不能在同一版本系列中重复使用Build Number。

根据核对表，以下(Version, Build Number)序列也有效。

案例：在不同的释放列车中重复Build Number。

（1.0.0,1） - ＆gt; （1.0.0,2） - ＆gt; ... - ＆gt; （1.0.0,11） - ＆GT; （ 1.0.1 ， 1 ） - ＆gt; （1.0.1,2）

Answer 2

CFBundleShortVersionString应与您为iTunes Connect提供的版本号相匹配。它也是用户在App Store中查看您的应用程序时显示的版本号。

版本号显示在商店中，该版本应与您稍后在iTunes Connect中输入的版本号相匹配。

Source

CFBundleVersion未显示在App Store中，但iTunes会使用它来确定您的应用程序何时更新。

如果您更新构建字符串，如“设置版本号和构建字符串”中所述，则iTunes会识别出构建字符串已更改并正确地将新的iOS App Store Package同步到测试设备。

Source

更具体地回答你的问题......

将新版应用上传到应用商店时，需要增加哪些版本/内部版本号？

两者。一个显示在App Store中，另一个用于iTunes以更新App。

CFBundleShortVersionString或CFBundleVersion可以在应用更新之间保持不变吗？

没有。（元问题，这里的用例是什么？如果你以任何方式编辑了有效负载，那么构建将会有所不同，并且用户会想知道它）。如果您尝试，您将看到如下错误消息：

Error messages

或者是否将它们与之前的相应数字进行比较，以确保使用新版本的应用程序上传数字更大的数字？

是。使用semver.org标准。

CFBundleShortVersionString和CFBundleVersion数字是否以任何方式相互比较？

没有

Answer 3

CFBundleShortVersionString 是公共＆＃34;名称＆＃34;版本（例如：＆＃34; 2.5＆＃34;或＆＃34; 3.8.1＆＃34;）。您必须在每次发布时增加它。

CFBundleVersion 是私人构建号码。它在AppStore上没有出现。您必须在每次上传时增加它。这意味着如果您在二进制文件上线之前拒绝它，并且您想要上传新的二进制文件，它将具有相同的 CFBundleShortVersionString ，但必须具有更高的 CFBundleVersion （例如：public＆＃34; 2.5＆＃34;，private＆＃34; 2.5＆＃34;，然后二进制拒绝，并重新上传私有＆＃34; 2.5.1＆＃34;）

2016年11月16日编辑：

/ ！ \ {strong> CFBundleVersion 属性也在User-Agent标头User-Agent: MyApp/2.21 CFNetwork/... Darwin/...标头中使用（以及 CFBundleName ） 3}}在您的代码中。

示例：如果 CFBundleName 是 MyApp 且 CFBundleVersion 是2.21，那么您的代码使用{{3}直接发送的任何编程HTTP查询将嵌入标题：

（这不适用于UIWebView自动发出的请求。）

Answer 4

CFBundleVersion和CFBundleShortVersionString必须大于应用程序的最后版本号。让它们保持一致是一种很好的做法。你应该在你的-info.plist中找到它们。

当您尝试在管理器中验证应用程序时，如果其中任何一个尚未递增，则会引发错误。昨晚发生在我身上。

Answer 5

在向App Store发布新版本时，CFBundleVersion和CFBundleShortVersionString 必须才会增加。

此外，其中一个字符串必须与iTunes Connect中指定的版本匹配。

Xcode Organizer Validator error: must increment the version number.

This question包含Xcode Organizer的Validator的上述屏幕截图，拒绝在CFBundleVersion和CFBundleShortVersionString未增加时验证应用。

此捆绑包无效。 Info.plist文件中密钥CFBundleVersion [1.0]的值必须包含高于先前上载版本[1.134]的版本。
此捆绑包无效。 Info.plist文件中密钥CFBundleShortVersionString [1.0]的值必须包含高于先前上载版本[1.134]的版本。

验证程序还会抛出一个错误，证明其中一个字符串必须与iTunes Connect上创建的应用程序版本匹配。

版本不匹配。 Info.plist中的CFBundleVersion ['1.0']和CFBundleShortVersionString ['1.0']都不匹配iTunes Connect ['1.4']中设置的应用程序的版本。

Answer 6

当前Apple Technical Note TN2420, Version Numbers and Build Numbers说（我的粗体）：

对于iOS应用，您可以在不同的发行版中重复使用内部版本号，但是不能在同一发行版中重新使用内部版本号。 对于macOS应用，您无法在任何发行版中重复使用内部版本号。

不幸的是，这意味着当您试图在Mac Catalyst上发布同一版本时，您将无法重用跟踪到iOS上发行版本号的内部版本号。

例如，由于某些较早的问题，我最终以Mac Catalyst应用程序发布了1.0.2（4），它与iOS上的1.0.2（1）相对应。现在，当尝试同时在两个版本上发布1.0.3（1）时，由于内部版本号，该应用在MacOS上无法通过验证，而在iOS上通过了验证。

现在我猜想我将定期在iOS和MacOS上发布相同的应用程序，如果需要在给定的范围内更改内部版本号，我将采用与日期相对应的内部版本号，例如20200111，并以小数点递增释放。

Answer 7

您需要增加两者。

上传新版本时，您需要在iTunes Connect上创建一个新版本，该版本会自动高于之前的版本。 iTunes Connect上的此版本将需要具有相同版本号的二进制文件，因此CFBundleShortVersionString需要递增。

如果您更新版本但忘记增加CFBundleVersion，则在上传过程中会遇到错误。请参阅pkamb的答案和屏幕截图。

有关CFBundleShortVersionString和CFBundleVersion的详细信息，请参阅：https://stackoverflow.com/a/31921249/936957

Answer 8

经过两种方式的尝试，我可以确认一系列版本和内部版本号，例如...

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

...将被iOS应用接受，但对于Mac（Catalyst）应用，它将返回此错误：

错误ITMS-90061：“此捆绑包无效。Info.plist文件中的CFBundleVersion键[1]的值必须包含比先前上传的版本[2]更高的版本。”

Mac版本和内部版本号需要像...

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

对于iOS，我通常输入内部版本号作为版本号加第四个数字，例如...

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

...但是Mac应用程序也不允许这样做。当我尝试提交我的第一个Mac（Catalyst）应用程序时，Apple只接受三位数或更少位数的内部版本号：

错误ITMS-9000：“此捆绑包无效。Info.plist文件中键CFBundleVersion [1.0.0.1]的值必须是一个由句点分隔的列表，该列表最多由三个非负整数组成。”

因此，我更改为一个数字，该数字在每次构建时都会递增，并在各个版本号之间继续递增。

Answer 9

我正准备发布一个新的Mac App Store应用程序。使用YEAR.release (build)的{{3}}格式。

我上传了多个版本：2020.0 (1)，2020.0 (2)等。我最终提交了2020.0 (8)进行App Store审查。通过审核并处于待开发人员发布状态。

我想在发行前修复一些问题，因此我在同一发行版中添加了一个新版本：2020.0 (9)。

这会导致错误：

App Store Connect操作错误

错误ITMS-90062 ：“此捆绑包无效。Info.plist文件中的密钥CFBundleShortVersionString [2020.0]的值必须包含比先前批准的版本更高的版本。版本[2020.0]。请在CalVer“
中找到有关CFBundleShortVersionString的更多信息

这很烦人，因为我的2020.0版本从未真正发布过。从这个问题的公认答案中，我得到的印象是，在App Store上可用之前，您可以继续发布具有相同版本的新版本。

解决方案似乎是，如果应用程序状态为待开发人员发布，则无法更新“发行版”（相同版本+新版本）。要么发布您现有的版本，然后增加版本，要么在App Store Connect中取消此版本，以允许对该版本系列进行进一步的上传。

Answer 10

AFAIK，在我的头顶，您只需要增加内部版本号CFBundleVersion。不一定需要增加短版本字符串，但您可能应该增加它，因为它会告诉用户应用程序是新的。 Apple确实说编号应遵循传统的软件版本规范，但如果您尝试重新上传已有的版本，iTunes Connect可能会抱怨。

长话短说，它可能有用，但可能不行。

在App Store发布时，哪个iOS应用程序版本/内部版本号必须递增？

Android / Google Play注意：

Apple文档

10 个答案:

要点：

版本号和内部版本号清单

2016年11月16日编辑：