让我们说我有一个iOS应用程序让我们说，足球新闻，现在我想为篮球新闻创建另一个版本，主要基于足球应用程序，但可以自由创建不同的行为在每个应用程序的某些方面+将来为其他新闻主题添加更多应用程序。
另一个条件是他们将拥有单独的CoreData模型，资产，图标等。
据我所知，我有几个选择：
每种选择的优缺点是什么？在这种情况下最佳做法是什么？
只是为了澄清 - 我提到的应用就是一个例子，应用不是新闻，，每个概念都必须是不同的应用。
由于
答案 0 :(得分：14)
我在企业环境中工作，我们有一个移动应用程序，它是我工作的公司的产品。我们向我们的客户销售该软件的许可证，这些客户总是巨大的公司。我们的应用程序没有通过App Store。
我们的每个客户都可以在应用上进行某种自定义，只需更改徽标或为其中一个添加某些特定功能即可。我的意思是：我们必须每天处理与你所描述的情况非常接近的情况，这是我的两分钱。
事先：对不起，如果我有时太诚实，我不是故意冒犯任何人。
<强> 1。单独管理应用程序，将它们放在同一目录中并指向第一个（足球应用程序）中的共享文件。
嗯......这是一个奇怪的解决方案，但它确实可行。在使用SVN / Git时（特别是在团队工作时），可能很难在本地维护甚至更难维护。
我之前遇到过与符号链接相关的一些问题，但我不确定这是否与您在此选项中引用的内容有关。如果你解释得更好一点，我可以编辑它并尝试给你一个更好的意见。
<强> 2。为同一项目中的每个应用创建不同的目标
在我看来，这是一个更好的开始。
我们主要使用这种方法来处理各种可能的后端服务器。例如，我们的一个目标使用我们的开发后端服务器，而另一个目标使用生产服务器。这有助于我们确保我们可以使用面向开发目标的应用程序而不会给我们的团队带来严重的成本（例如，由于错误下订单）。
在您的情况下，您可以在目标上配置预处理器宏，以启用/禁用某些特定于目标的功能，这些功能由代码调用。您还可以为每个目标使用不同的故事板。
这个选项的缺点是代码会很混乱，因为每一段代码都在同一个项目中。这是我选择＃3的主要原因。
第3。创建一个包含一个项目的工作区，该项目将包含公共代码和每个项目的项目。
同样，我也是这样做的。说实话，我们在YET公司没有使用这个，但这是由于内部原因。我想尽快为我们的项目做好准备。
我不会轻易地设置它，但如果操作得当，它可以帮助您节省一些时间，因为维护原因。您可以重用任何可以重复使用的代码，并且仍然可以将特定于目标的图像，类和视图保存到自己的容器＆＃34;（项目）中。
通过这种方式，您将获得一个默认项目（应用程序本身），多个目标，以及一个＆＃34;框架＆＃34;保留每个目标的代码。换句话说，您可以在多个目标/应用之间共享代码，同时您可以将属于每个目标/应用的内容分开。没有杂乱的项目：）
我不确定Xcode是如何编译CoreData的，因为我们没有使用它。但请查看我刚才为another question所做的答案。它不是Swift，但这不应该有太大的区别，因为几乎所有的答案都是关于配置工作空间来实现这个解决方案。不幸的是，我觉得它太大了，这就是为什么我要把答案联系起来而不是在这里粘贴它的原因。
如果你需要任何帮助，请告诉我，我会尽力帮助你。
答案 1 :(得分：11)
这可能对你来说太过分了，但这个解决方案是可扩展的。我们必须从一个代码库构建~15个应用程序
我们必须解决的问题是品牌推广。应用程序设计和流程基本相同，以及我们收到的数据结构。 我们的CI服务器完成了很多繁重的工作。
我们拥有一个包含所有UI和一些常见业务逻辑的核心应用程序。这被称为白色应用程序。
然后，我们为每个不同的端点设置了一个特定的项目（框架并不存在）。数据模型和映射器进入White-app的视图模型。这些应用程序是私人吊舱，由可可豆荚管理。
我们的CI配置方式可以编译所有“品牌”。应用程序通过复制，编译，将所有变化的plist，资产，字符串文件与每个应用程序的每个特定数据模型一起签名到每个应用程序中。因此，当触发端到端构建时，它将构建所有不同的品牌应用程序。
这样做的好处是Xcode中的目标布局不会混乱，我们有一个发布，测试和开发目标，适用于构建的每个应用程序。这意味着我们的项目非常简洁，没有意外编辑品牌应用程序构建设置的风险。
此解决方案还将为您提供.xcworkspace（主要由可可豆荚使用），其中包含对不同型号豆荚的参考
这个解决方案因为它是设置工作，即在Xcode中构建时我们创建了一个特殊的方案，它安装了一个pod并复制到所有正确的资产中（如CI所示）
答案 2 :(得分：5)
这是许多开发人员多次思考的问题，他们提出了针对他们需求的不同解决方案。以下是我对此的看法。
将你可以看作核心的公共部分放在一个单独的东西上是件好事。除了支持可重用性之外，它还通过清晰的分离和清晰的界面来提高代码质量。根据我的经验，这使测试更容易。你如何打包这取决于你放在那里的东西。静态库是核心业务逻辑的一个很好的开端，但缺乏对Swift的支持，并且资源很难包括在内。框架很棒，但提高了最低iOS开发目标的标准。当然，如果您只使用非常少的文件，只需将文件夹添加到您的应用程序项目也可以正常工作 - 保持项目结构最新可以自动化（dropbox / djinni这样做），但它是非 - 感性的方法。
然后是要构建的实际产品，其中必须包括核心模块和各个部分。这可以是具有多个目标的项目，也可以是具有多个项目的工作空间，或两者的混合。在给定的上下文中，我根据应用程序的相关程度做出决定。如果一个只是一个小的改变，比如改变一个运动队，或者配置一些功能，如光与专业，这将是同一个项目中的不同目标。另一方面，如果应用程序明显不同，我会使用不同的项目（可能安排在一个共同的工作区内），如Facebook客户端和Twitter客户端，用于离线游戏的桌面游戏应用程序和在线游戏应用程序等。< / p>
当然，还有很多事情需要考虑。例如，如果您为客户构建应用程序并运送源代码，则可能需要单独的项目 。
答案 3 :(得分：4)
创建一个包含所有3个选项中所需的最多共享代码的框架会更好。此外，第一种选择在任何情况下都是糟糕的。为了更好地控制，最好有2个或3个选项。工作区更为可取，因为如果您决定使用cocoapods，它不会对其他子项目造成伤害。工作区还允许您在每个项目中拥有一组不同的本地化。另外，只有与特定项目相关的目标才会出现在目标列表中，这比一堆中的一堆目标更好（例如，如果您在所有产品中都有共享扩展名 - 那么找到一个目标就会令人沮丧需要）。你选择什么取决于你的需求，但第二和第三选择都足够好。
答案 4 :(得分：1)
我认为最好的办法是把所有的东西都包括在内
首先，我将创建一个可配置的框架，它与所有目标共享它们共有的所有内容，从UI（自定义警报等元素）到业务逻辑。
然后，我将为每个目标创建不同的包或文件夹，检查成员资格目标（以这种方式保证只导入确切的资源），然后使用预处理器宏，您可以创建特定于您的资源所在的正确的包或目录的路径构建器。
在这些年里，我收集了一些关于最佳实践的有趣链接。
他们在这里：
Use asset catalog with multiple targets
Use multiple tagets XCode 6
XCode groups vs Folders
Create libraries with resources
Create lite and pro version of an app
我知道在SWIFT中他们对预处理器宏进行了一些更改，因此有些文章仍然有效，但有点过时。
答案 5 :(得分：1)
我们都面临着这种情况。但这是我做的事情，也许你可以在这里选择一些可以帮助你的东西。 （我希望）。