2015

Apple even merged a Podspec into their first foray in open source libraries with ResearchKit.

Our biggest online/offline event this year, was the the CocoaPods Test Jam. It ran in 7 cities and helped get a lot of people bootstrapped with both testing and contributing back to the open source community. It was awesome to organise, and fun to contribute to.

We found that keeping on track of all pods is starting to become an issue, for example yesterday 18 new pods were added to trunk. We wanted to find an alternative way to keep on top of new pods, so we created @CremeDeLaPods as a way of keeping track of the highest quality new pods.

Wanting to experiment, and to encourage new voices in the CocoaPods team we worked with Rails Girls Summer of Code. We teamed up with Karla Sandoval and Emma Koszinowski, who make up team CocoaGems. Together with the GitHub web team advising they:

• Created a plugin to annotate a Podfile.
• Converted the user interface section of CocoaPods into its own gem called Cork.
• Split out CocoaPods' command line search tools into a new gem, CocoaPods-Search.

Web Properties

A problem close to my heart is discoverability. We want to lower the barriers to entry for everyone to participate in OSS, and making people's projects easily discovered is an important part of this.

The CocoaPods web presence has had a lot of work devoted to it in the last year, the most obvious is that we now have individual pages for a pod. These pod pages pull in nearly every interesting piece of metadata around the pod, making it significantly easier to browse and compare pods.

We introduced a project we've had been working on for over a year, CocoaPods Quality Indexes (QIs) an evolving attempt at defining quality in software. These QIs are used throughout the web properties to provide feedback and to sort pods.

The QIs provide a positive feedback loop, showing you ways in which you can game the system by improving your library. By focusing on showing you ways to improve, rather than penalising discouraged behaviour, I hope we can continue to foster a welcoming and supportive community.

To expand on that further and allow people to have a better sense of their the state of their libraries, we created Pod Author Pages. Here's a great example from Andrea Mazzini making it really easy to understand his impact on the community.

Another multi-year project that we shipped this year was CocoaPods Stats. Stats offers a way of knowing how many downloads a pod has, and far more interestingly the number of targets it has been integrated with. This is something I haven't found in other dependency managers, as it's a really hard problem to solve. We couldn't have shipped this alone, so a big thanks to Segment for sponsoring a lot of the infrastructure here.

While the number of pods available via CocoaPods has increased in the last year, the amount of servers we need for search has not. Florian Hanke who has been working with us since the start continues to refuse to throw more money at our search server. His work has made it possible for us to deal with doubling our search traffic, support more metadata, add different sort types and allow scoping to all the new platforms Apple keep shipping.

CocoaDocs, the CocoaPods documentation service started supporting Swift code this year via Jazzy, and the future is looking bright on that front as Jazzy now supports Objective-C projects and one of these days will support mixed language projects. We'll probably be migrating CocoaDocs to only use Jazzy next year. CocoaDocs had problems scaling with the number of new pod versions being shipped this year. We remedied this by working with Button to get a high-end Mac Mini doing the work instead of a shared VPS.

Finally, we made it easier to get bootstrapped to work on the web infrastructure via a meta-repo called Strata.

So, to wrap this up, I was looking at the Google Analytics for the CocoaPods web properties. My favourite quirky statistic is this: We get more user sessions from Windows devices than we do iOS. Perhaps this mobile thing is just a fad?

CocoaPods

So this year was a crazy year from the perspective of Apple releases.

In the last 3 months, Swift is the dominant language for half of the new Pods. At this point last year we were just starting to ship betas supporting frameworks, enabling Swift for those brave enough to be early adopters. Now there's a Swift library is in the top ten downloaded Pods and there are tens of thousands of apps using CocoaPods with Swift frameworks. We're starting to see real mainstream adoption of the language.

Apple also kept us all on our toes by introducing 2 new platforms. watchOS first came as an iOS extension, but then migrated to a real platform of its own with watchOS2. tvOS came towards the end of the year. This means CocoaPods now supports 4 independent platforms.

We added determinate UUID generation, which is only important if you check in your Pods directory. This means running pod install would generate the same UUIDs for the files it generates, and you won't see diffs for Pods.xcodeproj.

The CocoaPods plugin API got more powerful via pre-install and post-install hooks. Third party adoption of plugins has been great, and we've moved a bunch of non-core CocoaPods code into plugins. For example; trunk, stats, search and try are all plugins.

We made it harder to accidentally edit your Pods files by having the files read-only by default.

Finally, the introduction of Molinillo made CocoaPods' dependency resolving first class. This means that a pod install is now always going to be the exact same Pods as the one that generated the Podfile.lock. Also, seriously, it's in RubyGems + Bundler, that's so cool.

CocoaPods.app

The final major project that we've been working on, and have shipped a few releases sneakily is CocoaPods.app. In our constant work to lower the barrier to entry for building apps, we've started tackling the last mile. How do we improve, and simplify the installation and updating of CocoaPods?

The best way to do that is to make CocoaPods act like other tools a Cocoa developer would work with every day. So we have been working on a CocoaPods.app that you can drag into /Applications and it will deal with handling CocoaPods for you.

I'd like to say sorry if using the terminal just for this made you feel like a leet hacker, but I'd be wrong. CocoaPods.app includes a fully hosted copy of the pod command ( as well as all the tools it relies on: svn, hg, bar, git etc ) that you can use from your terminal.

The next CocoaPods release is going to be the first release that we will be offering this as the default way to install CocoaPods. I think it's the best experience we can offer for someone who is consuming Pods. For now, we're keeping it a little bit hidden away on cocoapods.org/app. We're aiming for something on the lines of this:

1.0

I finished the last post talking about what 1.0 looks like, so it seems fitting to end this year about 1.0 too. Our 1.0 milestone is getting there, and there's progress on the last major breaking change to the Podfile syntax. With luck, this may finally be the year of CocoaPods 1.0.

Tweets of Praise