New Service: CocoaPods Metadata generation

This week we shipped a new behind-the-scenes service for CocoaPods authors: cocoapods-metadata-service it handles a subset of CocoaDocs responsibilities but does not have the requirement of running on a Mac. This makes it easier for us to maintain.

It's been almost a year since we announced that CocoaDocs was going to be shut down. CocoaDocs' sunsetting was intially slowed down by the team at BuddyBuild offering to take over the project, but the migration wasn't finished before they were acquired by Apple. This means they cannot take over community services.

Instead I've started building out a simpler replacement that handles just the needs of the website. Read on to find out what that looks like.

Why build this?

CocoaPods' web infrastructure needs to continue to be hardened. We have fewer contributors and a lot more people using CocoaPods. Moving more of our web services into heroku means we have less diversity in how projects are hosted get run. Hosting a Mac Mini on the internet is a lot of work, and I wouldn't wish it on anyone else.

There's a tricky thing here though. CocoaDocs would run through the full pod install process and use the files to generate a set of useful metrics for each pod:


Not all of these attributes are feasible when running on heroku because it has an ephemeral filesystem. For example a repo would include example projects and code which are removed by the pod install - CocoaDocs would then use the remaining files to generate details on. In order to work on host without a local clone of the pod, some of those metrics need to be optional.

I built this service to focus on the most pressing problem first: READMEs, CHANGELOGs and license information. Basically:


Some of the other attributes can be added later, for example I see no blockers on adding dominant_language, is_vendored_framework, initial_commit_date, spm_support and readme_complexity to the service, but some attributes are just not going to be feasible.

This service has so far focused exclusively on Open Source GitHub projects, with plans to expand to Pods that use .tar.gz and zip files coming soon.

It's the first JavaScript project (TypeScript) in the CocoaPods org, because once I worked with TypeScript I couldn't go back to Ruby for a new project. This does introduce some complexity though. So I opted to livecode the entire process of building the v1 and getting the project into production.

This means if you're interested in how to build a small NodeJS server in TypeScript, you've got a small well-built example with a YouTube playlist of over 5 hours where I have to explain all of my choices.

As we rely more on this service, we can continue to provide the rich web-experience with far less dependencies on hard to maintain infrastructure, which paves the way for CocoaPods to continue being a useful resource for a very long time.