管理iOS应用程序的多个版本

Question

让我说我有一个iOS应用程序让我们说,足球新闻,现在我想创建一个其他版本的篮球新闻,将主要基于足球应用程序,但可以自由地在每个应用程序的某些方面创建不同的行为+为将来的新闻主题添加更多应用程序.

另一个条件是它们将具有单独的CoreData模型,资产,图标等.

据我所知,我有几个选择:

1. 单独管理应用程序,将它们放在同一目录中,并指向第一个(足球应用程序)中的共享文件.
2. 为同一项目中的每个应用创建不同的目标
3. 使用一个项目创建一个工作区,该项目将保存公共代码和每个项目的项目.

每种选择的优缺点是什么？在这种情况下最佳做法是什么？

只是为了澄清 - 我提到的应用程序就是一个例子,App不是新闻,它必须是每个概念的不同应用程序.

谢谢

Answer 1

我在企业环境中工作,我们有一个移动应用程序,它是我工作的公司的产品.我们向我们的客户出售该软件的许可证,这些客户总是巨大的公司.我们的应用程序不通过App Store.

我们的每个客户都可以通过简单地更改徽标或甚至为其中一个添加某些特定功能来对应用进行某种自定义.我的意思是:我们必须每天处理与你所描述的情况非常接近的情况,这是我的两分钱.

提前:对不起,如果我有时太诚实,我不是故意冒犯任何人.

1.单独管理应用程序,将它们放在同一目录中,并指向第一个(足球应用程序)中的共享文件.

嗯......这是一个奇怪的解决方案,但它确实可行.在使用SVN/Git时(特别是在团队工作时),可能很难在本地维护甚至更难维护.

我之前遇到过与符号链接相关的一些问题,但我不确定这是否是您在此选项中所指的内容.如果你解释得更好一点,我可以编辑这个并尝试给你一个更好的意见.

2.为同一项目中的每个应用创建不同的目标

在我看来,这是一个更好的开始.

我们主要使用这种方法来处理各种可能的后端服务器.例如,我们的一个目标使用我们的开发后端服务器,而另一个目标使用生产服务器.这有助于我们确保我们可以使用开发目标应用程序,而不会给我们的团队带来严重的成本(例如,由于错误的订单).

在您的情况下,您可以在目标上配置预处理器宏以启用/禁用由代码调用的某些特定于目标的功能.您还可以为每个目标使用不同的故事板.

这个选项的缺点是代码会很混乱,因为每一段代码都在同一个项目中.这是我选择#3的主要原因.

3.使用一个项目创建一个工作区,该项目将保存公共代码和每个项目的项目.

再说一遍,我会这样做.说实话,我们在YET公司没有使用它,但这是由于内部原因.我想尽快让我们的项目得以实现.

我不会轻易地设置它,但如果操作得当,它可以帮助您节省一些时间,因为维护原因.您将能够重用任何可以重用的代码,并且仍然能够将特定于目标的图像,类和视图保存到自己的"容器"(项目)中.

通过这种方式,您将获得一个默认项目(应用程序本身),多个目标,以及一个"框架",以保留每个目标的代码.换句话说,您将能够在多个目标/应用之间共享代码,同时您将能够分离属于每个目标/应用的代码.没有凌乱的项目:)

我不确定Xcode是如何编译CoreData的,因为我们没有使用它.但请查看我刚才为另一个问题所做的答案.它不是Swift,但这不应该有太大的区别,因为几乎所有的答案都是关于配置工作空间来实现这个解决方案.不幸的是,我觉得它太大了,这就是为什么我把答案连接起来而不是粘贴在这里的原因.

如果您需要任何帮助,请告诉我,我会尽力帮助您.

Answer 2

这可能对你来说太过分了,但这个解决方案是可扩展的.我们必须从一个代码库构建~15个应用程序

我们必须解决的问题是品牌推广.应用程序设计和流程基本相同,以及我们收到的数据结构.我们的CI服务器完成了很多繁重的工作.

我们有一个核心应用程序,包含所有UI和一些常见的业务逻辑.这被称为白色应用程序.

然后,我们为每个不同的端点和数据模型以及映射到White-app的视图模型中的特定项目(当时不存在框架).这些应用程序是私人吊舱,由可可豆荚管理.

我们的CI配置方式是通过复制,编译,签署所有不同的plist,资产,字符串文件以及每个应用程序的每个特定数据模型来编译所有"品牌"应用程序.因此,当触发端到端构建时,它将构建所有不同的品牌应用程序.

这样做的好处是Xcode中的目标布局不会混乱,我们有一个发布,测试和开发目标,它适用于构建的每个应用程序.这意味着我们的项目非常简洁,没有意外编辑品牌应用程序构建设置的风险.

该解决方案还将为您提供.xcworkspace(主要由可可豆荚使用),其中包含对不同模型豆荚的参考

这个解决方案,因为它是设置工作,即在Xcode中构建时,我们创建了一个特殊的方案,它安装了一个pod并复制到所有正确的资产中(如CI所示)

Answer 3

这是许多开发人员多次考虑的问题,他们提出了针对他们需求的不同解决方案.这是我对此的看法.

将您可以看作核心的公共部分放入单独的部分是一件好事.除了支持可重用性之外,它还通过清晰的分离和清晰的界面来提高代码质量.根据我的经验,这使测试更容易.你如何打包这取决于你放在那里的东西.静态库是核心业务逻辑的一个很好的开端,但缺乏对Swift的支持,并且资源很难包括在内.框架很棒,但提高了最低iOS开发目标的标准.当然,如果您只使用非常少的文件,只需将文件夹添加到您的应用程序项目也可以正常工作 - 保持项目结构最新可以自动化(dropbox/djinni事情这样做),但它是非 - 通过什么方法.

然后是要构建的实际产品,其中必须包括核心模块和各个部分.这可以是具有多个目标的项目,也可以是具有多个项目的工作空间,或两者的混合.在给定的上下文中,我根据应用程序的相关程度做出决定.如果一个只是一个小的改变,比如改变一个运动队,或者配置一些功能,如光与专业,这将是同一个项目中的不同目标.另一方面,如果应用程序明显不同,我会使用不同的项目(可能安排在一个共同的工作区内),如Facebook客户端和Twitter客户端,用于离线游戏的桌面游戏应用程序和在线游戏应用程序等.

当然,还有很多事情需要考虑.例如,如果您为客户构建应用程序并运送源代码,则可能需要单独的项目.