Updates for Cocoapods support


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.

KPIs for AFNetworkingVersions of AFNetworking

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.


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:

dependencies for sharekit

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:

display consolidated dependencies

While we recognize this isn’t 100% correct, we feel that it improves the usability of VersionEye for iOS and Mac developers.

Since we have a little bit historical data now, we can show a nice chart about new Pod versions and packages. Check out our Objective-C page.

Screen Shot 2013-11-29 at 12.50.17

We hope you like all the new changes. If you have suggestions or find a bug, please let us now in the comments, via email or on Twitter and Facebook.

VersionEye now supports OpenSearch

If you want to find out which version of a software library for your programming language of choice is the latest, you had to go the libraries’ website or the repository. Finding the website, the latest version and getting reminded on important bugfixes for the libraries you use can cost a lot of time.

VersionEye is a website that tracks software libraries in 8 different programming languages and 7 package managers. Eg. if you are a Ruby developer you might be interested in the latest Rails, Sinatra or Capybara version. As a Java developer the latest versions of Spring, Guice or Hibernate might be of interest for you.

If you regularly search for software libraries you may want to have a search engine directly in your browser. VersionEye now supports OpenSearch so you can add VersionEye as a search engine to your browser and quickly find out what the current version of your library is.

Add VersionEye to Firefox

  1. Go to http://www.VersionEye.com/.
  2. Locate the search box in the upper right corner of your browser.
  3. Click the small grey triangle next to the search icon and you will be able to add “VersionEye” as your new search engine for software libs.


Bildschirmfoto 2013-11-05 um 16.57.05

Add VersionEye to Chrome

To add VersionEye OpenSearch to Chrome, just go to www.versioneye.com and search for your favourite software lib or something your colleague just mentioned the other day. After this, Chrome will automatically use VersionEye’s search if you type versioneye.com rails in Chromes Omnibox bar. (Recognize the space, Chrome will switch into search mode when you type the space after the domain name.)

Customizing your new Library Search Engine

To make searching for libraries even easier, go into Chrome Settings for Search Engines (the URL is chrome://settings/searchEngines ) and search for VersionEye. Just change the key in the middle to something short to like ve and you can search for Capybara by just typing ve capybara into the Chrome Omnibox.



We hope you like the post and you find VersionEye useful. If you would like to have a feature we don’t have yet, please let us know.