我们正在考虑使用传统的Major.Minor.Patch版本号方案更改iOS应用的下一版本中的版本号，而不是使用基于日期的方案（例如2012.month.patch）来更好地反映给我们的用户应用程序的货币。
Apple iTunes在iTunes Connect中唯一的版本号指南如下：
您要添加的应用的版本号。编号应遵循 典型的软件版本控制约定（例如，1.0或1.0.1或 1.1）。
我的问题 - 他们是否执行这一传统计划？
使用基于日期的方案有什么不利之处吗？
在已广泛部署的应用程序中，是否有任何可能因更改方案而出现的问题？
更新更多地解释了进入基于日期的版本控制方案的理由......有问题的应用程序主要更新，以反映每年添加几次的新数据集。对于用户来说，知道版本2012.2具有当前数据是有用的 - 版本2.6没有传达它。
答案 0 :(得分：5)
苹果计划通常是强制执行的，因为您的捆绑包会被检查两次以获取正确的版本号（一次在验证时，一次在上传时）。如果不是苹果，通过普遍接受的传统。此外，如果您可以使用内置编号字段，为什么还需要超出推荐的小数位？
无论如何，只有一个问题。有时，iTunes Connect在小数位时会出现两位数的问题。我的意思是，V1.1和V1.10有时会显示为相同的版本（因为零被忽略）。但是，V1.11很好。
根据你的建议，它看起来有些古怪，但我会继续尝试。应用程序商店并没有突出显示版本号（除非在软件更新期间，即使这样，它也是一个副标题），所以我敢打赌它可能只是滑过。如果需要，只需修改应用程序的名称即可反映年份。
答案 1 :(得分：3)
根据我的经验，除了第一个版本不低于1.0且您无法发布编号较低的版本外，他们不会强制执行。
传统方案的优势在于它专注于可以按您的速度更新的功能，而不是始终嘀嗒作响并且变化太快的日期。很容易判断发布与其他版本相关的位置以及更短的使用日期。
你为什么要这样？如果您将2012.02.08提交到应用商店但直到2月15日才获得批准，则会立即出现差异。应用程序商店列出了应用上次更新的日期，您的用户可以阅读该网站或您的网站。
如果您定期更新，并下载更新，那么我相信他们会收到您的应用经常更新的消息。当我更新应用时，我当然会注意到除了在下载或在应用程序中实际查看版本号时，将版本号更改为日期并不能帮助他们知道它经常更新。
答案 2 :(得分：0)
在进行了一些研究以提交我的第一个版本之后，我正在写这篇文章。
该应用程序的首次上传不能小于 1.0 （不允许beta版本的想法） 以后的每次上传都应至少增加一个
允许的最大子版本格式为 X.X.X （其中X只能是数字） 没有字母
在存档以上传到应用商店之前，请确保Info.plist文件中所有与版本相关的参数中仅跟随一个版本号
答案 3 :(得分：0)
我想对此发表评论说使用 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"