管理一系列相关 iOS 应用程序的最佳实践

Posted 2023-03-13

【中文标题】管理一系列相关 iOS 应用程序的最佳实践

【英文标题】：Best practice for managing a family of related iOS apps

【发布时间】：2011-04-04 19:00:46

【问题描述】：

我目前正在将现有的 ios 应用程序改编成一系列非常相似的应用程序（每个应用程序实例可能会映射到不同的国家/地区）。

我计划为每个实例设置不同的构建目标，它们之间的唯一区别应该是：

图像（可能只是启动画面和图标） 本地化 字符串变量：远程服务的基本 URL、应用程序 ID、支持电子邮件等（可能有六个这样的变量）

代码本身在所有应用上都应该相同。

我想知道您认为管理此类应用程序家族的最佳做法。

关于图像和本地化（或一般的资源），应该只是从目标中添加/删除适当的文件（我想我什至可以在不同的目录中为图像使用相同的名称）。

我不确定的主要是其他配置变量。

我听说过/想到了几个选项：

使用预处理器宏和具有不同 URL、ID 等的主配置头文件 每当应用程序启动时从 plist（或类似的配置文件）加载它们，并且每个目标都有一个这样的文件 创建一个空的 .sqlite 文件（此应用已使用 Core Data）并使用默认配置变量填充它，并且每个目标都有一个这样的文件

我认为，一旦我有几个这个应用程序的实例，第一个选项是最快的，而且我每次更改这些设置时都必须重新编译。

我也不确定第三个选项，因为我将向我的数据库中添加不属于那里的实体，而且对于可能是 5-10 的设置来说，这有点矫枉过正.我也不确定如何在更新中添加新设置。

所以我更倾向于第二种选择。

想法？这些有什么替代品吗？

更新 #1：

关于第二个选项，还有一个缺点是这些字符串（id、URL 等）会比源代码中的字符串（即，如果有人打开应用程序并查看 plist）稍微暴露一些。代码。并不是说这是一个大问题，而是需要考虑的问题。

更新 #2：

直接使用应用程序的 info.plist 并将其存储在那里怎么样？ （因此每个目标配置都有一个 info.plist）即使最初我想有一个单独的 plist，并且有一个“配置单例”可以在启动时从那里加载所有内容，但我认为简单地拥有它可能更简单在 info.plist 中，然后通过 [[[NSBundle mainBundle] infoDictionary] objectForKey:@"com.example.mykey1"] 阅读。

【参考方案1】：

我会选择预处理器。您可以将所有预处理器放在一个文件/方法中，它不会太乱。就像 oefe 所说，更改 .sqlite 是矫枉过正。使用多个 plist，您会发现自己拖着东西到处走，并且做很多容易出错的操作。

然而，我不会制作很多应用程序。我只会制作一个应用程序，让用户在启动时选择他的城市。您还可以添加应用内购买，让用户在需要时添加更多城市。

您的应用将更易于维护：您想在每次更新时上传、更改 10 多个应用的​​描述和屏幕截图吗？我发现这与 1 个应用程序有关... 您不会向 AppStore 发送垃圾邮件：在 AppStore 中还有 10 多个具有完全相同目的的应用程序是荒谬的......这正是 Apple 进行应用程序内购买的原因，以避免这种情况。 您必须为每个城市找到不同的图标：在 AppStore 上销售您的应用时，您的图标是最重要的方面之一。您希望它尽可能抛光。 Apple 不会允许多个应用程序拥有相同的图标并通过在其上添加标签来区分图标不是一个好的选择。

【讨论】：

虽然我理解您关于不要制作大量应用程序的观点，但它们的内容（从远程服务器访问）使它们与众不同，甚至可能我们只发布每个应用程序App Store 中在其自己的国家/地区发布版本，而不是在其他国家/地区发布。我们更感兴趣的是让每个应用程序在自己的国家/地区具有吸引力，而不是制作一个可能对任何人都没有吸引力的通用应用程序。应用内购买也不适用于此处 - 这些都是免费应用。

预处理器也是我的第一选择，它很可能是最快的实现，我只是担心在 5-6 个不同的构建之后可能会出现混乱......

如果你只有 1 或 2 个地方做条件句，那就没那么乱了。我发现有6个同名文件比较乱...！

【参考方案2】：

我最终选择了 plist，但我没有创建一个新的 plist，而是使用了 info.plist 文件，因此每个目标不需要额外的文件，因为我已经需要为每个目标有一个单独的 info.plist一。我只是直接从包中加载它们：

[[[NSBundle mainBundle] infoDictionary] objectForKey:@"com.example.mykey1"]

我还使用了预处理器（在目标设置上设置了标志），但这主要是为了当我想完全禁用/删除应用程序的某些部分时（例如，以确保我得到了我评论的所有内容出枚举值，甚至包括在几个地方）。

我认为它相对干净，我可以轻松地将其复制到未来的构建中，而不会造成太多混乱。

【参考方案3】：

鉴于每个国家/地区的变化，并且这些变量是字符串，您为什么不简单地将它们视为可本地化的字符串，从而将问题简化为已经解决的问题？

否则，我会选择 plist。 Sqlite 似乎有点过头了，而且对源代码控制不友好。而且条件编译会很快变得混乱。

【讨论】：

没想到这一点，确实它会让事情变得简单......但我不确定我是否想将每个构建绑定到一个特定的（一组）语言（ s)。另外，关于 sqlite 源代码控制问题，我没有考虑过这一点。