为你的移动应用选择正确的架构是一件相当大的事情，这会对你的工作流程造成影响,陷入面对的问题，可能是一笔巨大财富也可能是一个巨大负担。
HubSpot的是一个全功能的app。他是一个分析的app，也是一个设计媒体的app，还是一个邮件app，并且是一个联系人管理的app（可能还有更多地惊喜），这些功能集合在一个app中。去年夏天，当我们开始构建这个相当复杂的app时，我们知道必须有一个可以容易扩展它的架构。
实际上，我们把每个子app当做一个完全完整地独立的应用程序，然后使用CocoaPods将它们集成到主应用程序中。
截图中，你可以看到各个子程序的源程序，仪表盘，社交媒体，实际上既是一个独立的iPhone应用程序，也可以纳入主要的应用程序的菜单中选择一个应用程序。
这会给我们代理一些巨大的好处：
- 最关键的是，我们很容易就能保证每个子应用程序的主分支是准备好发布，并可以推送一个子应用程序的特定版本。
- 我们在编译上花费多一些时间，而减少了较多合并的时间。每个独立app的沙盒可以很容易的在子应用程序内循环，花最少的时间与其他应用程序进行集成。如果你在一个以上的iOS团队工作过，你毫无疑问已经经历过.xcodeproj合并时的痛苦。虽然他们可以解决，但这个痛苦地步骤我们只想对他敬而远之。
- 我们能够在必要时单独部署每个应用程序，这样我们在一个独立的app可用性测试上将会是惊人的。我们可以更早地将我们的app在合成之前提交给测试者，例如导航功能实现之前，这样我们可以得到更高质量，和更有针对性的反馈。
- 由于子应用程序之间的用户流只是基于URL路径（后面会详细解释）完成的，这意味着路径可以内置或者文档化，而不是从一堆UIViewController以搜索正确的方式来实例化一个特定的视图，当然必须要事先定义好路径。建立类似演练教程或者新的推送通知时，这是非常有用的。
这种架构在一个两人以上的团队建立多方面的iOSapp时，能节省出巨大的时间。
从网页学习
这种将移动端app分割成独立app的灵感来自于我们在HubSpot网页端架构的成功。
HubSpot网页端架构是高速发展和可扩展的。正如我同事所写，我们使用各种工具盒技术，让我们在一天内共同部署300次。这一点至关重要，当HubSpot的产品套件有几个不同的松耦合应用组成：分析，社交媒体，电子邮件，博客和报告工具。
在web上，我们可以编译，测试和发布HubSpotapp独立的一小部分——包括后台API和用Java编写的任务，前端CoffeeScript工程，Python工程。为什么移动端不也这么做？
CocoaPods：用起来！
CocoaPods是iOS中出色的依赖管理解决方案，是一个把所有东西聚合的关键工具。
一个多应用程序架构可能对你的使用的案例过度使用，但CocoaPods绝对不会——尽管你只是生成一小撮使用案例，视图组件或者网络的第三方库——花费几分钟来设置它是完全值得你去投入的。Ruby，gem类似的语法在app中整合开源组件中变得几乎无缝。
核心库和共享资源，如登录，样式类，API/认证持久性和访问可以构建成带Kiwi测试和podspec文件的独立工程。
我们将他们发布在私有CocoaPods仓库中，然后在实际完全编译的应用中包含他们。然而，我们进一步把它们建立成各个子app——所有的社交媒体，电子邮件，资源，使用样例——分成一个单独的podspec，然后使用CocoaPods将它们编译到一个app中。
这意味着，我们可以在内部发行单一功能的测试版本，并且可以在一个单一的应用程序进行快速的变更而无需担心破坏其他工作在不相关的子app开发者的编译。
我们最终完app的Podfile如下所示：
platform :ios, '6.0'
# networking, slider navigation, routing
pod 'AFNetworking', '~> 1.2.1'
pod 'ViewDeck', '~> 2.2.11'
pod 'JLRoutes', '~> 1.2'
# sub-apps, pulling from the head of each repo for development. alternately, we can pin it to a release version like we do the other pods
pod 'HSAPIClient', :head
pod 'HSCommonResources', :head
pod 'HSMarketingGraderApp', :head
pod 'HSContactsApp', :head
pod 'HSDashboardApp', :head
pod 'HSLoginApp', :head
pod 'HSSocialApp', :head
pod 'HSSourcesApp', :head
pod 'HSSettingsApp', :head
pod 'HSSocialReach', :head
pod 'HSEmailApp', :head
把它粘在一起
细心地读者会注意到我们使用了一些在主app中粘合IIViewDeck和JLRoutes两个子app具有关键作用的开源工具。
做到这点我们就可以不需要在基础app的不同菜单项提供信息，并且每个子app的路径都可控。每个子app提供了一个实现了一些HSBaseApp方法的协议类。
HSBaseApp.h文件如下：
@protocol HSBaseApp <NSObject>
+ (UINavigationController *)baseNavigationController;
+ (NSArray *)menuItems;
+ (NSArray *)routesToRegister;
@end
实现的例子HSSocial.m如下：
+ (UINavigationController *)baseNavigationController {
return [[HSNavigationController alloc] initWithRootViewController:[[HSSocialViewController alloc] initWithNibName:@"HSSocialViewController" bundle:nil]];
}
+ (NSArray *)menuItems {
HSMenuItem *calendarMenuItem = [[HSMenuItem alloc] initWithTitle:@"Publishing" icon:@"\\" launchHubSpotApp:[HSSocial class]];
calendarMenuItem.sectionTitle = @"Social";
return @[calendarMenuItem];
}
+ (NSArray *)routesToRegister {
HSRoute *newItemRoute = [HSRoute routeWithUrl:@"social/new" andAction:^BOOL(id<HSRoutingDelegate> routingDelegate, NSString *url, NSDictionary *parameters) {
// handle route, usually by suppying a UIViewController to the routingDelegate
}];
NSArray *routes = @[newItemRoute]; // could be more routes here too
return routes;
}
我们使用路径来处理传入的推送通知，然后我们使用相同的方案将主app和子app进行链接——例如，当我们从数据源或社交媒体返回数据。
HSRoutingDelegate有一点点神奇的是它能绕过当前活动的UINavigationController，然后我们能够在顶部推出或者创建一个基于上下文的模态视图跳转，除此之外，一个简单地JLRoutes基于block的语法也可以达到同样地目的。
我们还能做什么？
从长远来看，我们希望扩大我们过去简单一些共享库的Kiwi测试或在KIF测试中编译，这样每个子app的版本传递Kiwi和KIF测试是建立在一个持续集成的设置中，我们可以选择已知每个很好的版本，发行主程序的每个版本。
你在多人协作中是如何组织大型的iOSapp的呢？有没有更好的方法？我们很乐意听到您的声音！
