我们正在考虑在 iOS 应用程序的下一个版本中更改版本号，从使用传统的 Major.Minor.Patch 版本号方案改为使用基于日期的方案，例如 2012.month.patch，以更好地反映给我们的用户应用的货币。
苹果在iTunes Connect中唯一的版本号指引如下：
您要添加的应用的版本号。编号应遵循 典型的软件版本控制约定（例如，1.0 或 1.0.1 或 1.1)。
我的问题 - 他们是否执行这种传统方案？
使用基于日期的方案有什么缺点吗？
在已广泛部署的应用上更改方案是否可能会出现任何问题？
更新：更多解释采用基于日期的版本控制方案的理由... 相关应用的更新主要是为了反映每年添加几次的新数据集.用户知道 2012.2 版本有当前数据很有用 - 2.6 版本没有传达这一点。
【问题讨论】：
标签： ios app-store versioning appstore-approval
Apple 方案通常是强制执行的，因为您的包会检查两次以确保正确的版本号（一次在验证时，一次在上传时）。如果不是通过苹果，根据普遍接受的传统。此外，如果您可以使用内部版本号字段，为什么还要超出建议的小数位？
无论如何，只有一个陷阱。有时，iTunes Connect 会遇到小数位两位数的问题。我的意思是，V1.1 和 V1.10 有时会显示为相同的版本（因为忽略了零）。但是，V1.11 很好。
根据您的建议，这似乎有点古怪，但我会继续尝试。应用商店不会显眼地显示版本号（软件更新期间除外，即便如此，它也是一个字幕），所以我敢打赌它可能会溜走。如果需要，只需修改应用名称以反映年份即可。
【讨论】：
根据我的经验，除了第一个版本不低于 1.0 并且您不能发布较低编号的版本之外，他们不会强制执行。
传统方案的优势在于，它侧重于可以按照您的节奏更新的功能，而不是总是滴答作响且变化太快的日期。很容易判断该版本相对于其他版本的适合位置以及更短的使用日期。
你为什么想要？如果您将 2012.02.08 提交到应用商店但直到 2 月 15 日才获得批准，那么立即就会出现差异。应用商店列出了应用上次更新的日期，您的用户可以阅读该日期或您的网站。
如果您定期更新它，并且他们下载更新，那么我相信他们会收到您的应用经常更新的消息。我当然会注意到应用程序何时更新。除了在下载时或在应用程序中实际看到版本号之外，将版本号更改为日期并不能帮助他们知道它经常更新。
【讨论】：
在做了一些研究以提交我的第一个构建之后，我正在写这篇文章。
首次上传应用不能低于1.0（不允许测试版想法） 每次后续上传都应至少增加一
允许的最大子版本格式为 X.X.X（其中 X 只能是数字） 没有字母
在存档上传到应用商店之前，确保Info.plist文件中所有与版本相关的参数中只有一个版本号
【讨论】：
我想对此发表评论是说使用 year.month.day 版本控制方案很好。
我检查了我的手机，看看谁在做类似的事情，这就是我发现的：
ideviceinstaller -l | grep 2020
com.bestbuy.buyphone, "202003261603", "Best Buy"
com.google.Docs, "1.2020.10202", "Docs"
com.huang.speedtest, "2020043002", "Oka Speed Test"
com.alibaba.iAliexpress, "8.7.1.2020031010", "AliExpress"
com.wayfair.WayfairApp, "20200326.72595", "Wayfair"
com.nguyenvh.holeio, "202003271450", "Hole.io"
com.adobe.Adobe-Reader, "20200326.133802", "Acrobat"
com.clearchannel.iheartradio, "2020022503", "iHeartRadio"
com.google.Sheets, "1.2020.12203", "Sheets"
com.google.Classroom, "2.2020.12205", "Classroom"
【讨论】：