前言: 我同意这里的其他帖子,您不能通过 iTunes Connect 本身执行回滚。即使可以,您也会遭受用户更新到回滚版本所需的延迟时间。但这并不意味着我们仍然不能回滚应用程序。
追溯,您不能回滚应用程序。但是,您可以主动检测您的应用,以便在发布和安装构建后启用未来的回滚。
高级步骤:
- 将应用程序的每个版本构建为框架
- 对于每个发布版本,包括当前和旧框架版本
- 在应用启动时,决定加载和执行哪个框架(包括合理的默认值)
- 当您想要回滚时,请更新所有用户设备的缓存值并等待下一个应用打开。
此策略使用与功能标志类似的机制,这些标志通常用于启用/禁用功能而无需重新发布。但是,在这种情况下,您是在“标记”整个应用版本。
嵌入式库之间的功能标记是否违反 App Store 指南?
没有。将您的应用的两个版本嵌入到一个版本中并不违反App Store review guidelines:
4.7 HTML5 游戏、机器人等
应用程序可能包含或运行未嵌入二进制文件的代码(例如
基于 HTML5 的游戏、机器人等),只要代码分发不是
应用程序的主要目的,代码不在商店中提供或
类似商店的界面,前提是软件 (1) 是免费的或
使用应用内购买购买; (2) 仅使用可用的功能
在标准的 WebKit 视图中(例如,它必须在本地打开和运行
Safari 无需修改或附加软件);你的应用必须
使用 WebKit 和 JavaScript Core 运行第三方软件,并且应该
不尝试向第三方扩展或公开原生平台 API
软件;
与功能标志类似,您计划运行的所有代码都包含在您提交以供审核的二进制文件中。此外,只要您回滚到 Apple 已经审核和批准的版本,就不会违反指南的精神。
这会影响性能吗?
我已经针对许多 popular and heavy open-source iOS apps (包括 Wikipedia、Signal、Firefox 等)分析了这种方法。您可以聪明地对资产和共享库进行重复数据删除,从而使夹层应用程序包大小约为 1.2 倍原始大小(实际上取决于您更改了多少代码)。在选择要启动的应用版本时,您还会产生大约 50 毫秒的启动成本。
IMO,时间和大小的增加都是值得的,以换取在您花时间实施修复时有选择地回滚遇到问题的用户的能力。
真正的应用会这样做吗?
在启动新功能和优化性能时,dylib 之间的主要应用程序功能标志一直存在。我还听说过大型科技公司在他们最大的版本中使用这种应用程序级模式。我在 App Store 中有一个使用这种模式的个人应用程序,并且我帮助其他开发人员也这样做了。
如何才能为他们的应用做到这一点
如果您愿意深入研究 Xcode 构建系统,您可以按照上面概述的步骤进行操作,并在启动时启动功能标记您的应用程序版本。请注意,您还需要某种形式的缓存和服务器端点来更新设备上的标志。
上述实现也正是screenplay.dev 实现iOS 回滚的方式。工具:
- 向您的 Xcode 项目添加两个构建目标,一个用于构建框架版本,一个用于捆绑最终版本构建。
- 用作旧应用构建版本的存储库。
- 提供用于切换实时版本的 Web UI。