配置不要写在代码中，使用默认配置发布并允许 OTA 升级配置

在 Github 上编辑

应用配置应该是两次部署（App Store，TestFlight，开发环境）之间仅有的变化部分，或者是随着时间推移而不随着底层代码而改变的部分。它包括：

  • 后台服务 API 的 key（无论是对内还是对外服务）；
  • 远程资源的 URL（即应用使用的 API）；
  • 功能开关。

应用配置有时候在代码中使用常量保存，这与 iOS-factor 的要求相违背。我们认为配置与代码需要严格分离。每次部署可能会更改配置部分，但代码部分则应完全一致。

判断一个应用的配置是否正确地独立于代码，一个简单的方法是看该应用的基准代码是否可以立刻开源，而不用担心暴露任何敏感信息。

在编译期注入配置的手段有很多种

  • 使用配置文件（如JSON、YAML）；
  • 使用 cocoapods-keys 可以更好隐藏键，并在 iOS 应用的编译期使用；
  • 自定义的编译方案（如使用 build phase）。

iOS 平台的部署周期明显要长于服务器的部署周期，所以你可能想用 OTA 的方式对配置进行更新，以对问题进行快速响应。

通过 OTA 更新配置非常强大，并且可以让你立即完成以下事情：

  • 开启特定的功能运行 A/B 测试，或者仅对一部分活跃用户进行一些 UI 上的改变；
  • 轮换使用 API key；
  • 更新网站主机地址或者其它已经改变的 URL；
  • 远程关闭功能或者隐藏按钮。

如果没有 OTA 升级，则需要等待应用通过审核上架后才能见效。而每次提交审核都增加了被拒的风险，并潜在影响紧急版本的发布。

同时，应用也应具备后向兼容性，因为那些不能升级到最新 iOS 系统版本的用户可能压根就无法更新应用。通过提供 OTA 更新，你可以持续为应用的较老版本提供支持。

实现 OTA 更新配置的一些可能的方案：