CocoaPods for Development-Time Modularity
At Twitch, we use CocoaPods, but not just for consuming external libraries like 1PasswordExtension and google-cast-sdk. We also use them for development time modularity (to keep our code properly isolated and to reduce build times for our automated tests).
We have over 20 development pods that we never intend to publish, either internally or externally, that live in our git repository. Many have separate workspaces (we call these “independent pods”) for faster build times while testing. For example, we have a TWFoundation pod containing extensions for many Foundation classes (NSString, NSDate, etc).
Independent pods have a separate workspace so the compiler can guarantee that they have no dependencies on code without our app. For example, if someone added a method into NSString+TWFoundation.m that depended on our video player view controller, TWFoundationHost would fail to compile because it can’t import our video player view controller.
Separate workspaces also decrease build times while testing. Building the full Twitch iOS App from a clean build folder takes 60 seconds on my MacBook Pro (Retina, 15-inch, Mid 2015). TWFoundation classes are heavily imported throughout our codebase, so it’s likely that changes to one of them will trigger many incremental compilations to build the full Twitch iOS App. However, building TWFoundationHostTests from a clean build takes only two seconds, so working within TWFoundation.xcworkspace is a much faster way to modify our TWFoundation classes.
Testing is also more focused. I can run allTWFoundationHostTests by running the Test scheme within the TWFoundation workspace. Running all tests throughout the independent workspaces requires opening each workspace individually, so we use Fastlane to run everything for us.
Because we don’t publish these pods anywhere, our Twitch iOS App workspace and other independent workspaces consume them as development pods. If we discover a bug or want to add a new feature, we can easily modify any existing files in TWFoundation or any other independent pods directly within our workspace. We don’t have to switch to TWFoundation.xcworkspace.
Even though independent pods are great for developer productivity, they can have some linker side-effects if used improperly. If you’re using CocoaPods’ use_frameworks! setting (required for Swift code), you’ll dynamically link all your pods, and that can negatively impact startup performance. Apple suggests:
So you absolutely can and should use [frameworks], but it’s good to try to target a limited number … a good target’s about a half a dozen.
Since we don’t use Swift in the Twitch iOS app, we can statically link our pods, which has no startup cost. Swiftpm doesn’t support iOS and Xcode doesn’t support statically linking Swift files without workarounds, so you should probably avoid Swift for any apps with lots of pods.
CocoaPods is great for easily consuming external code, but it’s also great for keeping your internal code organized and fast to build and test. Give independent pods a try today!
Twitch is hiring! Learn about life at Twitch and check out our open roles here.
