Update – Page 2 – Continuous Updating

TL;DR

We made the following changes for Cocoapods:
– Now we can watch your project’s Podfile as well as the Podfile.lock.
– We display all dependencies for a Podspec file.
– If there are dependencies to subspecs, only the corresponding spec is displayed.
– The pages show the actual version release dates for pods hosted on Github.
– Now there is a link to the original podspec file in the Cocoapods Specs repository on Github.

Details regarding VersionEye’s support for Cocoapods

Since we initially announced support for Cocoapods we got a lot of feedback from you. So, we want to say thank you for pointing out bugs and suggesting improvements which helps us to make the product better day by day.

First of all we improved our crawler to better represent Cocoapod’s podpecs. There was a small bug that prevented dependencies to display correctly.

Since Cocoapods doesn’t have the original release dates we try to get them from the corresponding git tag now. We use the Github API to do this, so currently this works only for pods hosted on Github. This is how version dates for AFNetworking look like now.

And because we have the release dates for most of the CocoaPods artefacts now, we can display proper KPIs for CocoaPods. That means we’re able to show you the average release dates of a Pod as well as number of references from other Pods.

We also display a link to the original podspec file in the Cocoapods Specs repository on Github. This should simplify comparing the original podspec with the data we display.

Subspecs

When we first introduced the list of dependencies for Cocoapods, we realized that Cocoapods has a feature called “Subspecs”. This is a cool feature that actually makes a lot of sense for the development of iOS apps. But subspecs is also a feature we couldn’t found in any other package manager yet.

When we first displayed dependencies, we saw that a project which depends upon Sharekit/Facebook and Sharekit/Twitter wouldn’t link to the Sharekit page on VersionEye. This made sense, because VersionEye‘s internal database domain model doesn’t support anything like subspecs yet.
ShareKit itself also depends on several subspecs of Google-API. This is how it looked like:

Since the version number is global in a Podspec file and all subspecs share the same version number, we thought it would be better to just summarize subspecs and show the podspec’s name instead. So the new version looks like this: