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

时间：2013-11-01 12:42:58

标签： ios

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

这是来自Apple Docs：

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

CFBundleShortVersionString （字符串 - iOS，OS X）指定捆绑包的发行版本号，用于标识应用程序的已发布迭代。发行版本号是由三个以句点分隔的整数组成的字符串。第一个整数表示对应用程序的主要修订，例如实现新功能或主要更改的修订。第二个整数表示实现不太突出的功能的修订。第三个整数表示维护版本。

此键的值与“CFBundleVersion”的值不同，后者标识应用程序的迭代（已释放或未释放）。可以通过将其包含在InfoPlist.strings文件中来对此密钥进行本地化。

但似乎有点奇怪。我对此的解释是将两个值相同，即：

CFBundleVersion: 1.0.0
CFBundleShortVersionString: 1.0.0

有人可以确认100％这是我应该放的吗？

7 个答案:

答案 0 :(得分：92)

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

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

Version and Build numbers

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

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

答案 1 :(得分：63)

以这种方式思考：“短版本”（CFBundleShortVersionString）是公共版本号。 “版本”（CFBundleVersion）更多的是内部版本号，它可能比公共“短版本”更频繁地更改。我个人对两者使用相同，但很多人在每次构建时更新“版本”。无论哪种方式，您通常都会在发布到Apple时更新“简短版本”。您更新“版本”的频率取决于您和您的需求。

答案 2 :(得分：12)

answer by rmaddy是正确的。我还要再添加两个想法。

第三版本号

请注意iTunesConnect网站上指定的第三个版本号，作为应用程序定义的一部分。如果该号码与Xcode中的两个号码不同，Apple会向您发出警告。你可以忽略这个警告，因为它不是一个show-stopper（不是＆＃34;错误＆＃34;）。

日期 - 时间版本

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

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

我已成功在iOS 7,8及以上版本的运费iOS应用中使用此款式的版本号码9。

您甚至可以自动生成此值。在您的项目中Target＆gt; Build Phases＆gt; Run Script小组：

  1. 在Shell字段中指定：/bin/sh
  2. 粘贴下面的5行脚本。
  3. （可选）选中Show environment variables in build log复选框。
  4. 取消选中Run script only when installing复选框。

    5. 每次进行构建时，都会捕获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行注释掉前面的#。

答案 3 :(得分：5)

我使用 CFBundleVersion 来指示 CFBundleShortVersionString 的内部版本。我使用测试飞行为我的测试人员提交构建，因此它们之间的差异非常有用。

Apple文档称CFBundleVersion＆＃34;应该是一个由 3 非负周期分隔整数组成的字符串＆＃34;但实际上它可以超过 3个部分（如上面的答案所示）。我使用它来表示我的开发构建，比如我的CFBundleShortVersionString是1.0.0，我可以使用1.0.0.11 for CFBundleVersion来表明这是我发布1.0.0的第11版

提交给应用商店的每个CFBundleVersion应该比以前更大，否则您将获得错误ITMS-90478 ：＆＃34;无效版本。无法导入版本为“xxx”的构建，因为已为新构建提交关闭了更高版本。选择其他版本号。＆＃34;

CFBundleShortVersionString 只能有3个部分，否则您将获得ERROR ITMS-90060：密钥CFBundleShortVersionString＆＃39; xxx＆＃39;在Info.plist文件中必须是一个以句点分隔的最多三个非负整数的列表。＆＃34;

Basil Bourque提到的第三个数字，即 iTunesConnect 上显示的版本号，可能会让事情变得复杂。

我使用与 CFBundleShortVersionString 不同的iTunesConnect编号，因为当我第一次将我的应用程序提交到应用程序商店时，我们已经有多轮内部版本。所以我使用1.0作为iTunesConnect编号，使用5.x作为CFBundleShortVersionString。在app Store的下一个版本中，我提供了一个函数，用于检查应用商店中是否有更新的版本，并意识到我现在遇到了麻烦，因为我只能获取iTunesConnect号码（使用http://itunes.apple.com/lookup?bundleId=）所以我需要做一些计算到将它与CFBundleShortVersionString数字进行比较之前。

我试图通过使用iTunesConnect号码作为我的CFBundleShortVersionString来解决这个问题，但是得到了错误，错误ITMS-90062 ：＆＃34;此捆绑包无效。 Info.plist文件中密钥CFBundleShortVersionString [x.x.x]的值必须包含高于先前批准的版本[x.x.x]的版本。＆＃34;

所以我建议总是让它们一样。

答案 4 :(得分：4)

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

  

内部版本号提供了一种方法，可以为您为特定版本提供的每个提交内容命名。如上面的定义所述，您为特定版本的应用程序提供的所有构建版本的集合称为该版本的版本列表＆＃39;。对于iOS应用程序，构建编号在每个版本系列中必须是唯一的，但它们不需要在不同的版本列表中是唯一的 [我的重点]。也就是说，对于iOS应用程序，如果您愿意，可以在不同的版本系列中再次使用相同的版本号。

来自Technical Note TN2420: Version Numbers and Build Numbers。

答案 5 :(得分：2)

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

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

3个字段加起来为64位。

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

我将第一个字段设置为YYYYMMDD。这总是大于最大允许版本，并且它导致不可预测的结果，至少可以说，当启动服务决定在安装了多个版本时运行的应用程序版本并使用类似'open -a Appname的内容时'从命令行。

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

答案 6 :(得分：0)

到目前为止，the Apple documentation for CFBundleVersion指出[重点是我]：

  

标识捆绑软件迭代版本的构建版本。

     

...

     

此密钥是机器可读的字符串，由 1-3个以句点分隔的整数组成，例如10.14.1。该字符串只能包含数字字符（0-9）和句点。

     

...

     

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

对于CFBundleShortVersionString [强调我的]：

  

捆绑软件的发行版或版本号。

     

...

     

此密钥是捆绑软件版本的用户可见的字符串。所需的格式为三个句点分隔的整数，例如10.14.1。该字符串只能包含数字字符（0-9）和句点。

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

您应该明确计划或设计一致的方式来更新CFBundleShortVersionString中用户可见的版本。

相关问题
最新问题