pka*_*amb 93 itunesconnect app-store ios mac-app-store
iOS应用的版本/构建字段包括:
"Version" CFBundleShortVersionString(String - iOS,OS X)指定捆绑包的发布版本号,该版本号标识应用程序的已发布迭代.发行版本号是由三个以句点分隔的整数组成的字符串.
"Build" CFBundleVersion(String - iOS,OS X)指定捆绑包的构建版本号,该版本号标识捆绑包的迭代(已发布或未发布).构建版本号应该是由三个非负的,周期分隔的整数组成的字符串,第一个整数大于零.该字符串应仅包含数字(0-9)和句点(.)字符.前导零从每个整数中截断,将被忽略(即1.02.3相当于1.2.3).此密钥不可本地化.
"iTunes Connect版本号":在iTunes Connect上创建应用程序的新版本时指定的版本号.
我的问题是:
当新版本的应用程序上传到iTunes Connect和/或发布到App Store时,需要增加哪些版本/内部版本号?
应用更新之间的"版本" CFBundleShortVersionString
或"构建"可以CFBundleVersion
保持不变吗?
Apple来源的额外积分或iTunesConnect在上传无效版本/内部版本号时显示的确切错误消息.
促使这个问题的讨论是,在谷歌Android应用的大众"版本" Play商店并没有需要递增,是没有办法验证.该android:versionName
可不同版本之间保持不变,升级,降级,或者是任何随机字符串,而不是东西,似乎是一个有效的"版本号".
android:versionName
- 表示应用程序代码的发行版本的字符串值,因为它应显示给用户.该值是一个字符串,以便您可以将应用程序版本描述为
<major>.<minor>.<point>
字符串,或任何其他类型的绝对或相对版本标识符.
Android中versionName和versionNumber之间的区别
而android:versionCode
强制执行是一个递增的释放整数.
正如新接受的回答中所述,Apple最近发布了一份技术说明,详细说明了他们的版本和内部版本号:
Aec*_*Liu 95
Version
,Build number
)必须是唯一的.
Version
(CFBundleShortVersionString)必须按升序排列.Build number
(CFBundleVersion)必须按升序排列.版本号和内部版本号清单
在向App Store提交新版本时,您可以检查以下内容.确保正确设置版本号和内部版本号可以避免因为不正确配置应用程序而自动拒绝您的应用程序.
- 对于每个新版本的应用程序,您需要发明一个新的版本号.此数字应该比您使用的最后一个版本号更大.虽然您可以为应用程序的任何特定版本提供许多构建,但您只需为每个新版本的应用程序使用一个新版本号.
- 您无法重复使用版本号.
- 对于您提交的每个新构建,您将需要发明一个新的构建号,其值大于您使用的最后一个构建号(对于相同的版本).
- 您可以在不同的版本系列中重复使用Build Number,但不能在同一版本系列中重复使用Build Number.
根据检查表,以下(Version, Build Number)
顺序也是有效的.
案例:Build Number
在不同的发布列车中重复使用
(1.0.0,1) - >(1.0.0,2) - > - >(1.0.0,11) - >(1.0.1,1) - >(1.0.1,2)
And*_*ndy 37
本CFBundleShortVersionString
应与你给iTunes Connect中的版本号.它也是用户在App Store中查看您的应用程序时显示的版本号.
版本号显示在商店中,该版本应与稍后在iTunes Connect中输入的版本号相匹配.
该CFBundleVersion
不会在App Store中显示,但使用的iTunes来决定的程序进行了更新.
如果您更新构建字符串,如"设置版本号和构建字符串"中所述,则iTunes会识别构建字符串已更改并正确地将新的iOS App Store Package同步到测试设备.
更具体地回答你的问题......
将新版本的应用程序上传到应用商店时,需要增加哪些版本/内部版本号?
都.一个显示在App Store中,另一个用于iTunes更新App.
应用更新之间CFBundleShortVersionString或CFBundleVersion可以保持不变吗?
没有.(元问题,这里的用例是什么?如果你以任何方式编辑了有效负载,那么构建将会有所不同,用户会想知道它).如果您尝试,您将看到如下错误消息:
或者是否将它们与之前的相应数字进行比较,以确保使用新版本的应用程序上传数字更大的数字?
是.使用semver.org标准.
CFBundleShortVersionString和CFBundleVersion数字是否以任何方式相互比较?
没有.
Gab*_*iel 30
CFBundleShortVersionString是版本的公共"名称"(例如:"2.5"或"3.8.1").您必须在每个版本中增加它.
CFBundleVersion是私有内部版本号.它在AppStore上没有出现.您必须在每次上传时增加它.这意味着如果您在二进制文件上线之前拒绝它,并且您想要上传新的二进制文件,它将具有相同的CFBundleShortVersionString但必须具有更高的CFBundleVersion(例如:public"2.5",private"2.5",然后二进制拒绝,并重新上传私有"2.5.1")
/ !\ CFBundleVersion属性也在代码中由NSURLConnection发送的标头中使用(以及CFBundleName).User-Agent
示例:如果CFBundleName是MyApp且CFBundleVersion是2.21,那么您的代码使用NSURLConnection直接发送的任何编程HTTP查询都将嵌入标题:
User-Agent: MyApp/2.21 CFNetwork/... Darwin/...
(这不适用于UIWebView自动发出的请求).
CFBundleVersion和CFBundleShortVersionString必须大于应用程序的最后版本号.让它们保持一致是一种很好的做法.你应该在你的-info.plist中找到它们.
当您尝试在管理器中验证应用程序时,如果其中任何一个尚未递增,则会引发错误.昨晚发生在我身上.
无论CFBundleVersion
和CFBundleShortVersionString
必须发布新版本在App Store时递增.
此外,其中一个字符串必须与iTunes Connect中指定的版本匹配.
这个问题包括Xcode的组织者的验证上面的截图拒绝验证的应用程序时,CFBundleVersion
并CFBundleShortVersionString
没有增加.
此捆绑包无效.CFBundleVersion
Info.plist文件中key [1.0] 的值必须包含比以前上载的版本[1.134]更高的版本.
此捆绑包无效.CFBundleShortVersionString
Info.plist文件中key [1.0] 的值必须包含比以前上载的版本[1.134]更高的版本.
验证器还会抛出一个错误,证明其中一个字符串必须与iTunes Connect上创建的应用程序版本匹配.
当前的Apple 技术说明 TN2420、版本号和内部版本号显示(我用粗体显示):
- 对于 iOS 应用程序,您可以在不同的版本系列中重复使用内部版本号,但不能在同一版本系列中重复使用内部版本号。对于 macOS 应用程序,您不能在任何版本系列中重复使用内部版本号。
不幸的是,这意味着当您尝试在 Mac Catalyst 上发布相同的版本时,您无法在 iOS 上重复使用跟踪发布序列号的版本号。
例如,就我而言,由于一些早期问题,我最终将 1.0.2(4) 作为 Mac Catalyst 应用程序发布,与 iOS 上的 1.0.2(1) 相对应。现在,当尝试在两者上发布 1.0.3(1) 时,该应用程序在 MacOS 上由于内部版本号而无法通过验证,而在 iOS 上却通过了验证。
我想现在我会定期在 iOS 和 MacOS 上发布相同的应用程序,我将采用与日期相对应的内部版本号,例如 20200111,如果我需要更改给定版本中的内部版本号,则以小数点递增。
归档时间: |
|
查看次数: |
71482 次 |
最近记录: |