我应该为CFBundleVersion和CFBundleShortVersionString使用什么值？

Question

这是我的第一个iOS应用提交,我不希望我的应用被拒绝.

这来自Apple Docs:

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%这是我应该放的吗？

Answer 1

CFBundleShortVersionString为您提供应用程序的版本.每次将应用程序发布到App Store时,它通常会增加.这是在应用程序的App Store页面的"Version"部分中可见的版本.

CFBundleVersion为您提供用于开发和测试的内部版本号,即"技术"目的.最终用户很少对构建号感兴趣,但在开发过程中,您可能需要知道每个构建上正在开发和修复的内容.这通常在内部发布的每次迭代时递增.您可以使用像Jenkins这样的持续集成工具来自动增加每个构建的构建号.

这两个数字并不相互依赖,但最好保持它们平行以避免混淆.请记住,一旦您的应用程序通过App Store审核,您需要像Phil一样增加内部版本号,并且无论您是否发布它都会像TheSky所说的那样.

使用案例:假设你有一个经过良好测试的版本,可以提交.它的版本号是1.0.0,内部版本号是1.0.0.32.提交应用程序后,您需要将版本更新为1.0.1并将版本号更新为1.0.1.0.

Answer 2

可以这样想:"短版本"(CFBundleShortVersionString)是公共版本号."version"(CFBundleVersion)更多的是内部版本号,它可能比公共"短版本"更频繁地更改.我个人对两者使用相同,但很多人在每次构建时更新"版本".无论哪种方式,您通常都会在发布到Apple时更新"简短版本".您更新"版本"的频率取决于您和您的需求.

Answer 3

rmaddy的回答是正确的.我还要再添两个想法.

第三版本号

请注意iTunesConnect网站上指定的第三个版本号,作为应用程序定义的一部分.如果该号码与Xcode中的两个号码不同,Apple会向您发出警告.你可以忽略警告,因为它不是一个显示停止(不是"错误").

日期时间作为版本

此外,您不需要使用带标点符号的三个数字.这可能适用于某些应用程序,传统上第一个数字的变化表明通常会影响兼容性的某种戏剧性变化.

对于其他应用程序,您可能只想使用ISO 8601标准格式样式(YYYYMMDDHHMM)的日期时间值.例如,201606070620.年 - 月 - 日 - 小时 - 分钟的顺序呈现一个不断增加的数字,由于填充零而总是相同的长度,按字母顺序排序也是按时间顺序排列的.

我已经在iOS 7,8和9中运行的iOS应用程序中成功使用了这种版本号.

您甚至可以自动生成此值.在您的项目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线#.

Answer 4

I use CFBundleVersion to indicate internal build for CFBundleShortVersionString. I use test flight to submit builds for my testers so the difference between them has been extremely useful.

苹果文件说CFBundleVersion“应该是一个包含以下内容的字符串： 3 non-negative, period-separated integers" But actually it can be MORE THAN 3 parts(as the above answer shows). I use that to indicate my development build, say my CFBundleShortVersionString is 1.0.0, I can use 1.0.0.11 for CFBundleVersion to indicate that is my 11th build for release 1.0.0

Each CFBundleVersion submitted to app store should be bigger than before or you will get ERROR ITMS-90478: "Invalid Version. The build with the version “xxx” can’t be imported because a later version has been closed for new build submissions. Choose a different version number."

CFBundleShortVersionString can only have 3 parts or you will get ERROR ITMS-90060:The value for key CFBundleShortVersionString 'xxx' in the Info.plist file must be a period-separated list of at most three non-negative integers."

The 3rd number that Basil Bourque mentioned, i.e. the version number shows on iTunesConnect is where things may get complicated.

I use a different iTunesConnect number than CFBundleShortVersionString because when I first submitted my app to app store we already have many rounds of internal releases. So I used 1.0 for iTunesConnect number and 5.x for CFBundleShortVersionString. In the next release to app store I provided a function to check if there is a newer version in the app store and realized I had trouble now because I can only get iTunesConnect number (using http://itunes.apple.com/lookup?bundleId=) so I need to do some calculation to before compare it with CFBundleShortVersionString number.

I tried to fix that by using iTunesConnect number as my CFBundleShortVersionString, but got the error, ERROR ITMS-90062: "This bundle is invalid. The value for key CFBundleShortVersionString [x.x.x] in the Info.plist file must contain a higher version than that of the previously approved version [x.x.x]."

So I will suggest always make them the same.

Answer 5

对我而言，最明智的方案是使用版本号（即CFBundleShortVersionString）作为实际版本号，然后使用内部版本号（即CFBundleVersion）代表提交到App Store的提交。因此，除非有任何问题，然后重新提交，否则该数字始终为1。对于新发行版，如果以前的版本在TestFlight测试或审核中有问题，我将重置为1。

内部编号提供了一种方式来命名您为特定版本提供的每个提交。如以上定义中所述，您为应用程序的特定版本提供的所有构建的集合称为该版本的“发行版”。对于iOS应用，内部版本号在每个发行版中必须唯一，但是在不同发行版中不需要唯一。这就是说，对于iOS应用程序，您可以根据需要在不同的发行版中再次使用相同的内部版本号。

摘自TN2420技术说明：版本号和内部版本号。

Answer 6

我从未在任何地方讨论过的问题是CFBundleVersion中每个字段的最大数量是多少？

通过将应用程序中的CFBundleVersion设置为1.1.1并查看“ lsregister -dump”中版本的十六进制值，我确定第一个字段的最大值为（2 ^ 22）-1或4194303，最大值第二个和第三个字段的值是（2 ^ 21）-1或2097151。

3个字段总计为64位。

这对我们这些根据日期和时间使用CFBundleVersion的人有影响。

我将第一个字段设置为YYYYMMDD。这总是大于允许的最大版本，并且至少在启动服务决定要运行哪个版本的应用程序时，至少安装了多个版本并且使用了诸如'open -a Appname之类的东西，这至少导致了无法预测的结果。从命令行。

请广泛传播。我相信很多人对此都不会感到困惑。

Answer 7

截至目前，AppleCFBundleVersion各州的文档[强调我的]：

标识包迭代的构建版本。

...

此键是由一到三个以句点分隔的整数组成的机器可读字符串，例如 10.14.1。该字符串只能包含数字字符 (0-9) 和句点。

...

您可以包含更多整数，但系统会忽略它们。

对于CFBundleShortVersionString[强调我的]：

捆绑包的发行版或版本号。

...

此键是捆绑版本的用户可见字符串。所需的格式是三个以句点分隔的整数，例如 10.14.1。该字符串只能包含数字字符 (0-9) 和句点。

我建议CFBundleVersion为每个构建（或每个 TestFlight 版本）自动递增，并在更改时将其重置为 0 CFBundleShortVersionString。

您应该明确计划或设计一致的方法来更新CFBundleShortVersionString.