"Translate" using CocoaPods modular iOS app

Original translation from: Using CocoaPods to modularize a Big IOS App

Choosing the right architecture for your mobile app is a big thing, and it can have an impact on your workflow, and it can be a huge asset and a huge burden to get into the face of the problem.

HubSpot is a full-featured app. He is an analytics app, a design media app, a mail app, and a contact-managed app (and probably more surprises) that are set up in one app. Last summer, when we started building this rather complex app, we knew there had to be an architecture that could easily be extended.

In fact, we treat each sub-app as a completely separate application, and then use CocoaPods to integrate them into the main application.

, you can see the various subroutines of the source program, dashboard, social media, is actually both a standalone iphone app, or can be included in the main application menu to select an application.

P1

This will give us some great benefits of acting:

• Crucially, it is easy to ensure that the main branch of each sub-application is ready to be released and can push a specific version of a child application.
• We spend more time on compiling and less time on merging. The sandbox for each standalone app can easily be looped within a sub-application and spend the least amount of time integrating with other applications. If you have worked on more than one iOS team, you have undoubtedly experienced it . Xcodeproj the pain of merging. Although they can be solved, but this painful step we just want to distance him.
• We were able to deploy each application separately when necessary, so that we would be amazing on a standalone app usability test. We can submit our app to testers earlier, such as the navigation function before it is synthesized, so that we can get higher quality and more targeted feedback.
• Because user flows between sub-applications are only done based on URL paths (explained in detail later), this means that the path can be built-in or documented, instead of instantiating a particular view from a bunch of uiviewcontroller to search the right way. Of course, you have to define the path beforehand. This is useful when creating a similar walkthrough tutorial or a new push notification.

This architecture can save a great deal of time when a team of two or more people builds multiple Iosapp.

Learn from web

This segmentation of mobile apps into standalone apps is inspired by the success of our HubSpot Web-based architecture.

The HubSpot web-side architecture is fast-growing and scalable. As my colleague wrote, we use a variety of tool-box technologies that allow us to deploy together 300 times a day. This is crucial when HubSpot 's product suite has several different loose-coupling applications: Analytics, social media, email, blogs and reporting tools.

On the web, we can compile, test and publish a fraction of the HubSpotapp's independence-including background APIs and tasks written in Java , front-end coffeescript Engineering,Python Engineering. Why doesn't the mobile side do the same?

CocoaPods: Use Up!

CocoaPods is an excellent dependency management solution in iOS and a key tool for aggregating everything.

A multi-application architecture may be overused for your use case, but CocoaPods will never-although you just generate a handful of use cases, view components or a third-party library of the network-it's worth your while to set it up for a few minutes. Ruby, a similar syntax forgems , has become almost seamless in an app that integrates open source components.

Core libraries and shared resources such as logins, style classes, api/authentication persistence and access can be built into standalone projects with Kiwi testing and podspec files.

We publish them in a private CocoaPods repository and then include them in the actual fully compiled app. However, we further build them into all app--social media, e-mails, resources, and use examples-into a single podspec, and then use CocoaPods to compile them into an app.

This means that we can release the beta version of a single feature in-house, and can make rapid changes in a single application without worrying about destroying other work on the unrelated Child app developer's compilation.

Our final podfile of the app is as follows:

Platform: iOS,' 6.0 '# Networking, slider navigation, routingpod' 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 podspod' Hsapiclient ',: Headpod ' hscommonresources ', : headpod ' Hsmarketinggraderapp ', : headpod ' Hscontactsapp ', : Headpod ' Hsdashboardapp ', : headpod ' Hsloginapp ', : headpod ' Hssocialapp ', : headpod ' Hssourcesapp ', : headpod ' Hssettingsapp ', : headpod ' Hssocialreach ', : Headpod ' Hsemailapp ', : Head               

Stick it together.

Careful readers will notice that we use some open source tools that are key to gluing Iiviewdeck and jlroutes two sub-apps in the main app.

By doing this, we don't need to provide information in different menu items in the underlying app, and each sub-app's path can be controlled. Each sub-app provides a protocol class that implements some of the Hsbaseapp methods.

The HSBaseApp.h file is as follows:

@protocol HSBaseApp <NSObject>+ (UINavigationController *)baseNavigationController;+ (NSArray *)menuItems;+ (NSArray *)routesToRegister;@end

Examples of implementation HSSOCIAL.M are as follows:

+ (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 rout Ingdelegate}]; nsarray *routes = @[newitemroute]; //could be + routes here too return routes;}   

We use paths to handle incoming push notifications, and then we use the same scenario to link the main app and the child app--for example, when we return data from a data source or social media.

hsroutingdelegate A little bit magical is that it can bypass the current activity of the Uinavigationcontroller, and then we can launch at the top or create a context-based modal view jump, in addition, A simple jlroutes block -based syntax can also achieve the same purpose.

What else can we do?

In the long run, we want to expand our Kiwi testing of simple shared libraries in the past or compile them in KIF tests so that the versions of each child app pass Kiwi and KIF The test is built in a continuous integration setting, and we can choose each version that is known to be a good version of the main program.

How do you organize large iosapp in multi-person collaboration? Is there a better way? We'd love to hear your voice!

"Translate" using CocoaPods modular iOS app