CocoaPods Blog

CocoaPods Trunk: Minor security updates

Wed, 18 Feb 2026 00:00:00 +0000

Hey folks, strange enough we got two separate security folks pointing out the same flaw in Trunk within a week of each other. I've shipped the fixes a month ago, it's worth both explaining what was fixed and giving credit to the two researchers: splitline from DEVCORE and Joshua Rogers from AISLE Research Team.

When you sign up to CocoaPods trunk, rather than having you set up a password in the CLI we email you a token which you click to verify your current session as being valid. So, you would register by running this command:

> pod trunk register orta.therox@gmail.com
[!] Please verify the session by clicking the link in the verification email that has been sent to orta.therox@gmail.com

That triggers a verification email, which would have looked like :

Hi Orta Therox,

Please confirm your CocoaPods session by clicking the following link:

    https://trunk.cocoapods.org/sessions/verify/51efd813

If you did not request this you do not need to take any further action.

Kind regards,
the CocoaPods team

Accepting the token by clicking the link sets up the authentication for my local CLI as being verified.

The flaw here is that 51efd813 is a relatively small space of characters, and we didn't have any protection around someone requesting a verification for basically every possible token (e.g. 11111111 to ffffffff.)

splitline fom DEVCORE sent me a very interesting way to think about it, with a proof of concept script by using a birthday attack.

Step 1: Register a lot of times for the email you want, to increase the odds of it working.
Step 2: Send random verification requests to Trunk
Step 3: Check all of the sessions to see if they were verified

With a reasonable enough amount of time, and tens of thousands of requests on each step, you can verify a token for an email address you don't own.

The fix

The Pull Request is here which converts the 8 characters to 20 characters (making the search space significantly larger) and adding the verification system to our request throttler, making it much harder to search the space!

Worst case scenario

Like with the RCE in 2021 I can't prove this hasn't been actively used. However, just because it hasn't been proved, doesn't mean it hasn't happened. This touches code which has been in trunk since launch, and 11 years is a long time.

The worst case scenario is that an attacker could have used this technique to get access to upload a CocoaPod version which contains malicious code. For a few years now we've been emailing Podspec authors when a new version comes out, so it's likely someone would have been notified if this has happened to them.

For more information

We want to offer our thanks to splitline from DEVCORE and Joshua Rogers from AISLE Research Team for their thorough reporting! They mentioned a few other things not noted in this blog post but we fixed around XSS and our throttler.

CocoaPods is ran by a set of volunteers in their spare time. If you have any questions or comments about this advisory:

Open an issue in the trunk repo
Email us at our private security email: info@cocoapods.org

If you're not sure of the email address you used for a pod, use pod trunk info [pod_name] to see the connected email accounts.

CocoaPods Trunk Read-only Plan

Sat, 30 Nov 2024 00:00:00 +0000

TLDR: In two years we plan to turn CocoaPods trunk to be read-only. At that point, no new versions or pods will be added to trunk. - Note, this post has been updated in May 2025.

Last month I wrote about how CocoaPods is currently being maintained, I also noted that we were discussing converting the main CocoaPods spec repo "trunk" to be read-only:

We are discussing that on a very long, multi-year, basis we can drastically simplify the security of CocoaPods trunk by converting the Specs Repo to be read-only. Infrastructure like the Specs repo and the CDN would still operate as long as GitHub and jsDelivr continue to exist, which is pretty likely to be a very long time. This will keep all existing builds working.

I plan to implement the read-only mode so that when someone submits a new Podspec to CocoaPods, it will always be denied at the server level. I would then convert the "CocoaPods/Specs" repo to be marked as "Archived" on GitHub which should cover all of our bases.

Making the switch will not break builds for people using CocoaPods in 2026 onwards, but at that point, you're not getting any more updates to dependencies which come though CocoaPods trunk. This shouldn't affect people who use CocoaPods with their own specs repos, or have all of their dependencies vendored (e.g. they all come from npm.)

May 2025 Update: Since this post was originally written, we've had enough security researchers abusing scripting capabilities in CocoaPods that we are now introducing a block on allowing new CocoaPods to use the prepare_command field in a Podspec. Any existing Pods using prepare_command are hard-coded to bypass this check.

Timeline

My goal is to send 2 very hard-to-miss notifications en-masse, and then do a test run a month before the final shutdown.

May 2025

We are stopping new CocoaPods from being added which use the prepare_command field

Mid-late 2025

I will email all email addresses for people who have contributed a Podspec, informing them of the impending switch to read-only, and linking them to this blog post.

September-October 2026

I will, again, email all email addresses for people who have contributed a Podspec, informing them of the impending switch to read-only, and linking them to this blog post, noting that they have roughly a month before we do a test run of going read-only.

November 1-7th 2026

I will trigger a test run, giving automation a chance to break early

December 2nd 2026

I will switch trunk to not accept new Podspecs permanently. This is a Wednesday after American Thanksgiving, so I think folks won't be in rush mode.

Contact

These dates are not set in stone, and maybe someone out there has a good reason for us to amend the timeline. I don't think I'm amenable to moving it forwards, but within reason there's space for backwards.

If you have questions, you can contact the team via info@cocoapods.org, me personally at cocoapods@orta.io or reach out to me via Bluesky: @orta.io.

CocoaPods Support & Maintenance Plans

Tue, 13 Aug 2024 00:00:00 +0000

TLDR: We're still keeping it ticking, but we're being more up-front that CocoaPods is in maintenance mode.

CocoaPods is about 13 years old now, and the landscape of iOS development has changed a lot in that time. I remember the fragmented islets of small shared libraries (like: ASIHTTPRequest, Three20, SBJson, SSToolkit, iCarousel) with tricky upgrade instructions and complicated build setups. CocoaPods simplified that process enough that it turned into the de-facto way to share code in the iOS and Mac community.

In 2015, Apple announce that the CocoaPods project had been Sherlocked because they were going to be creating their own package manager: Swift Package Manager. This move effectively took all the wind out of the sails of CocoaPods, slowing active development of the project as competing with Apple on their own turf is rarely a battle worth your volunteer hours.

Since Swift Package Managers announcement 9 years ago, members of the core team have individually had reasons for continual maintenance: a sense of duty, being employed to work on libraries or apps which use CocoaPods, working on build infra for large projects where CocoaPods is a key part of the build process or just a love of the community.

However, with time - these links become more tenuous too, jobs change, people move to new ecosystems and we've slowly been moving CocoaPods to an place where work only happens when something external causes it. That could be security issues like I've reported the last few years on the blog, or Xcode breaking changes which require us to tweak some settings and make a new build.

If CocoaPods' only audience were native Cocoa developers, CocoaPods' usage should be on the decline, however, that is not the case. The popularity of React Native and Flutter have ensured that most metrics of usage/traffic have been steadily rising over time.

This puts CocoaPods in a strange place, a lot of the maintainers don't use it, Apple have been maintaining a replacement for 9 years and the new users of the project barely even know that CocoaPods exists or what it does.

So, we concluded we need to figure out what is going on with the project and how we have been treating it as maintainers over the last few years.

How CocoaPods Is Maintained

Strictly speaking, we don't plan on changing how we're maintaining CocoaPods. We're just going to start being clear how CocoaPods has been maintained:

We will make sure to handle systemic security issues to trunk
We will aim to make at least 2 releases a year to keep up-to-date with Xcode updates
We will aim to look at support requests for trunk every 6 months
We will keep the website infrastructure from not falling over completely
We are open to PRs which make CocoaPods more future-friendly

What we will not be doing:

We don't actively follow GitHub issues as a support avenue for individuals
We aren't planning on active CocoaPods development in terms of new features
We aren't going to make guarantees about handling PRs from people adding new features, or application-level bugs

New contributors

This is where people would normally say "If we had more volunteers or money etc" but we're not sure that this would help, the skills of maintaining build tooling in Ruby have grown increasingly less relevant over the years to the point that the overlap between "knows how to handle an Xcode project" and "knows what's going on in a complex ruby project" is pretty slim.

We're open to the idea that multiple people who are well motivated to do the necessary volunteer work may be out there, but the search, training and mentoring is also a big ask for existing folks who have little enough time for the project.

Long term plans

Read-only Specs

We are discussing that on a very long, multi-year, basis we can drastically simplify the security of CocoaPods trunk by converting the Specs Repo to be read-only. Infrastructure like the Specs repo and the CDN would still operate as long as GitHub and jsDelivr continue to exist, which is pretty likely to be a very long time. This will keep all existing builds working.

At least for projects like React Native, this could be fine as-is, as most of their libraries come via npm instead of the Trunk, I can't talk to how Flutter's ecosystem works as I have no exposure to it.

We'd make the Specs repo read-only by offering a date when Trunk (our CocoaPods Specs repo authentication server) will be disabled. As trunk is the main target in a supply-chain attack, this would nix all the key issues there. I think we'd be open to this changing if there is a popular alternative client for the Specs Repo was maintained and used by a reasonable number of the community.

We would have a specific blog post with a comprehensive plan if/when this idea settles with us, and to be very explicit: the announced date would be years away.

I use CocoaPods as a Hidden Abstraction in My Framework

E.g. I maintain Unity, React Native, Flutter etc. A lot of these projects will (and should) be migrating to Swift Package Manager with time. As specified above, we are not breaking anything but bugs you may raise are unlikely to get fixed.

If you run these sorts of frameworks and are commercially exposed here, then we're open to chatting - I think no-one on the current team is interested in working on this full time but that doesn't mean we can't find ways to have others who consider this a part of their job role taking over parts of what keeps CocoaPods ticking. You can mail all of us at info@cocoapods.org or me personally at cocoapods@orta.io if you prefer.

Plodding on

Long term maintenance of public infra is often a long grind with the occasional thanks, so I want to try leave this on a "thanks" and give a shout out of all the folks who have been helping to keep the project alive: Eloy, Fabio, Danielle, Dimitris, Eric, Samuel, Paul, Igor, Boris, Florian, Keith, Karla, Emma, Marin, Michele, Joshua, Delisa, Kyle, Olivier, Hugo, Nate, Muhammed, Ben, and Marius . Plus, anyone who ended up in the CocoaPods Slack!

CocoaPods Trunk: 3 Remote Code Execution found, 2023

Sat, 28 Oct 2023 00:00:00 +0000

Over the last month, security researchers at evasec.io have been reached out to us about three separate vulnerabilities in CocoaPods Trunk (the server which handles updates to Pods). We've been working with evasec to patch these issues as they come up. Looking at all three combined, I felt we needed to reset all user sessions again, which is why I'm writing on the blog post instead of working on Puzzmo which just shipped this week.

There are three key issues reported against Trunk, which were promptly fixed:

1. It was still possible to use the 'claim your pod' process to take over a Pod when someone had removed all prior maintainers from it
2. The email which is sent out to verify your email address can be tricked to change to link to a third party
3. The part of trunk which verifies your email address could be used to execute shell commands on the trunk server

Being able to execute arbitrary shell commands on the server gave a possible attacker the ability to read our environment variables, which could be used to write to the CocoaPods/Specs repo and read the trunk database. Being able to trick people into clicking on a link which would take them to a third party site could be used to steal their session keys. I can't guarantee neither of these happened, and I'd rather be on the safe side.

This means you will need to log in again to trunk again to deploy any new Podspecs. If you have automated deployment to CocoaPods working with a stored ENV VAR right now, this will break, and you will need to pod trunk register again and replace your COCOAPODS_TRUNK_TOKEN. We're sorry, I know that sucks, but it also guarantees that you are the only person with write access to your pods.

If you are not a pod author, you do not need to do anything.

evasec.io are still in the process of writing up the full technical details of how the exploits worked, so I'll both update this post with links to their write-ups when they are ready, as well as do a new blog post with the details at a higher level to describe how they work to folks who are not intimate with server architectures.

Worst case scenario

Like with the RCE in 2021 I can't prove these have been actively used. However, just because it hasn't been proved, doesn't mean it hasn't happened. This touches code which has been in trunk since launch, and 9 years is a long time.

The worst case scenario is that an attacker could have used this technique to get access to our trunk database. The trunk database contains the same emails which are public in the git history of the Specs repo. The table of information in the database which should not be seen are session keys. These keys act like unique passwords to accounts, and session keys are used to connect authenticated users to pods. We are wiping all session keys, which ensures no-one other than those with access to their emails can post updates to those pods.

For more information

We want to offer our thanks to evasec.io(EVA) for their thorough reports!

CocoaPods is ran by a set of volunteers in their spare time. If you have any questions or comments about this advisory:

Open an issue in the trunk repo
Email us at our private security email: info@cocoapods.org

If you're not sure of the email address you used for a pod, use pod trunk info [pod_name] to see the connected email accounts.

CocoaPods Web Hosting now Sponsored by Emerge Tools

Wed, 21 Jun 2023 00:00:00 +0000

I'm very happy to announce that Emerge Tools is now sponsoring the web hosting costs of CocoaPods!

We're super thankful that Emerge is stepping in to help us out with this. CocoaPods.org, Trunk, and all the other websites we maintain are a critical part of the CocoaPods ecosystem, and we're glad to have Emerge's support to keep them running.

Emerge Tools is a suite of revolutionary products designed to supercharge mobile apps and the teams that build them. They're a small startup working in a space that is near and dear to our hearts, and when they heard that the CocoaPods maintainers had been paying for hosting out-of-pocket for years, they were eager to step up and help out.

1.11 Arrives!

Mon, 09 Aug 2021 00:00:00 +0000

CocoaPods 1.11 raises the minimum Ruby version to 2.6 while adding support for Ruby 3.0. It also adds support for 'On Demand Resources' and contains numerous bug fixes and improvements!

Ruby 2.6 and Ruby 3.0

With the release of 1.11, the minimum version of Ruby required to run CocoaPods is now 2.6. By doing so, we were also able to bump a few other dependencies (such as ActiveSupport and Addressable) that were often colliding with other setups. We hope this unblocks developers and makes CocoaPods a bit more flexible.

Ruby 3.0 is also now supported and is part of CocoaPods CI going forward! This will ensure new changes and fixes are always tested and verified against Ruby 3.0 before they are merged.

On Demand Resources

In a nutshell, On Demand Resources allow developers to ship smaller app bundles by downloading assets on-demand instead of pre-shipping them.

With CocoaPods 1.11, pod authors may now specify a set of resources to be integrated as on demand resources for a given application.

Here's an example podspec that uses the new on_demand_resources DSL:

Pod::Spec.new do |spec|
  spec.name = 'MyGameAssets'
  spec.version = '1.0'
  # ... rest of root spec entries go here

  spec.on_demand_resources = {
    'level1_assets' => ['level1/**/*.png'],
    'level2_assets' => ['level2/**/*.png']
  }
end

Each key specifies a tag and each value is a glob for the paths to include.

Note: On demand resource paths specified within on_demand_resources are not required to be also specified within resources DSL or resource_bundle DSL.

All on demand resources specified will be automatically integrated to the user's targets project and CocoaPods 1.11 will take care of updating all known asset tags of the user's project.

For example, give the following Podfile:

target 'MyGameApp' do
  pod 'MyGameAssets'
end

The on_demand_resources specified within the MyGameAssets.podspec will be integrated and added to the MyGameApp target!

Other Notable Enhancements

The following DSL options have been added or expanded to serve different use-cases:

project_header_files DSL: Pod authors may now specific a set of project_header_files that are part of their pod. This helps designate specific headers that are meant to be used only by the pod itself. When the library is built, these headers will not appear in the build directory.
New script_phase execution positions: The script_phase DSL has been extended to accept before_headers and after_headers option for the execution_position. This is useful when a script phase must be executed before or after the "Copy Headers" phase.
pre_integrate_hook DSL: Similar to the post_integrate_hook DSL added in version 1.10, this new hook will be executed before the user's project is integrated with the generated Pods project.

Xcode 13 Support

A new version of the Xcodeproj gem has shipped that adds initial support for Xcode 13 projects. To update, run gem update xcodeproj or if you are using Bundler then run bundle update xcodeproj instead.

CocoaPods 1.11 by default includes the latest version of the Xcodeproj gem allowing it to work with Xcode 13 right out of the box.

That's it!

What's Next

Like any other open source project, CocoaPods is maintained and improved by a handful of folks on their spare time. There is no official roadmap and new features will depend upon the community's appetite to build them! We welcome new contributors and assistance from anyone who wants to improve CocoaPods!

We believe that CocoaPods continues to play a significant role for iOS development. It has particularly found strong footing in alternative mobile frameworks such as React Native, Flutter and Kotlin Multiplatform and we hope this release provides pod authors and iOS developers with more powerful tools and features.

As always, we would like to thank all of our contributors who helped make this release happen!

Checkout the changelog to see the full list of changes.

CocoaPods Trunk: Remote Code Execution found

Mon, 19 Apr 2021 00:00:00 +0000

Part of the server-side validation for uploading a new CocoaPod to the central repository of Podspecs (trunk) could be exploited to execute arbitrary shell commands on the trunk server.

We were contacted via Max Justicz this morning who provided us with a great technical write-up and showed how to trigger it for ourselves. The exploit is a combination of un-sanitized user input getting through to a git call param which can be used to send remote payloads.

Being able to execute arbitrary shell commands on the server gave a possible attacker the ability to read the environment variables, which could be used to write to the CocoaPods/Specs repo and read the trunk database.

This means you will need to log in again to trunk again to deploy any new Podspecs. If you have automated deployment to CocoaPods working right now, this will break, and you will need to pod trunk register again and replace your COCOAPODS_TRUNK_TOKEN. We're sorry, I know that sucks, but it also guarantees that you are the only person with write access to your pods.

If you are not a pod author, you do not need to do anything.

Patched

This vulnerability was introduced on Jun 4th, 2015 and has been fixed as of 11am GMT April 19th 2021. The issue has been patched server-side and does not affect your CocoaPods installation.

As most of the commits in the Specs repo are automated through trunk, we have built some introspection tools to validate the Specs repo commits are ones which have been created by publishing/deprecating/deleting through trunk. The majority of other commits in the repo are around setting up infra for the CDN support, and CocoaPods release pushes. We don't think the CocoaPods Specs repo has been tampered with.

How the exploit worked

During the deploy of a podspec to trunk, the server validates that the repo is accessible to git. This is done to help fix potentially broken podspecs with typoes, local auth which won't work for others or external repos don't have tags already set up. This validation used to rely on using the git CLI on trunk using git ls-remote to replicate the same check as a user's git would, but ls-remote has a parameter --upload-pack which can be used to execute a new shell.

This meant an attacker could create a specially crafted podspec via source, which would trigger the --upload-pack param and execute an arbitrary command on trunk.

Worst case scenario

We've not been able to prove that anyone has used this method before Max's report today. However, just because it hasn't been proved, doesn't mean it hasn't happened. 6 years is a long time.

From the side of our investigation, we cannot automatically detect if someone has deployed a poisoned copy of a Pod. If you want to verify that your Pods have not had an un-expected release, you can use this app to shows the sources for every version of a Pod: https://pod-sources.cocoapods.org

For more information

CocoaPods is ran by a set of volunteers in their spare time. If you have any questions or comments about this advisory:

Open an issue in the trunk repo
Email us at our private security email: info@cocoapods.org
The security advisory on GitHub: GHSA-gx9h-rv35-v9hh

If you're not sure of the email address you used to use, use pod trunk info [pod_name] to see the connected email accounts.

1.10 Beta Begins!

Fri, 17 Jul 2020 00:00:00 +0000

CocoaPods 1.10 drops support for Ruby 2.0, adds support for Ruby 2.7 and adds initial support for Xcode 12 as well as a revamped XCFramework integration process!

Ruby 2.0 is out, 2.7 is in!

In the 1.10 release, CocoaPods no longer supports Ruby 2.0 and bumps the minimum version to Ruby 2.3.3! Support for Ruby 2.0 has been dropped for years and macOS with High Sierra has been shipping with Ruby 2.3.3 as the default version.

We hope that this update will unblock other gems that in the past were blocked by CocoaPods as well as address several vulnerabilities that have been fixed since then.

Finally, all CocoaPods related gems have been updated to work with Ruby 2.7 and all known warnings have been fixed during installation.

Revamped XCFramework Integration

With this release, the biggest change is the removal of the Prepare Artifacts script. Similar to the reworked dSYM support in this release, the logic to embed a .framework slice has now moved from the app to each pod target with a new script phase, Copy XCFrameworks. Handling of dSYMs and bitcode symbol maps have also moved.

This rework assisted in fixing several bugs and enabled the support of additional features such as static library support and framework user targets!

Xcode 12 Support

With CocoaPods 1.10 initial support for Xcode 12 has been added. Xcode 12 is still in beta, so it is expected that a few more updates will be required to fully support it. Please file any issues for us to diagnose and fix prior to 1.10 launching!

`post_integrate` Hook DSL

CocoaPods has always offered various hooks into its installation lifecycle. This allows users to customize several aspects of the installation process and perform changes to their project. With this release, we are adding a new post_integrate hook that is executed after the CocoaPods integration step is completed.

In your Podfile:

post_integrate do |installer|
    puts 'Perform post integration steps here!'
end

Integration is the last step of the installation process and is responsible for integrating the generated Pods.xcodeproj with the user's project. This hook will be executed right after this is completed.

Note: This hook is executed after all .xcodeproj have been saved (written to disk). Performing changes to the Pods.xcodeproj will require an additional save but that can be slow. It is recommended to use a post_install hook instead if you anticipate making changes to the Pods.xcodeproj before it gets saved to disk.

`ensure_bundler!` DSL

Many projects use Bundler under the hood and when working with CocoaPods. That is because Bundler ensures a consistent environment which can be useful for teams that work on the same project.

In 1.10, a new ensure_bundler! DSL can be added to your Podfile to specify a version requirement of the Bundler version.

Here's an example:

ensure_bundler! '> 2.0'

That's it!

What's Next

CocoaPods has come a long way since its inception, and we hope to revisit some of the older implementations regarding resource support (not resource bundles) that have been the source of issues for larger repositories that ship multiple apps.

Additionally, we are still considering adding support for local sources that would be helpful for monorepos and allow CocoaPods to discover local pods automatically.

Thanks to all of our contributors who helped make this release happen!

Checkout the changelog to see the full list of changes.

CocoaPods 1.9 Beta has arrived!

Mon, 16 Dec 2019 00:00:00 +0000

CocoaPods 1.9 adds support for XCFrameworks, configuration-based dependencies for pod authors, code coverage in generated schemes, and other enhancements and bug fixes!

This release includes several quality-of-life enhancements in addition to important bug fixes.

XCFramework Support

With the release of Xcode 11, Apple introduced a new bundle format using the .xcframework file extension. This format allows multiple copies of a framework compiled for different architectures and platforms to be combined into a single structure. XCFrameworks are also required for binary dependencies to support the new Catalyst platform introduced in macOS Catalina.

This release introduces support for Pod authors to ship vendored XCFrameworks using the existing vendored_framework DSL. Example:

Pod::Spec.new do |s|
  s.name         = 'ToastLib'
  s.version      = '1.0.0'

  # ...rest of attributes here

  s.vendored_frameworks = 'ButterLib.xcframework'
end

For apps that include Pods which vendor dynamic frameworks, a new script phase with the name [CP] Prepare Artifacts will be added to the project to facilitate including the .xcframework into the app bundle.

For additional details on how to create an XCFramework, check out Apple's WWDC talk Binary Frameworks in Swift which introduced the format.

Configuration-based dependencies for Podspecs

CocoaPods has long supported excluding dependencies from configurations in which they are not needed. For example, debug-only dependencies used during development can be included using the :configurations option on the pod Podfile DSL:

target 'BananaApp' do
  pod 'Toast', :configurations => ['Debug']
end

This release extends this functionality to Pod authors. The same :configurations option may now be used with the dependency Podspec DSL:

Pod::Spec.new do |s|
  s.name         = 'ToastLib'
  s.version      = '1.0.0'

  # ...rest of attributes here

  s.dependency 'ButterDebugging', :configurations => ['Debug']
  s.dependency 'ErrorReportingTool', :configurations => ['Release']
end

Note: Only Debug and Release configurations are currently supported. Support for specifying a custom configuration name might be added in the future.

Code Coverage in Test Specs

CocoaPods first introduced the ability to configure the generated Xcode schemes for Podspecs in version 1.7. This release adds support for enabling code coverage for tests by specifying the code_coverage option within the scheme DSL:

Pod::Spec.new do |s|
  s.name         = 'Networking'
  s.version      = '1.0.0'

  # ...rest of attributes here

  s.test_spec 'Tests' do |test_spec|
    test_spec.scheme = {
      :code_coverage => true, :environment_variables => {'FOO' => 'BAR' }
    }
  end
end

Swift Version Variants

As new Swift versions are released, Pod authors have added support for compiling their source with multiple Swift versions by using the swift_versions Podspec DSL.

To better support this, the Podfile DSL was updated in 1.7 to allow users to specify what versions of Swift their apps support, using the supports_swift_version DSL.

If two different targets include the same dependency but require different Swift versions, CocoaPods will now create multiple different targets for the same Pod to accommodate the different Swift versions used.

Given the following Pod:

Pod::Spec.new do |s|
  s.name         = 'CannonPodder'
  s.version      = '1.0.0'

  # ...rest of attributes here

  s.swift_versions = ['4.0', '5.0']
end

and the following Podfile:

target 'SampleApp' do
  supports_swift_version '< 5.0'
  pod 'CannonPodder'
end

target 'SecondApp' do
  supports_swift_version '>= 5.0'
  pod 'CannonPodder'
end

Two different versions of the CannonPodder target will be created.

This ensures the correct Swift version is used for each target that depends on the Pod.

`use_frameworks!` Linkage Customization

iOS 8.0 introduced the ability for apps to ship dynamically linked frameworks. To support this, CocoaPods introduced the use_frameworks! DSL which made all Pods be compiled as dynamically-linked frameworks. Frameworks do not have any inherent linkage, but Swift initially required dynamic linking to be used in iOS apps. It is possible to wrap a statically-linked library in a .framework bundle.

Now that Swift supports static linking, CocoaPods has expanded this DSL to allow specifying the type of linkage preferred.

use_frameworks! :linkage => :static

This is the first step in providing more control to CocoaPods users over how Pods are packaged and linked into their dependent binaries. For more details, check out the RFC.

What's Next

In future versions, we will continue to expand the customization points for how pods are integrated into projects.

Thanks to all of our contributors who helped make this release happen!

Checkout the changelog to see the full list of changes.

CocoaPods 1.8 Beta is Here!

Mon, 05 Aug 2019 00:00:00 +0000

CocoaPods 1.8 switches the CDN as the default spec repo source and comes with a few enhancements!

CDN as Default

CDN support was first introduced in the 1.7 release and was finalized in 1.7.2. It aims to speed up initial setup and dependency analysis dramatically. With 1.8, CocoaPods no longer requires cloning the now huge master specs repo in order to function and users may integrate their projects with CocoaPods almost instantly.

Here's video demonstration of integrating and building an iOS project with a fresh install of CocoaPods 1.8 in less than a minute:

You may safely delete the master specs repo with the following steps:

First, edit your Podfile to set the CDN as the primary source:

- source 'https://github.com/CocoaPods/Specs.git'
+ source 'https://cdn.cocoapods.org/'

Afterwards, run the following command to remove it from your managed repo list:

pod repo remove master

Note: If you wish to continue using the git based source then you must ensure it is explicitly specified in your Podfile via the source DSL, otherwise CocoaPods will automatically use CDN for dependency resolution.

And that's it! For more information regarding CDN, please read our previous blog post here!

`info_plist` Podspec DSL

CocoaPods automatically generates Info.plist files for pods, app specs and test specs when appropriate, such as when a Podfile requires dynamic frameworks by specifying the use_frameworks! option.

Podspecs now support modifying the contents of their generated Info.plist files via the info_plist DSL. While we anticipate this will be most often used to modify the bundle identifier of a framework, any key-value pair can be included. The values specified will overwrite any default values that are included by CocoaPods.

Here's an example:

Pod::Spec.new do |s|
  s.name         = 'NetworkingLib'
  s.version      = '1.0.0'

  # ...rest of attributes here

  s.info_plist = {
    'CFBundleIdentifier' => 'com.awesomecompany.networking',
    'SERVER_URL' => 'https://example.com/api'
  }
end

With app specs introduced in 1.7, pod authors were able to describe an application, such as a demo app, for their pods. The new info_plist DSL enhances the functionality of app specs even further by allowing podspecs to customize the generated Info.plist, which contains important settings such as the bundle identifier, iOS security and privacy settings, device orientation support, and more.

Pod::Spec.new do |s|
  s.name         = 'ToastLib'
  s.version      = '1.0.0'

  # ...rest of attributes here

  s.app_spec 'ToastCatalog' do |app_spec|
    app_spec.info_plist = {
      'CFBundleIdentifier' => 'com.bakery.ToastCatalog',
      'UISupportedInterfaceOrientations' => [
        'UIInterfaceOrientationPortrait',
        'UIInterfaceOrientationLandscapeLeft',
        'UIInterfaceOrientationLandscapeRight',
      ],
      'UILaunchStoryboardName' => 'LaunchScreen',
      'UIMainStoryboardFile' => 'AppStoryboard',
      'NSLocationWhenInUseUsageDescription' => 'ToastCatalog uses your location to find nearby Toast!'
    }
  end
end

It's important to note that the info_plist attribute will have no effect in situations where an Info.plist file is not generated, such as when pods are integrated as static libraries. If your library requires data that's included in the Info.plist to always be present, we recommend including it as a resource instead.

For more details on how this works and the rational behind it, check out the RFC here.

`project_name` Podfile DSL

CocoaPods 1.7 introduced the generate_multiple_pod_projects option that installs each pod into its own Xcode project. CocoaPods 1.8 expands further by introducing the project_name DSL that allows pod consumers to specify the project name to integrate a given pod.

This opens up plenty of new possibilities for consumers to group certain pods together that make sense logically. Consider the following example:

install! 'cocoapods', :generate_multiple_pod_projects => true

target 'MyApp' do
  use_frameworks!

  pod 'Moya', :project_name => 'Networking'
  pod 'Alamofire', :project_name => 'Networking'
  pod 'Result', :project_name => 'Networking'

  target 'MyAppTests' do
    inherit! :search_paths
    pod 'OCMock', :project_name => 'Testing'
  end
end

Will produce the following result:

It is up to the consumers to choose their own grouping and provide helper methods in their Podfile that automatically apply the project name to use. For example, another grouping idea is to group pods by their platform such as iOS or macOS.

Note: The project_name option currently requires the generate_multiple_pod_projects installation option to also be enabled in order for it to function. Incremental installation has also been updated to take into consideration the project name used for each pod and will continue to work as expected.

Test Spec Enhancements

Test specs have become an integral part of CocoaPods and a couple new features have been added.

UI Test Bundle Support

Support for "UI Test Bundles" is now possible and you may now specify the test_type to use for a given test_spec. The default will be :unit which would create a unit test bundle. Consider the following example of our favorite pod CannonPodder:

Pod::Spec.new do |s|
  s.name         = 'CannonPodder'
  s.version      = '1.0.0'

  # ...rest of attributes here

  s.test_spec 'UITests' do |test_spec|
    test_spec.requires_app_host = true
    test_spec.test_type = :ui
    test_spec.source_files = 'UITests/**/*.swift'
  end
end

This will successfully integrate a CannonPodder-UI-UITests UI test bundle upon installation and will automatically create an app host to be used for it.

Note: UI test bundles require an app host in order to function, therefore you must always specify requires_app_host should you choose to integrate a test spec as a UI test bundle.

Customizable App Host

For most cases, a generated app host for your test spec should be sufficient to execute your tests within it. However, there are cases in which pod authors may want to further customize the app host used for a test_spec.

For example, pod authors may want to specify additional dependencies for their app host or resource bundles to use during testing. App specs are an excellent candidate for this since they provide most of the scaffolding and with 1.8 it is now possible to set an app_spec as the app host for a test_spec via the app_host_name DSL.

Here's an example:

Pod::Spec.new do |s|
  s.name         = 'CannonPodder'
  s.version      = '1.0.0'

  # ...rest of attributes here

  s.app_spec 'DemoApp' do |app_spec|
    app_spec.source_files = 'DemoApp/**/*.swift'
    # Dependency used only by this app spec.
    app_spec.dependency 'Alamofire'
  end

  s.test_spec 'Tests' do |test_spec|
    test_spec.requires_app_host = true
    # Use 'DemoApp' as the app host.
    test_spec.app_host_name = 'CannonPodder/DemoApp'

    # ...rest of attributes here

    # This is required since 'DemoApp' is specified as the app host.
    test_spec.dependency 'CannonPodder/DemoApp'
  end
end

Will produce the following result:

This powerful new feature opens up new possibilities for pod authors who want much more granular control for the app host used for their test specs.

What's Next?

CocoaPods 1.8 is a very exciting release, and we're very happy for you to try it out, and recommend you upgrade:

$ gem install cocoapods --pre

For future versions, we continue to explore new ways to allow pod authors and pod consumers to configure integrating pods into their project, for example by specifying individual package or linkage settings. We have published a proposal that we are currently exploring and we welcome your comments!

As always, we would like to thank all of our contributors for making this release a reality!

Checkout the changelog to get the full list of changes.

🚀

CocoaPods 1.7.2 — Master Repo CDN is Finalized!

Fri, 14 Jun 2019 00:00:00 +0000

CocoaPods 1.7.2 brings with it the final version of CDN support for the trunk specs repo.

It's been a tale of ridiculous scale, unintended consequences and free open-source plans. CocoaPods is moving to use a CDN which is located at https://cdn.cocoapods.org/ and is still considered experimental. A future release will make it the default spec source.

A CDN is a Content Delivery Network - what this means for CocoaPods is that using CocoaPods won't require you to have a local copy of all the public Podspecs on your computer. Saving you about a GB of file storage, and shaving a lot of time off pod installs.

Scaling when free and open source

CocoaPods is a free, open-source project run by maintainers in their spare time. As such, it depends on the good graces and sponsorships of multiple tech companies. The initial decision was to store the specs in a GitHub repo, a common practice for a free, open-source project for storing such metadata.

The first hurdles of scale were encountered in 2016, when traffic to the master spec repo has caused GitHub to rate-limit all operations.
A comment from GitHub at the time stated that this repo alone was using 5 whole server CPUs and consuming terabytes upon terabytes of bandwidth.

The crisis was averted by sharding the repo to improve algorithmic performance and by limiting all first-time clones to being shallow.

This has solved GitHub's problem, but CocoaPods' users still had to deal with unsatisfactory performance.

Git as a Database

Git was invented at a time when "slow network" and "no backups" were legitimate design concerns. Running endless builds as part of continuous integration wasn't commonplace. CDN wasn't so commonly available.

There are many stories of git repos hitting the hard envelope of git's design constraints. Microsoft's Windows repo is one example. CocoaPods is another.

At the time of writing, the spec repo had:

almost 400k commits - half of the Linux Kernel repo!
over 400k directories
over 300k spec files

These numbers have caused the repo to take minutes to clone, long times to update and have wasted uncountable CI time. It has also proven to be resistant to tarballing, as this sort of directory structure hits a bottleneck in tar as well.

Directory Listing Denied

It was obvious to many that the spec repo should be put behind a CDN, but there were several constraints:

It had to be a free CDN, as the project is free and open-source.
It had to allow some way of obtaining directory listings, for retrieving versions of pods.
It had to auto-update from GitHub as the source of truth.

The first implementation was a shell script, polling GitHub and piping find into ls into index files. This ran on a machine that was not open or free and therefore could not be the true solution. Nevertheless, this auto-updated repo was put behind a jsDelivr CDN and the client interfacing with it was released in 1.7.0 labeled "highly experimental".

Final Lap with Netlify

The final version of the CDN for CocoaPods/Specs was implemented on Netlify, a static site hosting service supporting flexible site generation. This solution ticked all the boxes: a generous open-source plan, fast CDN and continuous deployment from GitHub.

Upon each commit, Netlify runs a specialized script which generates a per-shard index for all the pods and versions in the repo. If you've ever noticed that the directory structure for our Podspecs repo was strange, this is what we call sharding. An example of a shard index can be found at https://cdn.cocoapods.org/all_pods_versions_2_2_2.txt. This would correspond to ~/.cocoapods/repos/master/Specs/2/2/2/ locally.

Additionally, we create an all_pods.txt file which contains a list of all pods.

Finally, any other request made is redirected to GitHub's CDN.

Usage

Using the CDN for retrieving specs, while "finalized", should still be considered experimental until we switch it to be default.

To use the CDN source in your Podfile:

If you don't have private specs:

source 'https://cdn.cocoapods.org/'

If you have private specs:

source 'https://github.com/artsy/Specs.git'
- source 'https://github.com/CocoaPods/Specs.git'
+ source 'https://cdn.cocoapods.org/'

Doing this will break your Podfile.lock, so you are likely to need to run pod update to see the changes (be careful, this may update your Pods also).

If you have a CI setup, it is recommended to cache the new repo dir as it is very small and would save even more time. With 1.7.2 it should be located at ~/.cocoapods/repos/cocoapods- (yes, with a -), but we're looking to improve the naming in an upcoming release.

In an upcoming release, we are planning to make the CDN source the default source!

P.S. Thanks to @dnkoutso for all the release work!

🚀

CocoaPods 1.7.0 Beta!

Fri, 22 Feb 2019 00:00:00 +0000

CocoaPods 1.7.0 expands heavily on the improved underlying infrastructure of prior releases with support for multiple Swift versions, app specs and more!

This is a huge release which contains a variety of new features to help propel CocoaPods forward.

Let's jump right in!

Support For Multiple Swift Versions

The swift_version DSL that was first introduced in CocoaPods 1.4.0 has now been expanded to support multiple Swift versions. This helps pod authors and gives consumers more flexibility when it comes to choosing which version of Swift to use when consuming a pod.

Pod authors can now transcribe that information into their podspec by simply specifying the additional Swift versions within the swift_versions DSL.

Here's an example podspec that specifies additional Swift versions it supports:

Pod::Spec.new do |spec|
  spec.name = 'CoconutLib'
  spec.version = '1.0'
  # ... rest of root spec entries go here
  spec.swift_versions = ['3.2', '4.0', '4.2']
end

Unless or otherwise specified by the consumer of the CoconutLib pod, CocoaPods will automatically select the latest version of Swift during installation which in this example will be 4.2.

However, there are many cases in which consumers of a pod might be unable to use the latest Swift version, perhaps because their toolchain does not support it yet. For example, a project that is using an older version of Xcode that does not support Swift 4 will be unable to integrate the CoconutLib pod and would end up with a compilation error. To solve this, CocoaPods 1.7.0 provides the ability to specify Swift version requirements through the new supports_swift_versions DSL for each target that is integrated within the Podfile.

For example:

target 'MyApp' do
  supports_swift_versions '>= 3.0', '< 4.0'
  pod 'CoconutLib', '~> 1.0'
end

The above configuration will successfully integrate CoconutLib pod and use Swift 3.2 as the version to compile it with. This is because it is the only version satisfied by the requirements specified in the MyApp target definition and by the list of supported versions of Swift declared within the CoconutLib podspec.

Note: The supports_swift_versions DSL can also be declared at the root level of a Podfile in which case it will apply to all targets within the Podfile. Furthermore, nested targets (such as test targets) will inherit their Swift requirements from their parent unless they explicitly specify their own Swift version requirements.

There are many other edge cases that can occur when choosing which Swift version to use. We encourage you to read through the proposal for this change to find out more!

Linting And Validation

It is generally difficult for pod authors to maintain infrastructure to support multiple (primarily older) versions of Swift, therefore, during lint CocoaPods will choose the latest version of Swift during validation.

For pod authors who do have the infrastructure (such as a CI system) that ensures their pod works with older versions of Swift, the --swift-version parameter should be used during lint to override the default behavior.

Deprecating `.swift-version` File

Up until now, most pod authors have been relying on specifying a .swift-version file at the root of their repo in order to successfully publish their pod with the Swift version they officially support. However, this information is never transcribed within the published podspec and therefore during integration none of it is taken into consideration when choosing which Swift version to use.

This can cause numerous issues especially when a new version of Swift is released. This is because a consumer will automatically pick the latest version of Swift to use without the pod author officially claiming that it is supported.

We strongly recommend pod authors to migrate over to use the officially supported swift_version DSL within their podspec instead.

We also recommend deleting the .swift-version file in your repo unless you use it for other tools such as swiftenv. The swift_version DSL will always take precedence over the .swift-version file.

Finally, a warning will be displayed during lint that encourages pod authors to migrate away from using the .swift-version file and in a future major release of CocoaPods we plan to completely remove support for it.

App Specs

With the recently introduced test specs we were able to build a platform for us to expand on and introduce different types of specifications that can be provided by a pod author. With 1.7.0, we are introducing app specs which allow pod authors to describe an application from within their podspec.

App specs can help pod authors in various ways, for example, they can be used to ship a sample app alongside their pod as a tutorial on how consumers can integrate it to their own respective app.

App specs progress forward the concept of 'Isolated Development' in which a podspec can be used as the single piece of information needed to generate an entire (throwable) workspace to develop on.

Here's an example of an app spec declaration:

Pod::Spec.new do |s|
  s.name         = 'CoconutLib'
  s.version      = '1.0'
  s.authors      = 'Coconut Corp', { 'Monkey Boy' => 'monkey@coconut-corp.local' }
  s.homepage     = 'http://coconut-corp.local/coconut-lib.html'
  s.summary      = 'Coconuts For the Win.'
  s.description  = 'All the Coconuts'
  s.source       = { :git => 'http://coconut-corp.local/coconut-lib.git', :tag => 'v1.0' }
  s.license      = {
    :type => 'MIT',
    :file => 'LICENSE',
    :text => 'Permission is hereby granted ...'
  }

  s.source_files = 'Sources/*.swift'

  s.app_spec 'SampleApp' do |app_spec|
    app_spec.source_files = 'Sample/*.swift'
  end  
end

App specs can leverage the majority of the CocoaPods spec DSL to declare dependencies, build configuration settings, etc.

By default, app specs are not automatically integrated to a project that is consuming the pod. If you wish to do so you can specify this in your Podfile, similar to test specs:

 target 'MyApp' do
   use_frameworks!
   pod 'CoconutLib', '~> 1.0', :appspecs => ['SampleApp']
 end

We hope in the future to promote app specs to a top-level concept in which consumer applications are described as an app spec completely eliminating the need of maintaining an .xcodeproj in order to integrate with CocoaPods.

Multiple Xcodeproj Generation

Historically, CocoaPods has always generated a single Pods.xcodeproj that contains all the required targets and build settings for your project to compile. Using just one project that incorporates your entire Podfile works just fine for smaller projects; however, as your project grows, so will the size of your Pods.xcodeproj file.

The larger the Pods.xcodeproj file, the longer Xcode has to spend parsing its contents, which we have discovered leads to a degraded Xcode experience. Instead of putting all of your targets into one monolithic Xcode project, we’ve noticed some considerable performance improvements for larger CocoaPods projects by integrating each pod as its own separate Xcode project and nested under the top-level Pods.xcodeproj.

Additionally, in large codebases this feature can prove particularly useful as developers may opt-in to open only the specific .xcodeproj they need to work on (found under the Pods/ directory) instead of opening the full workspace which can slow down their development process.

Whether performance is a problem, or you just prefer setting up your workspace using multiple Xcode projects, CocoaPods now supports this setting using the generate_multiple_pod_projects installation option.

You can enable this in your Podfile like so:

install! 'cocoapods', :generate_multiple_pod_projects => true

By default, this option is turned off, but we encourage you to try it out and report any issues you find to us. We expect that going forward in a future major version update to CocoaPods this becomes the default option when it comes to workspace generation.

Here's how it looks:

Without multi-xcodeproj (default):

With multi-xcodeproj:

Warning: Switching your project to use multiple .xcodeproj may result in some compiler errors if your pods have relied on importing headers using the quote syntax for its dependencies. For example #import "PDDebugger.h" will no longer work in a pod that depends on PonyDebugger. Instead, we highly suggest you update your headers to correctly import the framework and its associated header: #import <PonyDebugger/PDDebugger.h>. This is intentional since this feature is currently opt-in.

Incremental Installation

Instead of regenerating your entire workspace every time you run pod install, CocoaPods now supports only regenerating the pod targets that have changed since your previous installation. Depending on the size of your project, this can save anywhere from a couple seconds to minutes off every pod install invocation.

You can enable this in your Podfile with the installation option incremental_installation like so:

install! 'cocoapods',
         :generate_multiple_pod_projects => true,
         :incremental_installation => true

Note: The incremental_installation option currently requires the generate_multiple_pod_projects installation option to also be enabled in order for it to function.

`scheme` DSL

Pod authors are now able to customize the generated scheme for their specs, test specs and the newly released app specs. For now, support for specifying environment variables as well as launch arguments is included and it can be easily expanded in the future.

Here's an example:

Pod::Spec.new do |spec|
  spec.name = 'CoconutLib'
  spec.version = '1.0'
  # ... rest of root spec entries go here
  spec.test_spec 'Tests' do |test_spec|
    test_spec.source_files = 'Tests/**/*.swift'
    test_spec.scheme = { 
      :launch_arguments => ['Arg1', 'Arg2'], 
      :environment_variables => { 'Key1' => 'Val1'}
    }
  end
end

The above will example with produce the following scheme for the test spec Tests:

Note: You may opt to configure a scheme for a specific platform. For example, test_spec.ios.scheme will only configure the scheme for iOS targets.

`.xcfilelist` Support

In CocoaPods 1.7.0 script phases now support usage of .xcfilelist in order to specify script input and output paths. CocoaPods will automatically detect whether the Xcode project being integrated supports .xcfilelist and prefer that over separate input/output path entries.

This reduces the amount of footprint CocoaPods has into the user project but also leverages the ability to use different input/output paths per configuration (e.g. 'Debug' vs 'Release').

Experimental Features

Along with 1.7.0 we are shipping a couple of exciting and important experimental features!

CDN Support For The Master Specs Repo

The master specs repo is crucial to the functionality of CocoaPods, however, over the years its size has grown dramatically making it the number one difficulty to onboard with CocoaPods.

This is especially true for folks with a slow internet connection since cloning the repo and its entire history becomes almost impossible. Additionally, CI systems are also slowed down dramatically for first time setup since again cloning can take a long time.

In 1.7.0 we are experimenting with CDN support to avoid cloning the master specs repo on your local machine (or CI) in order to use CocoaPods. This can be enabled by doing replacing the source of the master specs repo declaration in your Podfile with:

# source 'https://github.com/CocoaPods/Specs' comment or remove this line.
source 'https://cdn.jsdelivr.net/cocoa/'

Optionally, you may delete the existing git based repo by running pod repo remove master.

We are expecting either the syntax or the server structure to change again with 1.8.0, and so in adopting this feature in 1.7.0 you should be expecting to have to make changes in the future to keep this working. We don't intend to support the 1.7.0 version outside of 1.7.x releases.

We would like to thank jsDelivr for their support and help to make this work! For now, we currently plan to maintain both ways of consuming the master specs repo but we strongly encourage you to switch as it is much faster to get started with CocoaPods.

Depending on the results and stability, we hope that starting with 1.7.0, CocoaPods will no longer require users to clone the master specs repo in order to get started.

Windows Support

Starting with 1.7.0, we've added support for Windows! We encourage Windows users to use CocoaPods and report any issues to us going forward.

What's Next?

CocoaPods 1.7.0 is a very exciting release, and we're very happy for you to try it out, and recommend you upgrade:

$ gem install cocoapods --pre

For future versions, we hope to substantially improve the integration story of CocoaPods.

Currently, consumers of pods are limited to an all-or-nothing approach to integrate their project by forcing them to make a choice on whether to use dynamic frameworks everywhere or static libraries everywhere via the use_frameworks! option.

On the other hand, pod authors are also very limited for the options in which they can specify how their pod should be packaged and linked to the consumer target and have to ensure their pod can compile across different permutations of package and link styles. We are in the early stages of planning on how we can improve this further and give both pod authors and consumers better choices.

As always, we would like to thank all of our contributors for making this release a reality!

Checkout the changelog to get the full list of changes.

🚀

CocoaPods 1.6.0 Beta Begins!

Thu, 16 Aug 2018 00:00:00 +0000

CocoaPods 1.6.0 release continues our focus on stability, performance and scalability for large projects.

We are happy to announce that the first beta of 1.6.0 is now available! In this release, we revamped the build settings generation process to be faster and easier to maintain going forward. We've also enhanced the integration of multiple test specs in the same pod.

Revamped Build Settings

The generation of build settings (which reside within the .xcconfig files CocoaPods generates) has been completely rewritten. The primary goal for this rewrite was to clean up the code and make it scale much better on large projects.

When contributors to CocoaPods make build setting changes it would often cause a cascading amount of performance regressions and trigger an unusual combination of edge cases. This made it very hard to test these changes and verify that each fix works correctly for everyone.

From a user point of view, this rewrite should have zero effects when you compile your code. If there is anything that does not look right please file an issue providing steps and include a sample app that demonstrates the problem.

To demonstrate the results of this rewrite we worked closely with our friends at LinkedIn, who use CocoaPods on a large project. The rewrite, along with some other performance improvements, have decreased pod install time down to approximately 40 seconds from the original time of 3 minutes or 77% faster.

This change, while mostly invisible, helps guarantee that CocoaPods will scale with your app as it grows. We really want to thank the folks at LinkedIn for their contributions to CocoaPods as well as their time spent to improve this.

Enhanced Test Spec Integration

Test specs are becoming a fundamental piece of CocoaPods for pod authors. The ability to specify your test sources and have them execute through lint make this feature an invaluable tool and allow to make the podspec file be the source of truth for your library. Starting with 1.6.0, multiple test_spec entries will no longer generate a single test bundle target but instead generate a unit test bundle for each one.

Let's use the following as an example:

Pod::Spec.new do |s|
  # ... rest of root spec entries go here

  # Unit Test Sources - Those do not require an app host to run. 
  # They also require 'OCMock' dependency.
  s.test_spec 'Tests' do |test_spec|
    test_spec.source_files = 'Tests/**/*.{h,m}'
    test_spec.dependency 'OCMock'
  end

  # SnapShot Tests Sources - Those *do* require an app host to run.
  s.test_spec 'SnapshotTests' do |test_spec|
    test_spec.requires_app_host = true
    test_spec.source_files = 'SnapshotTests/**/*.{h,m}'
  end

Both the 'Tests' and 'SnapshotTests' test specs would merge into a single unit test bundle target. This also had the unwanted effect of using an app host for the 'Tests' test spec without explicitly having been declared by the pod author.

It looked like this:

This means it's impossible for pod authors to split their test sources and categorize them in different ways, for example using a different set of dependencies, resources, or compiler options.

With 1.6.0, this will now generate the following:

Much better!

We strongly support the idea of having tests for your code and we aim to build the right tools for supporting this with CocoaPods. Having your podspec be the source of truth and coupled with recently released cocoapods-generate plugin your developer experience can be much improved and streamlined.

Longer Beta Cycle

We intentionally do not commit on specific release dates for CocoaPods. This is primarily due to the fact that CocoaPods is maintained and improved by the free time of multiple people across the world. Making such commitments would be tough to meet and most likely disappoint everyone.

The 1.6.0 release will run through a longer beta cycle and will carry the 'beta' name for some time before it's stable. We encourage you to use the 1.6.0 beta and help us by submitting any issues you find.

To install it use:

$ gem install cocoapods --pre

What's Next?

We always like to use this last bit of the blog post as an opportunity to express what we have in mind for the next release (currently aimed to be 1.7.0). More particularly, we would like to extend the swift_version DSL to support a range of Swift versions instead of just a single version similarly to Swift Package Manager.

Finally, we've been heavily improving the internals of the library and investigating on how to make the pod install process incremental and change it in ways that make Xcode cope better with very large projects to be more responsive.

Thank you for making CocoaPods 1.6.0 a reality! We've come a long way.

Checkout the changelog to get the full list of changes.

CocoaPods 1.5.0 — Swift Static Libraries

Wed, 04 Apr 2018 00:00:00 +0000

CocoaPods 1.5.0 comes with native support for building Swift pods as static libraries.

Just a few months after the release of CocoaPods 1.4.0, we're releasing a new version that focuses on enabling everyone to adopt Swift.

Swift Static Libraries

Up until Xcode 9, support for building Swift into static libraries was non-existent and use of dynamic frameworks was required. This was a deal-breaker for some developers, particularly those worried about the launch performance implications of linked many dynamic binaries.

With CocoaPods 1.5.0, developers are no longer restricted into specifying use_frameworks! in their Podfile in order to install pods that use Swift. Interop with Objective-C should just work. However, if your Swift pod depends on an Objective-C, pod you will need to enable "modular headers" (see below) for that Objective-C pod.

Modular Headers

When CocoaPods first came out many years ago, it focused on enabling as many existing libraries as possible to be packaged as pods. That meant making a few tradeoffs, and one of those has to do with the way CocoaPods sets up header search paths. CocoaPods allowed any pod to import any other pod with un-namespaced quote imports.

For example, pod B could have code that had a #import "A.h" statement, and CocoaPods will create build settings that will allow such an import to succeed. Imports such as these, however, will not work if you try to add module maps to these pods. We tried to automatically generate module maps for static libraries many years ago, and it broke some pods, so we had to revert.

In this release, you will be able to opt into stricter header search paths (and module map generation for Objective-C pods). As a pod author, you can add 'DEFINES_MODULE' => 'YES' to your pod_target_xcconfig. Alternatively, in your Podfile you can add use_modular_headers! to enable the stricter search paths and module map generation for all of your pods, or you can add :modular_headers => true to a single pod declaration to enable for only that pod.

Tracking Installation Sources

This change happens behind-the-scenes, and opens up some exciting possibilities. CocoaPods will now store the specs repo that a Pod has been sourced from:

SPEC REPOS:
  https://github.com/CocoaPods/Specs.git:
    - Alamofire
    - Moya
  https://github.com/Private/Internal.git:
    - InteralPod

This will enable CocoaPods to be able to tell you when the source for a pod has changed, and will also force a noticeable git diff in the Podfile.lock, making sure you're aware when a Pod comes from a different source. This makes it possible to audit that your private forks are being used, instead of public specs, for example. We consider this a helpful security enhancement, especially for those teams with Security Engineers peering over their shoulders.

Further Improvements

CocoaPods will no longer add all header search paths for each xcconfig generated and instead, it only adds the header search paths for the dependencies of the pod
Static frameworks allow mixing Objective-C and Swift
During pod validation, any output from xcodebuild is now streamed when using --verbose
pod install performance is improved both for pods with many subspecs, as well as pods which specify exact file paths rather than globs
Script phases used by CocoaPods will now assert that all expected build settings (and environment variables) are set
Integrating static library pods into static library targets will not cause copy script phases to be run

Summary

CocoaPods 1.5.0 is an exciting release. We're very excited for you to try it out, and recommend you upgrade:

$ gem install cocoapods

After all of this excitement, here's a taste to whet your appetite for the next CocoaPods version. For 1.6.0, we're focusing on redesigning core parts of the library to improve CocoaPods performance for very large applications. So, if you're feeling like pod install is taking a tad longer than you'd like, stay tuned 😉

As always, we would like to thank all of our contributors for making CocoaPods 1.5.0 a reality!

Checkout the changelog to get the full list of changes.

New Service: CocoaPods Metadata generation

Fri, 16 Mar 2018 00:00:00 +0000

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 cocoapods.org 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:

install_size
total_files
total_comments
total_lines_of_code
doc_percent
readme_complexity
initial_commit_date
rendered_readme_url
license_short_name
license_canonical_url
total_test_expectations
dominant_language
builds_independently
is_vendored_framework
rendered_changelog_url
rendered_summary
spm_support

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:

rendered_readme_url
license_short_name
license_canonical_url
rendered_changelog_url

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.

CocoaPods 1.4.0 — Feature packed!

Thu, 18 Jan 2018 00:00:00 +0000

CocoaPods 1.4.0 comes packed with new features such as app host support for tests, script phases, static framework support and a new Swift version DSL!

Just after few months after the release of CocoaPods 1.3.0, we unveil a new version that adds a bunch of new powerful features. Let's get right into it!

App host support for test specs

CocoaPods 1.3.0 introduced support for test specs, but initially, pod authors were unable to use test specs that required an app host. With 1.4.0, you can now specify that an app host is required in order for your tests to execute.

You can accomplish this by using setting the requires_app_host attribute within your test spec:

s.test_spec 'Tests' do |test_spec|
  test_spec.requires_app_host = true
  test_spec.source_files = 'Tests/**/*.{h,m,swift}'
end

Once enabled, CocoaPods will automatically create a stub app host and link it with your test bundle targets. This enables you to describe test sources that use UIKit in order to function. CocoaPods will re-use the same app host across all test specs integrated in your project. For iOS, the app host generated by CocoaPods creates and adds an empty view controller.

Note: App host support is not currently available for the watchOS platform.

We've also made quite a few fixes since the initial launch of test specs in 1.3.0, so we highly recommend upgrading and start using test specs!

Script Phases

Script phase integration has been a long-awaited and a powerful new feature of CocoaPods 1.4.0. Pod authors as well as app developers can now use CocoaPods to integrate script phases within their podfile or podspec.

Podfile

For app developers, each target now allows you to specify a script_phase attribute which will automatically integrate a script phase to your target. Here's an example:

source 'https://github.com/CocoaPods/Specs'

install! 'cocoapods'

platform :ios, '9.0'

target 'SampleApp' do
  pod 'Alamofire'
  script_phase :name => 'Hello World', :script => 'echo "Hello World"'
end

This will yield the following result:

This allows you to represent script phases for your app targets within your podfile without having to maintain them within your .xcodeproj. Each script phase is prefixed with [CP-User] so you can easily distinguish it as your own, and know that it has been automatically added by CocoaPods. You can have multiple script phases per single target and the order in which you specify them is the order that they will be added into your target.

Podspec

It is often the case that libraries may want to perform a few tasks during compilation. Up until now, pod authors were only able to perform a configuration task via the the prepare_command attribute, however, this only executes when your pod is first installed or updated. Additionally, during execution of the prepare_command, none of the Xcode environment variables are set as they are during build execution.

With CocoaPods 1.4.0 you are now able to specify a script_phase attribute within your podspec that executes as part of the build process of your pod, giving you full access to the Xcode build environment. Let's take a look at an example using our favorite sample pod 'CannonPodder':

Pod::Spec.new do |s|
  s.name         = 'CannonPodder'
  s.version      = '1.0.0'
  s.summary      = 'CannonPodder for the win.'
  s.homepage     = 'http://cannonpodder-corp.local/cannonpodder-lib.html'
  s.description  = 'All the Cannons'
  s.source       = { :git => 'http://somewhere.com/cannonpodder.git', :tag => '1.0.0' }
  s.license      = { :type => 'MIT', :text => 'Permission is hereby granted ...' }

  s.ios.deployment_target = '9.0'
  s.osx.deployment_target = '10.10'

  s.script_phase = { :name => 'Hello World', :script => 'echo "Hello World"' }

  s.source_files = 'Sources/**/*.{h,m,swift}'

  s.private_header_files = 'Sources/Internal/**/*.h'
end

The above will automatically add a script phase to the CannonPodder-iOS and CannonPodder-macOS targets generated by CocoaPods. It looks like this:

If your pod supports multiple platforms, you can limit a script phase only to a specific platform, for example:

s.ios.script_phase = { :name => 'Hello iOS World', :script => 'echo "Hello iOS World"' }

The above example will only add a script phase to the CannonPodder-iOS target.

Additionally, there are times where you would like your script phases to be executed before compilation in order to perform a configuration step, such as generate some sources or perhaps perform a lint check. Support for this is included with CocoaPods 1.4.0 via the :execution_position attribute within each script_phase entry.

For example:

s.script_phase = {
  :name => 'Hello World',
  :script => 'echo "Hello World"',
  :execution_position => :before_compile
}

Generates the following:

CocoaPods will automatically add the script phase before the Compile Sources phase. This effectively allows you to control at what stage you prefer a script phase to be executed and allows you to perform different type of tasks depending on the compilation phase.

Here's a slightly more complicated example that demonstrates two script phases running at different stages:

s.script_phases = [
  { :name => 'Precompile',
    :script => '${PODS_TARGET_SRCROOT}/setup.sh',
    :execution_position => :before_compile
  },
  { :name => 'Postcompile',
    :script => 'echo "yay!"',
    :execution_position => :after_compile
  }
]

Currently, the available execution positions are :before_compile, :after_compile and :any which is the default and is reserved internally by CocoaPods. When you use :any, its behavior currently matches that of :after_compile but that might change in the future. This is why it is always recommended to specify the execution_position attribute when defining a script_phase within your podspec.

In the future, we are hoping to expand the :execution_phase attribute and provide more granular options for you specify at which point should your script phase execute.

Note: If you'd like your script phase to access any of the sources of your pod during execution, then it is highly recommended to use the ${PODS_TARGET_SRCROOT} environment variable which is set for each pod and is always relative to the path of your pod sources.

Security Warning

While script phases are a powerful addition to CocoaPods, it is crucial to understand that consuming pods that include script phases may be a high security vulnerability for many. After all, this feature essentially allows pod authors to execute code on your machine if you decide to integrate their pod into your project.

For this reason, CocoaPods will always display a warning when you install a pod or if you update a pod to a new version that adds script phases as part of it's build process.

A warning would be displayed as such (click to enlarge):

Note: This warning cannot be disabled and it will appear the first time you install a pod or when an existing pod is updated and contains script phases. It is imperative that you inspect the contents of the script phase to ensure no harmful code is executed as part of your compilation process.

In a future version, CocoaPods will prompt you before executing a prepare_command for a pod in order for you to inspect its contents.

Static Frameworks

Source static frameworks is another powerful new feature of CocoaPods 1.4.0. For the first time, it is possible to distribute sources and build them into a static framework when use_frameworks! is specified in the Podfile. Because dynamic libraries cannot depend upon static libraries, it now becomes possible to distribute pods that depend upon other static library frameworks, including the many static frameworks that are released as vendored_frameworks today.

Background

A framework is a collection of a library, headers and resources. The library may be either dynamic or static. A static library is linked at build time while a dynamic library is linked and loaded at runtime.

A dynamic library cannot depend on a static library because a static library may not have the necessary relocations to be loaded at runtime and because if multiple dynamic libraries depended upon the same static library, there would be multiple copies of the static library. The multiple copies is only a code size issue for the code itself, but it will lead to functionality issues for any data in the static library.

When Apple and Xcode refer to frameworks, dynamic is typically implied. However, the lower level Apple build tools work correctly with both dynamic and static frameworks.

Historically many binary CocoaPods have been distributed as a vendored_framework that includes a static library.

Before 1.4.0, sources could only be built as dynamic frameworks. Therefore, it was not possible to depend on many vendored_framework CocoaPods. Also, it was not possible for a vendor who delivered their pod in a binary form to convert it to a source CocoaPod and keep it as a static framework.

Usage

To enable static framework support add the following to your podspec:

s.static_framework = true

Voilà!

Swift Version DSL

With CocoaPods 1.4.0, you are now able to specify the Swift version your pod officially supports within your podspec via the swift_version attribute. Since the release of Xcode 9, multiple Swift versions are now allowed per target to be used. CocoaPods always defaulted to the Swift version your app target was using. As Swift evolves the current integration is no longer sustainable. For example, upgrading your project to Swift 4.0 does not necessarily mean that all Swift pods you consume also successfully compile with Swift 4.0 and therefore you had to wait for a new version of a pod to be published before upgrading to the latest version of Swift or resort into using a post_install hook to edit the configuration manually.

As a pod author you can now add the following to your podspec:

s.swift_version = '4.0'

This will automatically configure Swift 4.0 for the pod when it's consumed and regardless of the Swift version the app target uses. As an author you should always test and provide the known version of Swift that successfully works with your pod and update your podspec accordingly.

Note: The usage of the .swift-version file as well as the --swift-version parameter during lint is now deprecated. You may continue to use it but you will receive a warning to use the swift_version attribute instead.

We aim to improve support for this feature in the future by allowing pod authors to specify a range of Swift versions their pod supports instead of a single Swift version, but for the majority this will be sufficient. We would like to remain detached from Apple's Swift roadmap and not to have to perform releases of CocoaPods as new versions of Swift and Xcode are introduced.

Transition to `https`

With this release, publishing a pod using an unencrypted http source is now deprecated and it is highly recommended to begin the process of hosting your pod using an https source. A warning will appear if you attempt to publish a pod in the master repo that's not using an https source. In a future release this will become more strict and you will be unable to publish a pod without an https source.

Additionally, during installation consumers of pods with unencrypted http source will also receive a warning notifying them that the source in which the pod is hosted may be unsafe.

Development Pod Files

It is often very useful when you are developing locally on a pod (using the :path directive) to have all of its associated files (such as documentation files, its podspec and license files) to be easily available and visible so you can view and edit them. In 1.4.0, all of these files are now automatically added to the generated .xcodeproj! The following files will be automatically added to the workspace:

Podspec
Docs (in a folder which matches the glob pattern doc{s}{*,.*})
Custom module map (using the podspec's module_map attribute)
Prefix header (using the Podspec's prefix_header_file attribute)
License (using either the Podspec's license attribute, or automatically found with the glob pattern licen{c,s}e{*,.*})
README (matching the glob pattern readme{*,.*})

This should enhance your development experience when working with a pod locally.

Summary

CocoaPods 1.4.0 is a huge release for propelling iOS development forward and introduces many powerful features. We are very excited for you to try it and highly recommend you upgrade!

Special thanks to all the contributors for CocoaPods 1.4.0, we couldn't have done it without you.

Checkout the changelog to get the full list of changes.

CocoaPods 1.3.0 — Test specifications and performance improvements

Tue, 01 Aug 2017 00:00:00 +0000

TL;DR: CocoaPods 1.3.0 has been released, which includes support for test specifications and performance improvements specifically around rebuilding your project and preparation for Xcode 9 support!

We are happy to announce that CocoaPods 1.3.0 has been released! The primary feature of this release is support for test specifications. Up until now, podspecs were not able to describe test sources which made it difficult to test your pods and required custom workarounds to represent your test sources via other means. With this release, you are now able to describe your test sources within your podspecs!

Let's see an an example podspec:

Pod::Spec.new do |s|
  s.name         = 'CoconutLib'
  s.version      = '1.0'
  s.authors      = 'Coconut Corp', { 'Monkey Boy' => 'monkey@coconut-corp.local' }
  s.homepage     = 'http://coconut-corp.local/coconut-lib.html'
  s.summary      = 'Coconuts For the Win.'
  s.description  = 'All the Coconuts'
  s.source       = { :git => 'http://coconut-corp.local/coconut-lib.git', :tag => 'v1.0' }
  s.license      = {
    :type => 'MIT',
    :file => 'LICENSE',
    :text => 'Permission is hereby granted ...'
  }

  s.source_files = 'Sources/*.{h,m}'

  s.test_spec 'Tests' do |test_spec|
    test_spec.source_files = 'Tests/*.{h,m}'
    test_spec.dependency 'OCMock' # This dependency will only be linked with your tests.
  end  
end

Test specifications work just like subspecs, but they are treated differently by CocoaPods when it comes to integration. Any sources and headers you specify will be automatically added to your test target and all dependencies specified under test specs will only be linked to your test target. By default, test specs have a dependency to their parent, include all of its transitive dependencies and can import all of its headers (including private headers) for testing.

Note: As of right now, test specs will generate unit test bundles which require no app host to be executed. Support for test specs with app hosts will be added in the near future.

We also updated the lint process to automatically build and run your test sources if any test specifications are present. This functionality is turned on by default and lint will fail if any of your test sources fail to compile or a test run fails. Finally, the flag --skip-tests has been added to skip tests during lint if for any reason you wish to skip running tests.

If you wish to consume the tests of a pod, perhaps for local development, then you will have to specify the test specs in your Podfile. For example:

 target 'MyApp' do
   use_frameworks!
   pod 'CoconutLib', '~> 1.0', :testspecs => ['Tests']
 end

When you execute pod install this will automatically create a test target for the CoconutLib called CoconutLib-Unit-Tests.

Note: Support for automatic execution of tests has been added to all generated pod xcschemes. This means you are now able to CMD+U on the generated pod target to run its tests without having to create or add the test scheme manually.

Test specifications are a powerful addition to CocoaPods and allows you to represent your test sources within your podspec. It was one of the missing pieces of making podspecs the source of truth for describing your libraries. CocoaPods does a great job in leveraging the file system as the source of truth for library organization and now the same applies to your test sources. This also means you can now have your CI environment build, test and publish your pod using lint as the only command, saving you from managing Xcode projects manually.

Performance Improvements

With this release, we also tackled some of the largest pain points of CocoaPods development. In particular, there are three major updates that address the following:

All CocoaPods script phases (such as 'Embed Pods Frameworks' and 'Copy Pods Resources') now utilize Xcode's input and output paths. This means that those phases will not execute again unless any of their inputs or outputs have changed. This is automatically managed by CocoaPods as you add or remove pods in your Podfile. This should save a lot of time for developers who often iterate by making a single file change and want fast rebuilds. Internally, we've witnessed cases where without editing a single source file it would take 10-15 seconds to complete a rebuild, however, with CocoaPods 1.3.0 the same process now takes less than a second.
CocoaPods generates a handful of files each time you execute pod install. Those files are necessary for CocoaPods to function and properly integrate your project. However, by regenerating those files even with the same content, Xcode would treat them as "dirty" and often rebuild your project from scratch. This is no longer the case with CocoaPods 1.3.0. The content of each file now is now compared and unless it has changed the file will not be re-written. Executing pod install again should not cause any of your pods that haven't changed to rebuild.
We've applied a few performance improvements for speeding up pod install times. This is particularly beneficial for large complex projects with multiple targets and a large number of pods. Keeping pod install times low allows developers to execute faster by generating their workspace more quickly.

Notable Enhancements

There are a few other things worth noting for this release:

CocoaPods will automatically detect and copy the .dSYM files of vendored dynamic frameworks. Place the .dSYM next to your .framework for CocoaPods to detect it and copy it to the onto the folder specified by ${DWARF_DSYM_FOLDER_PATH}.
Each lint execution now runs in a unique temp folder. This allows for running multiple lint processes in parallel, for example within a CI environment.

Checkout the changelog to get the full list of changes.

Xcode 9

Apple is moving fast on releasing Xcode 9. We've taken notice and we are performing all necessary steps required to ensure a smooth transition. We've also seen some new major features, such as the ability to include Swift sources within static libraries and are looking to support them as fast as we can.

CocoaPods 1.3.0 is an important milestone for CocoaPods as it is maturing as the standard library for iOS dependency management. We would like to thank all contributors for their support and time spent to improve this project!

CocoaDocs documentation sun-setting

Tue, 28 Mar 2017 00:00:00 +0000

TL;DR: CocoaDocs will stop generating DocSets for new libraries and versions using CocoaPods towards the end of May.

I started CocoaDocs back in February 2013, and have been running and maintaining it for the last 4 years. CocoaDocs started as a way to generate documentation for Objective-C projects via Appledoc. When Swift came out, Jazzy support was added to the app. Since then, CocoaDocs has grown organically over the years into a tool to generate useful metadata for any CocoaPods library used in the CocoaPods.org website.

I intend to remove the support for generating HTML pages and DocSets for new libraries uploaded to trunk by the end of May.

I would like to reduce the complexity in CocoaDocs. It's rare for a week to go by without an issue or two in the CocoaDocs repo about a specific library, or tooling setup that requires human intervention on the server. These issues arise from either Xcode itself, or tools which rely on Xcode infrastructure to do their work. This makes it hard to fix wholesale.

By removing these parts of the system, I can keep maintaining the aspects of CocoaDocs that are used the most: creating metrics (for search) and README/CHANGELOG summaries for CocoaPods.org.

I don't think it's fair to hoist the maintenance of CocoaDocs on other contributors to CocoaPods. It's a complex tool that requires a lot of unique knowledge in unrelated areas.

So, I think this is a great time for someone else to consider re-thinking the original premise of CocoaDocs and create something that works with Swift Package Manager as well as CocoaPods. I hear server-side Swift is becoming a thing, so maybe you can create a new service for the community with it?

Due to the lengthy time required in a Cocoa project compilation, you probably would end up with a similar architecture as CocoaDocs. This means making a simple REST server, which provides a queue-like infrastructure to parse documentation which uploads the results to a static asset host. In this case CocoaDocs uses S3, and costs somewhere in the range of $20 a month.

If you decide to give it a shot, let me know once you have a prototype and I'll happily provide as many resources as I can. We can set up web-hooks from CocoaPods Trunk too.

CocoaPods Specs Repo Sharding

Fri, 28 Oct 2016 00:00:00 +0000

In March, CocoaPods hit an unfortunate problem with our Specs Repo being rate limited.

We announced that we were planning on Sharding the Specs Repo, but were hesitant to do it instantly. Now over six months later we are planning on running the scripts.

If you are using CocoaPods 1.x - you should not see any changes.
If you are using CocoaPods 0.39 and below, you will see an error saying that your version of CocoaPods is not supported. Previous to this, our minimum version was 0.32.

For people who want to continue using 0.x versions, we will be replicating the Specs repo from the commit before the repo was sharded. This means you can add:


source "https://github.com/CocoaPods/Old-Specs"

To the top of your Podfile, and CocoaPods will only use the archived repo, instead of using the new repo structure. You will also need to set your local Specs repo to a version before the transition:


cd ~/.cocoapods/repos/master/
git fetch origin master
git checkout v0.32.1

To run pod install, you will also need to use --no-repo-update.

We do not have the resources to maintain multiple versions of CocoaPods in our spare time, and so we recommend that instead of doing the above, you migrate to the latest versions of CocoaPods in your projects.

We are planning to do it on Friday November the 11th, so there will be scheduled downtime on pushing new Pods to Trunk during the process of updating and verifying that it was successful.

CocoaPods 1.1.0 - Xcode 8 support, improved support for new Swift versions, extensions, frameworks, and more

Wed, 19 Oct 2016 00:00:00 +0000

TL;DR: CocoaPods 1.1.0 has been released, and it comes with improved support for extensions, frameworks, and new Swift versions, as well as Xcode 8 support and error handling improvements.

CocoaPods 1.1.0 has been released! This release features improvements for integrating extension targets into your projects, as well as support for the latest from Apple: Xcode 8, new extensions types, and the latest iOS. Specifically for those of you working with extension targets, this means smoother App Store submissions. For Xcode 8 and iOS 10, this release has support for the new Swift version settings when building your project and distributing your pods, and it has support for new target types like messages extensions and messages applications. Finally, we've integrated some new error recovery tooling to help when you encounter an unexpected error using CocoaPods, and we've made some performance improvements to pod install when running it for large projects.

Extensions

This update improves support for integrating extension and framework targets. Extensions targets are a bit different than application targets because they require a host app. For CocoaPods, this means that pod install has to locate any host targets, in which the extension belongs, to integrate those extension targets' dependencies there. This seems counterintuive at first because Xcode has no problem installing frameworks into extensions the same way that it installs them into application targets. But, when you go to submit your app with its extensions to the App Store, you will probably get some combination of these responses:

Invalid Bundle. The bundle at 'MyApp.app/PlugIns/MyExtension.appex' contains disallowed nested bundles.

and/or

Invalid Bundle. The bundle at 'MyApp.app/PlugIns/MyExtension.appex' contains disallowed file Frameworks.

It turns out that Apple expects extensions to have their framework dependencies installed in their host apps: at launch time, extensions look into their host apps' bundles to find the frameworks they need. CocoaPods 1.1.0 understands this, and it integrates your extension target's dependencies into the right place.

Frameworks

Frameworks work about the same way. A framework's dependencies must also be installed alongside that framework, into whichever targets that are going to consume that framework. There are a few new frameworks scenarios, of which CocoaPods 1.1.0 is now mindful. In each scenario below, the framework is listed in the Podfile and has some pods:

Framework(s) in your application-type project
Framework(s) in your application-type project, where the framework may live in a sub-project (i.e. an Xcode project within your Xcode project)
Framework(s)-only projects (for doing framework development)

In every case, pod install looks through each of your project's non-framework target's "Target Dependencies" build phase to find where the framework is meant to be integrated (same for extensions as well). For framework-only projects, if CocoaPods can tell that your project only contains framework targets, then it assumes that the project must be a framework-only project (for doing framework development) and emits a warning about this assumption. In that case, CocoaPods doesn't have much to do except ensure your project's targets have the headers to build properly.

Xcode 8 and iOS 10

Xcode 8 is here! It brings support for iOS 10, macOS Sierra, new versions of Swift, and new challenges for CocoaPods. The first is the ability to support Swift 2.3 and 3.0 projects. In CocoaPods 1.1.0, setting the version of Swift when linting and pushing your pod is supported in following ways:

It defaults to Swift 3.0, if your pod uses Swift.
It uses the setting from your .swift-version file if present (inspired by swiftenv).
The --swift-version flag can be used to specify a version of Swift to use. This overrides the version set in the .swift-version file.

Finally, iOS 10 makes some new extension and application types available. In particular, CocoaPods has been updated to recognize the messages extensions and application product types.

About Supporting Multiple Swift Versions in the Podspec

Because Swift doesn't use semantic versioning, supporting the Swift language version used by a pod as part of the podspec is tricky. There are a few different options we considered, but we ultimately decided not to add any new podspec dsl for this release. Here are some examples of options we considered:

We could add a swift_version option to indicate which version of Swift the pod supports. This would force authors to push new versions of their pods to update this setting when new versions of Swift come out, even if the new version of Swift is backwards compatible. This isn't ideal.
This could be helped by instead supporting a min_swift_version option to indicate the minimum Swift version the pod supports. This wouldn't force authors to update their pods when new versions come out, but it would break if a new version of Swift comes out that is not backwards compatible with the one used to build the pod.
We could add a swift_version_range option to indicate the range of Swift versions the pod supports, but this suffers from the same issues as option 2. There is no way to verify that a pod pushed today that claims to support up through Swift version 4 actually supports that version.

In this release of CocoaPods, you lint your pod against the version of Swift you intend to support. When integrating pods, CocoaPods generates pod targets that use the Swift version set in your project. This allows pod authors the flexibility to support multiple incompatible swift versions if they wish by using #if swift() checks, while keeping the pod maintenance burden light across Swift 3 versions.

Additionally, the version of Swift that was used to pass validation is baked into the podspec JSON file that is pushed to trunk. For tool authors, this makes it easy to use the database of pods on trunk to build reliable tooling that works with multiple versions of Swift.

Error Handling Improvements

Now when CocoaPods receives unexpected errors, it will highlight existing issues that might be related in the console. This makes it easier to find the answer to common issues. We do this by using gh_inspector, which you may have seen inside Fastlane too.

CocoaPods 1.1.0 was a huge release, so congrats to everyone! Checkout the Changelog to get the full list of changes.

2016 CocoaPods State of the Union

Sun, 29 May 2016 00:00:00 +0000

Apple have their annual WWDC keynote and Developer State of the Union. We have ours. We're planning a great opening event to WWDC week: The CocoaPods Alt State of the Union. You should join us, and hear about what's happened in CocoaPods in the past year, and what's to come in the next. This year's is going to be extra-special, as we'll all get to celebrate the release of CocoaPods 1.0 together 🎉

It's become an annual tradition for CocoaPods to host an event at WWDC, and we want to make this another great one. Last year, we tried out a new lottery system, and we'll be using it again this year. To register, just go to https://sotu.cocoapods.org and authenticate with GitHub.

Registration is open to everyone with a GitHub account. Twilio have graciously offered to host us again this year, June Thirteenth (Monday) at 6:30 PM, and we can't wait to see you all!

All of the details, as well as the lottery registration link, are available at https://sotu.cocoapods.org/. We'll be closing the lottery and announcing the lucky entrants in one week (on June 5th), so hurry up and register!

CocoaPods App 1.0

Wed, 11 May 2016 00:00:00 +0000

After about a year of work, with the release of CocoaPods 1.0, the corresponding Mac App is also ready for public usage.

This is no big reveal, we've been advertising it's existence on our websites for a while. I've already talked a little bit about the tech behind the Mac App, so this post is the one that makes you say your team "we should use this instead of the gem".

So let me put my best hat on, and try to pursuade you that using the CocoaPods Mac App is a great idea.

What problem does this solve?

CocoaPods exists within the ruby ecosystem. The majority of Cocoa developers don't have much overlap with writing ruby programs. Installing and maintaining multiple versions of command-line tools like CocoaPods is something that people have to learn in order to use CocoaPods effectively.

This creates a problem which Bundler solves really well, but now you're starting to really dive into the ruby ecosystem and the pre-requisite knowledge to contribute raises again. While I'm on my soap-box, if you're using the CocoaPods and Fastlane gems in an app, you probably should be using Bundler.

So the CocoaPods app hosts everything. Literally, it has it's own self-contained copies of bzr, curl, git, mercurial, ncurses, openssl, pkg-config, ruby, scons, serf, subversion, yaml and zlib. This allows the CocoaPods team to ensure consistent behavior across all user setups.

This concept is not new for Cocoa developers, as Xcode has been embedding its own dependencies inside it's .app since it moved to the Mac App Store. The advantage from a user's perspective is that it works, and you can install your own crazy version of git, or curl or ruby, and it just works.

What does it do well?

Glad you asked, 'cause it does two things really well:

Running pod install or pod update
Editing a Podfile

That was basically the spec for the app from day 1. Once @alloy had proved that pod install/update was working, @nate_west and I took over and started working on the latter.

Podfile Editing

Some of these features are mundane, "hey, wow, syntax highlighting</sarcasm>" but others are really fascinating deep levels of context-specific integration that you'd expect from an IDE.

We've started out with syntax highlighting, and then added useful examples of auto-completion results that show how to use the Podfile DSL.

The app will auto-complete your pods, including private pods. This feels magical when you don't expect it. We've been having discussions about ways to introduce more of the internal CocoaPods knowledge into the auto-complete like this - you're welcome to help out.

The app will generate an overview of what your integration will look like without needing to be installed, so you can understand what CocoaPods will do before it has done it.

The app provides a UI for updating your Specs repos, you can find out a little bit more about why this is needed in our Master spec-repo rate limiting post‑mortem.

It also has the ability to start a new CocoaPods project, or to even remove CocoaPods from a project entirely. I don't want to give away all of the app's secrets though, so you should give it a test run.

Check the site Download App

Thanks

It wouldn't be an announcement without a thanks to people involved, it's a fascinating project to work on due to the interesting layers of tech involved, but one of the coolest things about building this app, is that it provides a project for people who are Cocoa developers to contribute back without learning a new language. So we've been recieving a lot of PRs to the app, and it is always a joy to work with more.

I want to specifically call out Nate West, who has been working with me on the app through-out 2016. His contributions to this project have been significant, and through this he's contributed to more of our core projects.

We have a lot of ideas for where the app can go, and some low-hanging fruit for contributors. Why not help us with take it somewhere new?

CocoaPods 1.0

Tue, 10 May 2016 00:00:00 +0000

I'm incredibly happy to say that, after an incredible four and a half years of development, we just released CocoaPods 1.0. It's been a long road to get here, but the journey has told the story of the larger Cocoa open source community -- from new versions of Xcode to new languages and platforms, CocoaPods has grown over the years to support a staggering number of developers.

Across all of our various projects, we've accumulated ~20,000 commits by ~400 developers, closing ~22,000 issues -- it’s truly been a community effort to get here to ~19,000 pods and ~86,000 versions. With this release, we're committing to keep CocoaPods stable, and promising that it's ready to be used in production (see this entry in our FAQ we've been dying to delete for years).

Since adding stats a year ago, we got a real idea for the scale of CocoaPods’ impact. CocoaPods has been used to integrate ~285,000,000 pods into ~850,000 unique Xcode targets.

Changes

Let's get the changes in 1.0 out of the way first. The overarching principle we followed was to prepare CocoaPods, the tool, for the next five years - rather than introducing any individual feature. CocoaPods is a tool that many rely upon to get their work done, and we don't take that trust lightly -- we decided to make breaking changes in one fell swoop so we won't need to do so again for a long time.

The following are the highlights of the 1.0 release, but it’s been seven months since our last minor release, 0.39 (four and a half of those were the 1.0 beta period). As you might imagine, we’ve accrued quite a few changes, big and small, and you can find the summary of all 750 of those commits in the CHANGELOG. (The CHANGELOGs for the other projects under the CocoaPods organization likewise detail all of the other changes we’ve made during this time.)

Podfile DSL

By far the largest and most disruptive change, we've altered the way Podfiles work to make them better align with how we develop Cocoa applications. We recently put out a migration guide a few months ago detailing the majority of the changes -- we anticipate that most people will be able to migrate the most complicated of Podfiles in under ten minutes.

Here’s the tl;dr:

All targets have to be explicitly defined in the Podfile, and their names have to match up with the target name in Xcode.
Some command line options have been moved to Podfile installation options.
There’s a new target inheritance option that’s made to allow test targets to only inherit the search paths of an app target.
Abstract targets are now a thing. This makes sharing dependencies across platforms a lot less repetitive.

Improved Linter

One of the nice features CocoaPods provides is the ability to lint a pod, ensuring the Podspec is well-formed, and giving users confidence that the libraries they’re integrating can compile for the platforms declared in the Podspec. In 1.0, we go that final mile -- pods will be compiled and imported into an actual app to guarantee that no strange build or import errors come up.

Improved Sources Handling

As we posted about last week, we've made major improvements to how we handle updating sources to ensure that the Specs repo remains fast, usable and consistent. We’re happy this issue surfaced before 1.0 -- it gave us the push we needed to revisit some of the assumptions made before CocoaPods reached its current scale, and ought to provide a better user experience in the long run.

Automatic Deintegration

Changing the targets in your Podfile will no longer cause things to break when you go to build in Xcode. We’ve also made cocoapods-deintegrate a default plugin and pod install will now ensure that any target not being integrated with CocoaPods has all traces of CocoaPods removed.

CocoaPods Master Specs Repo Lockdown

When we announced trunk almost two years ago, we began the process of locking down the CocoaPods master specs repository. With CocoaPods 1.0 comes a policy change that completes that work -- we will no longer be accepting pull requests to the specs repo. In order to ensure pod owners still have full control, we’ve introduce the pod trunk deprecate and pod trunk delete commands. While we strongly advise against deleting podspecs from the specs repo, we’re putting that decision in the hands of pod owners.

The Past Five Years

CocoaPods began its life almost five years ago as a project started by Eloy Durán, taking inspiration from Bundler and RubyGems in lieu of any system provided by Apple.

The Cocoa ecosystem has been an interesting place to run a dependency manager, given the lack of control CocoaPods has on the underlying toolchain. It’s created some interesting problems, and the occasional nightmare. In the last year, Apple has moved into the space with Swift Package Manager, and we’re really optimistic about what it means for the community on the whole.

CocoaPods isn’t going anywhere any time soon -- we’ve poured our hearts into this project, and are so grateful for all the time and love it’s gotten from people on the team as well as all our users. There’s something thrilling about working on a project that has such large ambitions, and that people choose to believe in for their day-to-day work. As long as you all are using CocoaPods, we will continue to work hard to improve it. 1.0 is just the first step on that path.

Thanks

As I mentioned earlier, CocoaPods owes an enormous amount to our community as a whole as CocoaPods has always been a reflection of the community. None of this would've been possible without everyone pitching in to make it happen.

However, there are a few people in particular I'd like to thank, because without their time CocoaPods would never have reached 1.0.

Eloy Durán

Eloy started CocoaPods, and is famously our 'final boss'. In addition to his vision for founding the project, Eloy has been brave enough to let others take the mantle and step into leadership. He established the team culture and is still often actively engaged, from helping with issues to building the foundations for the Mac app.

Fabio Pelosin

Fabio was a whirlwind for CocoaPods -- he came with no Ruby experience and over the course of a few years built a lot of the infrastructure that’s still in place today. Fabio still has the largest number of commits to CocoaPods projects, a title that won’t be wrested from him for a long time to come. He provided so much positive energy when handling thousands of GitHub issues in the early days.

Orta Therox

Orta, our Design Dictator, first joined the CocoaPods team by maintaining the pull requests on the Specs Repo, before we introduced Trunk. His first major contribution to the community was via CocoaDocs, which powered generating documentation for all pods. His work since then has been around the public-facing web infrastructure, the Mac App, community management, and design.

Florian Hanke

Florian is the only developer in this list that has never made a Cocoa app. He joined the team five years ago after meeting Eloy in Japan and has been working on the search engine for CocoaPods ever since. He was fundamental in creating Trunk, and helped out a lot with all of the CocoaPods web infrastructure simply because he enjoyed being with the group.

Kyle Fuller

Kyle helped set up important processes within CocoaPods, in addition to serving as release manager for almost a year. By helping us split the core of CocoaPods into plugins, and working on tooling necessary to manage micro-projects via CI, RuboCop and Rakefiles, Kyle laid the foundation for CocoaPods’ internal project management.

Marius Rackwitz

Marius gave himself one of the hardest jobs as a starter project - building Frameworks support for CocoaPods. This has been a multi-year project in reality, with edge-cases still popping up as the platforms evolve.

Boris Bügling

Boris has devoted considerable energy into ensuring CocoaPods supports the dizzying array of platforms, target types and Xcode project settings used in modern Cocoa apps. Additionally, he has been our consistent Triagemaster General in the fight to keep our issues under control.

Samuel Giddins

That’s me! I’ll do my best not to brag, but given I’m pushing the button (or typing a bunch of esoteric commands into a terminal) that actually does the release, I figured I’d add myself to the list. Since joining the CocoaPods Core team about two years ago, I’ve spent more hours than I can count implementing crazy new features and investigating the weirdest bugs. It’s been an absolute blast, and CocoaPods is as big a part of my life as anything else at this point. I look forward to the next 3000 commits on this little project of ours.

Let's Celebrate

CocoaPods has been a huge part of my life over the past two years. I know that it's tempting to just say finally right now, but I think this is an opportunity for something more -- it’s a chance for us to celebrate, as a community. CocoaPods is more than just a tool -- it’s a community of wonderful iOS, Mac, watchOS, and tvOS developers. It's a team of dedicated contributors who selflessly give back by answering issues and making pull requests. CocoaPods has been my home for the past two years, and on the occasion of our 1.0 release, I think it's time we celebrate. The future is bright, and we've had a great journey getting here. Now let's grab some cake and enjoy the moment.

🎉 segiddins, Patch Master & Bundler of Joy

Master spec-repo rate limiting post‑mortem

Wed, 04 May 2016 00:00:00 +0000

Recently we were made aware of issues that our users had when cloning the CocoaPods Master spec-repo, which contains specifications for projects shared by and with the community. The GitHub infrastructure team were quick to explain that this was because of us hitting CPU rate limits on their end, which turned out to be caused, besides the high volume of clones, by the default options we chose to clone this repo.

After some back and forth, we settled on the following list of causes and solutions.

Shallow clone

To ease initial setup for CocoaPods users, we performed shallow clones of spec-repos, meaning they only had to fetch the latest state of the repo. However, this meant that the GitHub servers had to spend much more time figuring out which Git objects the user already has, needs, and compute the deltas for those objects.

Therefore, we are no longer going to shallow clone spec-repos on initial setup and we’ll automatically convert existing shallow clones to full clones.

Too many fetches

To ensure the user always has access to all the available podspecs, we automatically performed a git fetch on each pod install and pod update. The amount of fetches this resulted in made the above shallow clone issue even worse. That, combined with the fact that on most pod install runs there was little need to actually update the repo, led to us changing the following:

We will no longer automatically update spec-repos on pod install. If a lockfile exists and podspecs are missing, an error will be raised that suggests the user to update their spec-repos with pod repo update.
We will still automatically update the spec-repos on pod update, because that’s implicitly what the user asks for at that time, but it’s an action taken far less often than running pod install.
Before any Master spec-repo fetching, we’ll be making use of a GitHub API that returns if a repo has changes in a far more efficient manner. This API is also used by Homebrew for this very same reason.

Too many directory entries

In the Git object model, each change to a directory results in a new ‘tree’ object and many Git operations need to traverse this tree, which internally has to be recreated through multiple steps of deltas, each of which has to be found and decompressed. Currently, spec-repos have a flat structure where all pod directories are in the same Specs directory, which at the time of writing has ~16K entries and consists of ~100K commits. Suffice to say, these are a lot of very large tree objects and thus require a lot of computation.

To fix this, we’ll shard the Specs directory of a spec-repo by hashing the pod names and create sub-directories based on the first few characters of that hash, so that there will be far fewer entries in any given sub-directory.

This will make file-system level browsing of a spec-repo less intuitive, but a solution like this was required to deal with 1 character pod names including single emoji characters. Note, though, that we have tooling that eases this, such as the pod spec which command.

Roll-out

Except for the solution to the third issue, these changes have been available since version 1.0.0.beta.6. While we already have the code in place to shard the spec-repo, activating it now would require updating the existing spec-repo and forcing < 1.0.0.beta.7 users to upgrade now, which might be a hard situation for people that need time to deal with breaking version 1.0.0 changes. We’ll be activating it not long after version 1.0.0 has been released, though, so don’t wait too long with upgrading.

Unable to upgrade just yet?

If for whatever reason you cannot upgrade to version 1.0.0 just yet, you can perform the following steps to convert your clone of the Master spec-repo from a shallow to a full clone:

$ cd ~/.cocoapods/repos/master
$ git fetch --unshallow

Thanks

We would like to thank @mhagger, @vmg, and @mikemcquaid for helping diagnose the issues and our understanding thereof; @arthurnn for his help with optimizing the way sharding should work, as well as GitHub in general for their continued generous sponsorship of hosting resources.

In addition we would like to thank @segiddins, @DanielTomlinson, and @mrackwitz, for their hard work on implementing these solutions as soon as they did.

CocoaPods Socks available for the next four weeks.

Mon, 22 Feb 2016 00:00:00 +0000

TL;DR: We’re doing crowd-funded socks for charity, using Knitout. With all profit going to charity: water.

CocoaPods was started in 2011. We are a community run project, with no large-scale corporate backing. We're often asked if we'd do something like t-shirts or hoodies.

We don't want to use CocoaPods' popularity to make money. So, we are putting all profits into a charity. Want to know more? Go see cocoapods.org/socks.

CocoaPods 1.0 Migration Guide

Wed, 03 Feb 2016 00:00:00 +0000

Major 1.0 changes TL:DR

You now have to define targets. Previously there was an available implicit target.
A target has to represent an Xcode target.
When you want to represent a collection of pods that go to multiple targets, use an abstract_target then add targets inside that. Pod dependencies are inherited by nested targets.
Targets that want to know about the pods for a target but don't need linking (for example, Test targets) can define that they inherit pods via their search paths (inherit! :search_paths).
:exclusive => true and link_with have been removed in favour of the above.
xcodeproj is renamed project to make the DSL vocabulary consistent.
We've removed the ability to declare :head on a pod—you can either use the :podspec option or point directly to the upstream repo (via git, :svn, etc.).
You can now declare installation options inside the Podfile via install! (e.g. install! 'cocoapods', :deterministic_uuids => false, :integrate_targets => false).
We've removed all DSL attributes that were classed as deprecated.
pod trunk delete and pod trunk deprecate have been introduced.
pod search improvements (this is great because it searches all your private spec repos too).
pod lib lint and pod spec lint will verify that your pod can actually be imported.

Re-targeting

A large fraction of the bug reports we receive is due to ambiguity in the Podfile. It gave a lot of freedom to create all kinds of CocoaPods setups that would work by luck of implementation details, or work but are significantly more complex than they needed to be.

In the 0.x branches the name of a target could be anything. If it was the name of a matching target then it would automatically link to the target, but if not it would create a Pods-[Name] target and you could use link_to to connect it to targets.

In 1.0+ a target has to correspond to a real Xcode target. In order to support use cases where Pods can be shared among multiple targets we added abstract_target. For example:

# Note: There are no targets called "Shows" in any Xcode projects
abstract_target 'Shows' do
  pod 'ShowsKit'
  pod 'Fabric'

  # Has its own copy of ShowsKit + ShowWebAuth
  target 'ShowsiOS' do
    pod 'ShowWebAuth'
  end

  # Has its own copy of ShowsKit + ShowTVAuth
  target 'ShowsTV' do
    pod 'ShowTVAuth'
  end
end

Note: In this example, it would be simpler to just not use the abstract_target at all, but it's an example, so let me off.

This change enforces a much stronger connection between the CocoaPods target, and makes it impossible to make a Podfile like this:

pod 'ShowsKit'

due to it having ambiguous behavior. However, the following is possible, as it declares what target to link to:

pod 'ShowsKit'
target 'ShowsiOS'

This works because the root level is classed as an unnamed abstract_target.

More Examples

Let's take a look at a really common example that is shipped as the 0.x pod lib create.

source 'https://github.com/CocoaPods/Specs.git'
use_frameworks!

target 'ORStackView_Example', :exclusive => true do
  pod 'ORStackView', :path => '../'
end

target 'ORStackView_Tests', :exclusive => true do
  pod 'ORStackView', :path => '../'

  pod 'Quick'
end

This sets up two completely independent CocoaPods targets that are exclusive to each other. Both have a copy of the library ORStackView. There is a lot going on in this Podfile; contrast that to the simpler 1.0 version.

source 'https://github.com/CocoaPods/Specs.git'
use_frameworks!

target 'ORStackView_Example' do
  pod "ORStackView", :path => "../"

  target 'ORStackView_Tests' do
    inherit! :search_paths

    pod 'Quick'
  end
end

It has an obvious hierarchy, so you can see that Pods included in ORStackView_Example will be included in the ORStackView_Tests target. The only new thing is inherit! :search_paths which means "don't link Pods into here, but let this target know they exist." This Podfile is easier to read, simpler and has less redundant information.

Off with `pod`s `:head`

Adding :head to a pod nearly always worked, except when it didn't. It is documented as this:

Finally, instead of a version, you can specify the :head flag. This will use the pod’s latest version spec version, but force the download of the ‘bleeding edge’ version. Use this with caution, as the spec might not be compatible with the source material anymore.

It was a tool that was really useful back when CocoaPods was small and it was hard to persuade people it was worth supporting any dependency manager for their projects. That time has long passed and now the flexibility that this attribute originally offered has fallen onto the side of "not worth keeping around." It would introduce extremely hard-to-debug issues for developers expecting it to mean "use the latest version of their code repo." You can either use the :podspec option or point directly to the upstream repo (via git, :svn, etc.).

Options to `install!`

In the past when we have had to support configuration options for CocoaPods we have used environment variables. These act like NSUserDefaults in that someone who knows the key can make a change, but otherwise they remain quite hidden. Though, sometimes they could be command line APIs too like --no-integrate. While these were conscious choices they eventually added up to being inconsistent over time, and we've opted to move in favour of centralizing the information in the Podfile. You can see all the available options in the guides.

This means that every developer on your team will have the same output on pod install regardless of their environment, whether in CocoaPods.app or in the command line. We've left the DSL attribute install! quite open so that future features can be built with this attribute.

Building for stability

A lot of the work for 1.0 has been around trying to simplify CocoaPods in order to provide long-lasting infrastructure. This is especially important given that the foundations that CocoaPods builds upon often shifts every June and the project is run by a handful of people in their spare time.

We also understand that running CocoaPods is about dealing with humans. With our default CocoaPods Specs repo, for example, we've had a policy of it being read-only since it was introduced CocoaPods Trunk. In reality though we've had to support editing and deleting Pods by hand on a relatively regular basis with the CocoaPods dev team being the ones having to make those decisions. With 1.0.0 we've built the infrastructure to support deleting and deprecating a CocoaPod and a CocoaPod version. We don't recommend it, but it's now there, and it's up to library owners to make the decisions around whether it's fine for their users to remove dependencies.

1.0

Finally, and probably the most important point. Once the betas are finished, I can get rid of this FAQ entry:

"CocoaPods is not ready for prime-time yet.”

Correct. Version 1.0.0 will be the milestone where we feel confident that all the basic requirements of a Cocoa dependency manager are fulfilled.

Once we reach the 1.0.0 milestone we will –for the first time ever– contact the community at large through mailing-lists such as cocoa-dev.

Which has been annoying me for as long as I've been working on CocoaPods' infrastructure / design.

🎉

RGSoC

Fri, 29 Jan 2016 00:00:00 +0000

During Summer 2015, we had the delightful opportunity to contribute to CocoaPods as part of Rails Girls Summer of Code (RGSoC). We were generously hosted and coached by GitHub. How did two newbie developers begin to work on open source, you might ask?

What is Rails Girls Summer of Code?

RGSoC is a global fellowship that funds two-woman teams to contribute to Open Source projects during a three month period. Among the available projects to work on we found CocoaPods the most interesting, even though it was on the challenging side for our skill level. For the application to be considered, we needed to find people that were willing to coach us with our coding adventure, and preferably, a place to work from. We reached out to GitHub, who offered us workspace. Five engineers signed up to coach us for an hour each week. With this configuration we were one of 16 teams accepted.

How we met the team

We met the CocoaPods team the weekend before Alt-Conf at Limon, a Peruvian restaurant. When Kyle Fuller, one of our CocoaPods coaches sent us an address and an invite for a dinner party, I thought we were meeting up for a pot luck. CocoaPods members must really enjoy cooking if they are going to host an entire dinner party was my first thought. The CocoaPods team took up nearly the entire second floor. Although, not one to clam up when meeting people, the thought of meeting an entire group, and one that chose our team to work on their Open Source project made me nervous. It was scary, at first, to meet 14 different people that might already know each other. To ease the anxiety I remembered that we had already met Kyle Fuller and Samuel Giddins, at a cafe in SOMA, and they were friendly. At Limon, we introduced each other, and listened to conversations around us. We learned a bit more about dependency managers through conversational CocoaPods. Hearing terms drop when we had only a faint idea what they meant was no deterrent, it was fuel to the curiosity fire. After dinner, we walked around the Mission, and ended up at the ice cream shop Xanath. The week we met the CocoaPods core team kicked off many other great first time experiences at AltConf, here in San Francisco.

How we organized the work

The student teacher ratio was opposite from what a learning environment usually looks like. We had 11 dedicated mentors who were willing to spend time to help us throughout the project. Most collaboration with our mentors happened remotely and many of our team members were based in other countries and timezones. Communication often started in one of the three Slack channels from organizations involved working with our project. Longer sessions and pairing were planned in advance.

To schedule sessions with mentors and coaches in different time zones, we used a combination of Google Calendar, Slack, and texts. For screen sharing, we found ScreenHero, Google Hangouts, Blue Jeans, and Skype for communication. Having screen sharing alternatives was necessary since audio, and screen sharing delays are unavoidable. In the same way that tools are unpredictable, so are life events. Flexibility is key. Not enough sleep, double scheduling, conferences, and the cold all happened. Communicating with as much time in advance when something changes, using the calendar religiously and setting alerts to avoid forgetting sessions and due dates is the way to go.

What we worked on together

During the project we worked on a couple of different things. Here are some of the main things we worked on for CocoaPods.

Together with Boris Bügling we paired on creating cocoapods-label, a plug-in for CocoaPods that annotates the Podfile with its Pod description. This is great for everyone with short memory that wants to remember what the different pods do in an efficient way. We started working on this while Boris visited San Francisco, during AltConf, and then, we continued working on it remotely, while screen sharing. We found that the best time to work on it was during Boris's evenings which were our mornings due to a 9 hour time difference. It was great to have Boris guide us and show us how to create a new plug-in, a knowledge we would have use for in the project.

When we applied to work on CocoaPods we chose to work on making CocoaPods more modular by creating plug-ins. During a planning meeting we picked issues that were interesting for us to work on.

These are the things Emma worked on

I chose to work on a couple of different things. Starting with what seemed like an easy task, to make so that Pods are listed case-insensitive in Xcode. I learned a lot about sorting and also about just finding my way around the codebase. To get that PR merged filled me with pride and energy to take on the next task. Continuing with moving the source code for cocoapods-search to its own gem and depend on it from CocoaPods it self. There is a scaffold for creating plugins for CocoaPods that I used that sets up the main structure of files and folders. From there on it came down to figuring out what code was responsible for search and copy that code to the newly created gem. I ran my local changes with Rake to make sure everything worked as it should. The tests also needed to be moved to the new gem and that proved to be more complicated than moving the source code, mostly since they required a lot of files in the fixture folder to run. One of the goals of extracting search to its own gem was to make it easier and safer to modify without messing something else up in the larger project. After I finished the extraction other contributors have continued to improve the search code even more which shows that the extraction did have a positive effect in that its easier to find and understand.

With search finished there were still a couple of weeks left of the project. I wanted to learn more about web development and collaborated with Orta on a new project called CocoaPods Stories. The idea was to give Pod users the ability to write stories about what Pods they are using and how. We didn’t make it further than the planning and research stage and we are not sure whether it will still be useful. Please ping us if you want us to contribute to this idea.

These are the things Karla worked on

After working on CocoaPods-label with Boris and Emma, CocoaPods issue #3398 'Extract UI module into its own gem', labeled d1:easy, seemed particularly appealing. Samuel Giddins set up the project scaffolding, and we outlined the first steps to work on #3398 by breaking it down into smaller steps. To extract the User Interface module, CLAide into its own gem, so that it works in isolation of CocoaPods, we had to get rid of all CocoaPods specific language, dependencies and documentation. CocoaPods syntax was challenging to spot out initially. So, pairing with Samuel and Kyle Fuller at GitHub was crucial. After cleaning up CLAide, and freeing it of CP dependencies, writing tests for all of the left over User Interface code was the next step.

For testing we used Rubocop, CodeCov, Code Climate, and Travis CI. After writing tests, and or changing tests, we had to debug quite a bit. Debugging felt like a never ending story, but it was enjoyable. We are still working on Cork, and I am looking forward to wrapping it up before Summer 2016 rolls around.

Also, if you're curious about the name, we found it fitting to name the CocoaPods-free User Interface library Cork, because Cork like CocoaPods, is also a commonly harvested part of the tree.

Conclusion

We encourage other open source projects to be a part of next years RGSoC. Teaching and learning are both great opportunities to become better at taking in information, learning how to process and apply new concepts. Not to mention, when you teach something that you know, or think you know it really encourages you to examine your own beliefs about the concept you are teaching. As a participant of the program, learning how to stay humble was a huge lesson, and asking for clarification was one of the greatest gains.

Some of the other gains:

We could work on tasks that caught our interest.
We developed experience working on a project in production
Learning from professionals
Following the other RGSoC teams around the world working on other open source projects.
More cost effective than attending a boot camp which we considered when we applied to RGSoC.

Some of the hurdles:

Volunteer based teaching means that our mentors prioritized their work and we could not always depend on getting help when we needed it.
Working with several organizations on the same project sometimes made it challenging to plan and get on the same page.

It does take time to mentor but if you look at it as an investment to bring more contributors to open source it is time well spent. We also encourage other developers to take the opportunity to learn and contribute to open source.

App 1.0

Tue, 12 Jan 2016 00:00:00 +0000

TLDR: CocoaPods now has a Mac App that provides a hosted Ruby experience, go check out the web page for it: cocoapods.org/app.

The rest of this post is about how all the pieces come together to make a CocoaPods app.

What's happening under the hood?

Let's take a look at the Xcode Project.

The app is three separate tools that work in combination to provide a seamless experience. You can see the targets; CocoaPods, pod and ReflectionService.

CocoaPods

This is the CocoaPods app, it provides an OS X GUI to common tasks for people who use CocoaPods. It also is the host to an entire environment required to use the CocoaPods' features it exposes. It turns out there are quite a lot of dependencies for CocoaPods once you try to replicate the common user's environment.

In order to make it work seamlessly we bundle: bzr, curl, git, mercurial, ncurses, openssl, pkg-config, ruby, scons, serf, subversion, yaml and zlib. These are compiled dependencies sitting inside the application bundle. In the Xcode Project above, they are contained in the bundle reference group.

It's quite the setup in there. It's very similar to how Xcode hosts all of it's SDKs, compilers and apps (Instruments.app, iOS Simulator.app for example.) These folders represent a hosted environment which is well-contained and well tested. We provide the latest stable builds of these dependencies inside the app.

The GUI aspect of the app is built mainly in Swift and Objective-C when necessary. It uses all the fancy modern goodies available in the latest Cocoa APIs: NSViewControllers, Storyboards and XPC.

It's cleanly built using simple composition, and has been the source for quite a few people's first open source contribution. We keep a well stocked issue cabinet with well marked out issues for people wanting to help out. I aim to always put up designs early for features, making it easy for people to contribute with a specification in mind.

pod

We don't plan on replicating every feature of the command-line gem in the CocoaPods app. That's just not good usage of our time. Instead we offer a way to access the command-line interface with the version of CocoaPods that is inside CocoaPods.app. We do this in the same way Xcode does, by offering command line tools:

The pod command is a C binstub which uses the Core Services API in order to work independent of the CocoaPods.app which installed it. The binstub finds the embedded ruby pod command generated by RubyGems and passes along the same arguments. This means once you've installed it, you can move your app freely, and we don't need to update the C binstub. Ace.

As it has the same name, you don't need to change any scripts or your development flow in the terminal once installed. I've been using it as my main pod command for the last few months.

ReflectionService

The CocoaPods app needs to talk to the pod command provided by ruby. The simplest option is via NSTask, which will execute a command in a shell and output text to STDIN and STERR. This makes it easy to run commands, but it can be hard to deal with interactivity. It's effectively a one way communication pattern.

There have been a few tools which bridge Ruby and Cocoa, the most notable being RubyMotion. There is however a bridge that used to come shipped with Mac OS. That is RubyCocoa. We built support for bi-directional communication between Objective-C and Ruby using RubyCocoa.

At one point we had a fork of RubyCocoa that supported objects created in Swift, but that was probably going to turn into a long road for something with not too much gain on our end.

We negated the need for this by moving to communicate with Ruby over XPC, we called this the ReflectionService. It's explained below.

XPC means that we can have a persistently running Ruby environment from which we can send/recieve metadata about Podfiles. This protects the app from crashes, keeps memory usage low and doesn't require booting up Ruby every time we want to communicate. Triple win. If you've not looked at XPC it gets a thumbs up from us.

What's in now?

The key features for 1.0 are being able to edit a Podfile, and to be able to run pod install and pod update on it.

One of the things I'm really happy about is our inline errors for your Podfile. The app gives direct feedback as you're editing the Podfile:

We have a lot of the normal developer key commands working as expected, if there's something you'd want that we don't support, write us an issue or PR.

What's next?

We've got some WIP Pull Requests for some cool features like automatic CocoaPods plugin installation, and an integration summary. These are very likely to be in for the final 1.0 release. However we've not tried to look too far into the future with this app.

I think there's a lot of space for improvements, and we'd love some community input on what you would like to see in a GUI for CocoaPods.

For example, I know when most people try attack this problem they try to solve the pod discovery problem, but I'm not sure if we can do better than the website in the native app. Would love some ideas on ways we could improve.

Release Versions Only

Tue, 29 Dec 2015 00:00:00 +0000

The main CocoaPods website, cocoapods.org, lets you search for all versions of a pod. That includes prerelease versions. As a result, when searching for a pod with a prerelease version, the latest prerelease version is shown in the result list.

This sounds good in principle, but the behaviour is at odds with how the pod command operates. The default there is to use the latest released pod version. As a result of this – as we noticed via our stats system – usage of prerelease versions is minimal, and showing the latest prerelease version on cocoapods.org violates expectations as to what pod install will actually install.

Therefore, we will be switching to the pod command default also on cocoapods.org, meaning in the results, we will show only released versions. We've prepared all systems for the switch and will flip it on December 31st 2015 to start into the new year with the brand new search engine behavior.

Happy New Year, pod friends!

2015

Wed, 18 Nov 2015 00:00:00 +0000

CocoaPods is a dependency manager only in the sense that Apple is a cell phone manufacturer – it’s just one of their many projects.

-- Ash Furrow - Building Online Communities

Last year, around this time, I started an annual write-up for CocoaPods. A lot happens in a project with 10 relatively active developers, and a lot of very welcome drive-by contributors.

Stats

Alright, so, let's start off with a bang! Here's the TLDR interesting numbers:

24 searches per minute.
45 pod installs per minute.
100,000 unique app targets.
100,000 uniques to the site.
500,000 monthly page views.
2.5 million gem downloads of CocoaPods.
6.6 million targets integrated by pod install / pod update.
30 million pods have been integrated by CocoaPods.

Contributions

We started the year with a change in ownership. Eloy Durán who had been heading up the project for five years, announced he was stepping back due to becoming a father.

Right now we have four people making a lot of the major decisions around CocoaPods: Boris Bügling, Marius Rackwitz, myself and Samuel Giddins. With the help from other developers on a day to day basis.

This year we've seen Samuel Giddins sponsored by Capital One in order to help him focus on building CocoaPods while he studies at college. I want to dig in a little about Samuel's work in the last year. In the last write-up, I mentioned a project he was working on:

The second, Samuel Giddins, has been mostly working on a iterative dependency resolver for both CocoaPods and Bundler ( CocoaPods for Ruby. )

This project turned into a gem of a library called Molinillo, see the announcement, which is the project at CocoaPods with the most impact. Molinillo is now used in both Bundler and RubyGems! This is awesome because it powers a huge amount of ruby infrastructure, but that soon enough CocoaPods' code will be shipping in every copy of OS X. So cool.

Community

This year a lot of major companies migrated to using CocoaPods as their transport method for their SDKs. We got featured in a few annual keynotes:

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

i love you @CocoaPods :) pic.twitter.com/cWynBnROGC
— Bruno da Luz (@brunov0id) July 29, 2015

Working w/#CocoaPods for the first time is an achievement that ranks just below my wedding day and birth of my first child. #iOS #MobileApps
— Brian Stein (@bleestein) July 17, 2015

When I take on an #iOS project that doesn't use @CocoaPods... the #horror. #DeveloperProblems #RefactoringTime #LateNight
— Derek Argueta (@derek_arg) February 8, 2015

Finally started using @CocoaPods and oh my gosh it is life changing
— Josh Puckett (@joshpuckett) January 14, 2015

playing with @CocoaPods .. its awesome.. #iosdev #development @appleios @ios
— sagar modak (@sagarmodakit) February 17, 2015

Finally FINALLY I can try out cocoapods. And it is wonderful.
— Michael Robinson (@codeofinterest) February 21, 2015

Down about dependency management in iOS? In our latest blog post, Mason G. explains how we use @CocoaPods to help: http://t.co/NDG8lbuSJv
— Yelp Engineering (@YelpEngineering) April 1, 2015

CocoaPods, taking open source libs quality to new ⬆︎ Level 👍 Great Job. https://t.co/PDlBE2hnZ4
— Kostiantyn Koval (@KostiaKoval) July 11, 2015

This is your daily reminder that 'pod try' is insanely convenient! Great job @CocoaPods !
— Gabriele Petronella (@gabro27) July 21, 2015

COCOAPODS! <3
— Marc Backes (@backesmarc) July 29, 2015

Introducing: Creme de la Pods

Sat, 07 Nov 2015 00:00:00 +0000

TL;DR: You could always find out what was new with @CocoaPodsFeed and feeds.cocoapods.org. Now you can see new CocoaPods that have a QI score of over 70 on @CremeDeLaPods.

Keeping on top of the community's work is a challenge, with ~13,500 CocoaPods available and roughly 20 new pods every day. We work on CocoaPods to encourage contributions to OSS. A by-product of this is that if you follow the whole stream of new CocoaPods, it can get hard to distinguish between "my first library" and "an awesome paradigm swift."

I have taken a stab at solving this problem, by trying to select the best pods by their Quality Index. The first time we run documentation parsing for a Pod, if that Pod's QI is over 70 then CocoaDocs will send out a tweet on the @CremeDeLaPods twitter feed, with the exact same formatting as @CocoaPodsFeed.

Follow @CremeDeLaPods

If you've already seen tweets from @CocoaPodsFeed before, there should be no surprises on the look of those tweets on CremeDeLaPods:

[Venice] CSP for Swift 2 (Linux ready) https://t.co/DdPyqojBjI
— Creme De La Pods (@CremeDeLaPods) November 7, 2015

[ControllerContainer by @3lvis] View Controller Containment for humans https://t.co/3WgHkIrUUa
— Creme De La Pods (@CremeDeLaPods) November 6, 2015

Every Pod also comes with an overview image too, making it easy to see some of the salient properties.

[Money by @danthorpe] Swift types for working with Money. https://t.co/jCdJlrZV9Z
— Creme De La Pods (@CremeDeLaPods) November 6, 2015

Follow @CremeDeLaPods

It's easy to forget that a lot of people are just getting started, and learning how to ship a Podspec is an important step towards community participation. We want people to feel welcome at all stages of their careers, so we'll always be showing and hosting the unfiltered feed.

We've talked about, in the future, supporting tweeting when any pod's version moves to getting to a score of 70+. This should be a bit more accommodating for improvements after seeing an initial score, rather than set up at the start.

Capital One

Tue, 27 Oct 2015 00:00:00 +0000

I'm incredibly excited to announce that as of today my work on CocoaPods will be sponsored by Capital One.

What does this mean? It means that Capital One is stepping up to support continued development on CocoaPods and I will be able to focus on CocoaPods work while finishing university.

This sponsorship demonstrates Capital One's commitment not only to CocoaPods, but to the wider open source ecosystem -- they're supporting the creation, maintenance, and improvement of tools used by hundreds of thousands of developers on a daily basis.

I'd be remiss if I didn't mention that Capital One is a great place to work (I'm friends with several of their engineers, and they're some of the smartest and most experienced iOS developers I know), and they're hiring engineers in Northern Virginia and SF. If you believe in supporting open source and building apps that change how people interact with their money, you should drop them a line by sending @louielouie a Direct Message on Twitter.

I'm extraordinarily happy to be able to redouble my efforts on CocoaPods and that I can do so in lieu of taking up other work is entirely thanks to Capital One.

Now, back to our regularly scheduled CocoaPods 1.0 development -- and thanks again to the generous folks at Capital One for making it possible for me to do so!

CocoaPods 0.39 - tvOS and Dynamic Vendored Frameworks

Fri, 09 Oct 2015 00:00:00 +0000

TL;DR: CocoaPods 0.39 has been released, with support for tvOS pods and dynamic vendored frameworks.

Dynamic Vendored Frameworks

CocoaPods 0.39 has been released, with the biggest change being support for dynamic vendored frameworks. This will allow closed-source pods to be provided as dynamic frameworks, meaning no more errors when they are transitive dependencies of multiple other pods. This will also allow closed-source pods to not only be used simultaneously with Swift pods, but it means closed-source pods can even be written in Swift.

tvOS

The update allows you to use pods with tvOS. As a pod author, you may need to specify the deployment target for tvOS in your podspec, as seen below:

Pod::Spec.new do |s|
  # …
  s.tvos.deployment_target = '9.0'
end

This means that, in practice, not all existing pods will be compatible with tvOS immediately. Any pod that can support tvOS needs to explicitly add support by adding s.tvos.deployment_target, since it is an entirely new platform.

Swift Standard Library Copying

When building Swift pods with Xcode 7 or later, the Swift standard library runtime will no longer manually be copied. For projects with a large number of Swift pods, this can lead to a drastic speed-up in build times.

Private Linting

All commands that perform linting (pod spec lint, pod lib lint, and pod repo push) now can take a --private flag. Using this flag will disable warnings that are only relevant to public pods, such as URL reachability.

Along with these enhancements, 0.39 features dozens of bug fixes.

Updating

To install the last release of CocoaPods you can run:

$ [sudo] gem install cocoapods

Until version 1.0 we strongly encourage you to keep CocoaPods up-to-date.

For all the details, don’t miss the Changelog!

Running SSH Commands via Rakefiles

Wed, 26 Aug 2015 00:00:00 +0000

TL;DR: CocoaDocs' commands which used to be executed via logging in are now done via rake commands.

CocoaDocs runs a lot of CocoaPods' infrastructure. It is the workhorse that allows us to provide rendered READMEs/CHANGELOGs, QIs and status updates.

I have been manually sshing in to the server to execute commands for a few years, and it's a bit of a chore. Over time though, I became used to this. As more people were starting to help out in maintaining CocoaDocs, it became obvious that it needed to change from being dark arcane knowledge to easy -discoverable- commands.

Show me the code: c7be695...a00338d.

I initially explored the idea of using Mina to let us treat CocoaDocs like we do with heroku. I spent a few hours setting it up, but never managed to get a single working prototype. Eventually I started looking for alternatives.

I found net-ssh, which is a pleasant reminder of how old the ruby community is, given that docs are from 2004. I used it to connect to the server in a tiny amount of code:

require 'net/ssh'

Net::SSH.start('api.cocoadocs.org', 'cocoadocs', :password => "hahayeahright") do |ssh|
  output = ssh.exec!("hostname")
  puts output
end

Which was enough to start. Once I started though, I hit a problem. Each command is executed stateless-ly. What this means, in principal, is that your session won't stay in the same folder, and you won't have your normal shell setup. I started out trying to do all the things a shell would do source ~/.zshrc etc. etc. Not practical.

After giving up on the exec function, I did some duckduckgo-ing for alternatives and found a chapter on shell in the docs. However, the docs were out of date, and the code didn't exist. Luckily it had just been separated out into a new gem: net-ssh-shell. This meant we could do:

require 'net/ssh'
require 'net/ssh/shell'

Net::SSH.start('api.cocoadocs.org', 'cocoadocs', :password => "hahayeahright") do |ssh|
  ssh.shell do |sh|
    sh.execute 'hostname'
  end
end

Which executes the command, as expected, as though you had logged in. Perfect. With that, I did some minor refactoring to turn it all into a function that takes some commands as an array.

 def run_ssh_commands commands
   puts "Connecting to api.cocoadocs.org:"
   Net::SSH.start('api.cocoadocs.org', 'cocoadocs') do |ssh|
     ssh.shell do |sh|
       sh.execute 'cd cocoadocs.org'
       commands.each do |command|
         puts command.yellow
         sh.execute command
       end
       sh.execute 'exit'
     end
   end
  end

I included an exit command to close the session at the end of the submitted commands, and that's it. Commands are now easily run from a maintainer's computer without the need for domain knowledge. They just need to know that bundle exec rake -T will give useful tasks. Given that we use Rakefile in all projects, this knowledge is implicit. Woo!

So, next time you hear people complaining about a chore you've become used to, take heed and try to automate the problem away.

CocoaPods Stats Resetting

Sun, 09 Aug 2015 00:00:00 +0000

TL;DR: CocoaPods Stats is ready to move from it's current staging environment, and we will be resetting all stats next weekend.

When I set up CocoaPods Stats - the website API and Analytics database with help from Segment, I created it within a staging environment in our analytics database. Since getting it up and running, I gave it two months to gather enough data in order for us to be sure that the, at-the-time, evolving table data structure works.

Looks like it is working. In that time, people using only the latest releases of CocoaPods, have used CocoaPods to download AFNetworking almost 100,000+ times, on 6500+ individual projects.

So, next week I will migrate the stats server to production and everything will be back to zero downloads / installs again.

CocoaPods 0.38 - watchOS and target de-duplication

Tue, 21 Jul 2015 00:00:00 +0000

TL;DR: CocoaPods 0.38 has been released, with watchOS 2 support, target de-duplication, and Stats for everyone.

CocoaPods 0.38 has been released. This is our first update since WWDC and it brings support for Apple's latest releases, including Xcode 7 and watchOS. It also includes lots of improvements that make building Pods easier. Furthermore, it rolls out Stats for everyone.

watchOS

The update allows you to use Pods with watchOS. As a Pod Author, you have to specify the deployment target for watchOS in the Podspec, as seen below:

Pod::Spec.new do |s|
  # …
  s.watchos.deployment_target = '2.0'
end

What this means in practice, is that not all Pods are automatically available by default. Any Pod that can support watchOS needs to explicitly add support by adding s.watchos.deployment_target. It is an entirely new platform.

Target Deduplication

CocoaPods now de-duplicates Pod targets, which means that it recognises when a dependency is used multiple times across different user targets but only needs to be built once. But sometimes this is not possible and they still need to be generated in different variants and thus build multiple times. The targets in Pods.xcodeproj need to be duplicated when one of the following conditions applies:

They are used on different platforms.
They are used with differents sets of subspecs.
They have any dependency which needs to be duplicated.

This fixes several issues with Archiving apps with extensions, but also reduces build times significantly.

Removal of the Enviroment Header

After updating and running pod install on your integration, you will see that some header files in the Pods directory won't be generated anymore matching the pattern Pods-*-environment.h. This was the environment header, which contained precompiler macro definitions with the version components of each dependency used in the integrated target. It was visible not only for the user target, but also for all its dependencies. It could be used to make additional features available if a given pod is present. But this was also the cause of some issues. One of them was that it wouldn't be possible to de-duplicate frameworks. If you relied on that, you can still use the Clang file checking macro __has_include to determine (by the presence of a header) whether a specific dependency is available or not:

#if __has_include(<QueryKit/QueryKit.h>)
  #import <QueryKit/QueryKit.h>
#endif

To make optional behavior in your Pod available, you should use subspecs, exclude the subspec from the default_subspecs and declare there an explicit dependency, which is versioned and will affect the dependency resolution only when the user explicitly includes the subspec.

Breaking Change to the Hooks-API

The Podfile allows you to define pre_install and post_install hooks. Before this update, we maintained a proxy layer, so that we could alter the installation / integration process and the model and just change how the Hooks API representations access those artifacts. This worked for a while, but finally we became aware that we reached a point where both came completely out-of-sync. Because of that, we relinquished that approach and made the underlying installer directly available, which was exposed before anyway and allowed more advanced possibilities for this more advanced feature.

If you relied on that feature, this table may help you with the mapping and give you some help how to migrate:

InstallerRepresentation	Installer
`sandbox_root`	`sandbox.root`
`project`	`pods_project`
`pods`	~> `pod_targets`
`libraries`	~> `aggregate_targets`
`specs_by_lib`	use `#find` or `#select` on `pod_targets`
`pods_by_lib`	use `#find` or `#select` on `aggregate_targets`
`sandbox`	`sandbox`
`config`	`config`
`installer`	not needed

If you need to keep compatibility to the older versions of CocoaPods, then you can simply check the gem version in the Podfile as it is just Ruby code after all.

post_install do |installer_or_rep|
  # @note: Remove after CocoaPods 0.38+ is completely rolled out
  # and rename block argument to `installer`.
  installer = installer_or_rep.respond_to?(:installer) ? installer_or_rep.installer : installer_or_rep

  # You can use the installer from now on.
end

Split of `xcconfig`

One of the more advanced attribute in Podspecs is - or better was - the attribute xcconfig.

This allow you to specify build settings for your Pod. Previously those were made available to libraries and the integrated target.

We broke this with the support for frameworks. This wasn't an issue for most Pods because the build setting is mostly used to configure build settings which are relevant only to the generated Pod target itself. When we mentioned that there were still some Pods which weren't working anymore as expected due to that change, we decided to split the attribute from now on. This way Pods also can't accidentally overwrite or conflict with build settings of the user target.

The former attribute xcconfig is deprecated and will cause a linter error when pushing new versions to trunk. The new attributes are available as pod_target_xcconfig and user_target_xcconfig, which makes their effects more clear. The latter attribute (user_target_xcconfig) should be used with great care, because well designed Pods should be self-contained and make as few assumptions about their environment as possible. Furthermore, this attribute can cause conflicts when different values are specified by two Pods for a build setting which doesn't allow multiple values and so cannot be merged.

Deterministic UUIDs by Xcodeproj

This update also includes the latest version of Xcodeproj, which encapsulates the API to Xcode projects. Beside support for new build settings, it now supports the generation of deterministic UUIDs for every object in the project file. That means in practice mostly, that you have smaller diffs for the Pods.xcodeproj after running pod install or pod update, which reduce unnecessary merge conflicts. This behavior can be disabled via the new COCOAPODS_DISABLE_DETERMINISTIC_UUIDS environment variable.

Resolver takes the Deployment Target into account

The deployment target of a podspec is now taken into account in the dependency resolution process. This will ensure that CocoaPods will always be able to resolve your Podfile, even if newer versions of pods are released that have higher minimum deployment targets. It makes the behavior of CocoaPods overall less surprising.

Thanks to Contributors of Bug Fixes

Along with these enhancements, 0.38 features dozens of bug fixes. Special thanks to all the new contributors we had for this release, especially for their help in squashing bugs.

Updating

To install the last release of CocoaPods you can run:

$ [sudo] gem install cocoapods

Until version 1.0 we strongly encourage you to keep CocoaPods up-to-date.

For all the details, don’t miss the Changelog!

CocoaPods Stats

Wed, 24 Jun 2015 00:00:00 +0000

People have been asking for years about feedback on how many downloads their libraries have. We've been thinking about the problem for a about as long too, and finally ended up asking Segment if they would provide a backend for the project.

But wait, there's more...

It wasn't just enough to offer just download counts. We spend a lot of time working around Xcode's project file intricacies, however in this context, it provides us with foundations for a really nice feature. CocoaPods Stats will be able to keep track of the unique number of installs within Apps / Watch Apps / Extensions / Unit Tests.

This means is that developers using continuous integration only register as 1 install, even if the server runs pod install each time, separating total installations vs actual downloads.

Alright, hold up

Let's go over how we check which pods get sent up for analytics, and how we do the unique installs. CocoaPods-Stats is a plugin that is now bundled with CocoaPods from version 0.38 onwards. It registers as a post-install plugin and is ran on every pod install or pod update.

Detecting Public Pods

We're very pessimistic about sending a Pod up to our stats server. We ensure that you have a CocoaPods/Specs repo set up as your master repo, then ensure that each pod to be sent is inside that repo before accepting it as a public domain pod.

Data being sent

First up, we don't want to know anything about your app. So in order to know unique targets we use your project's target UUID as an identifier. These are a hash of your MAC address, Xcode's process id and the time of target creation (but we only know the UUID/hash, so your MAC address is unknown to us). These UUIDs never change in a project's lifetime (contrary to, for example, the bundle identifier). We double hash it just to be super safe.

  # Grab the project and the type of target
  uuid = target.user_target_uuids.first
  project_target = project.objects_by_uuid[uuid]

  # Send in a digested'd UUID anyway, a second layer
  # of misdirection can't hurt
  {
    :uuid => Digest::SHA256.hexdigest(uuid),
    :type => project_target.product_type,
    :pods => pods
  }

We then also send along the CocoaPods version that was used to generate this installation. Ideally before release we'll also be able to give statistics on how many people are using pod try [pod] for your library too.

How does it work?

My first attempt at a stats architecture was based on how npm does stats, roughly speaking they send all logs to S3 where they are map-reduced on a daily basis into individual package metrics. This is an elegant solution for a company with people working full time on up-time and stability. As someone who wants to be building iOS apps, and not maintaining more infrastructure in my spare time, I wanted to avoid this.

We use Segment in Artsy, and our analytics team had really good things to say about their Redshift infrastructure. So I reached out about having them hosting the stats infrastructure for CocoaPods. They offered a lot of great advice around the data-modelling, we were up and running really quickly. So you already know about the CocoaPods plugin, but from there it sends your anonymous Pod stats up to stats.cocoapods.org. This acts as a conduit sending analytics events to Segment. A daily task is triggered on the web site, this makes SQL requests against the Redshift instance which is then imported into metrics.cocoapods.org.

FAQ

Can I opt out as a CocoaPods user?

Sure. You can set an environment variable COCOAPODS_DISABLE_STATS to true in your shell, and stats will not be sent from your machine.

Does this affect every pod?

Yeah, every pod will get download stats.

Will it be live stats?

No, they get generated once per day.

What is the rollout strategy?

We plan on making this initially a separate CocoaPods plugin that you can optionally install via [sudo] gem install cocoapods-stats which will send the data. In a release or two we will bundle this into CocoaPods, and it will be installed by default for everyone moving forwards.

Can I use it right now?

Sure, update to the latest CocoaPods [sudo] gem install cocoapods or download the latest CocoaPods.app.

How does this affect the quality indexes / sorting?

Ideally we can reduce the amount of impact GitHub stars affects a quality index, and replace some of the values with new metrics based on downloads/installations.

What commands does this run on?

It runs at the end of a pod install or a pod update.

I check in my Pods directory, how does this affect stats for the pods I use?

Checking in your Pods directory will mean that the download count for the pods used will rarely be affected, but the installations will be the exact same. They only register once per project, so multiple developers on the same project running pod install will not raise this number.

CocoaPods.org v2.5

Tue, 09 Jun 2015 00:00:00 +0000

After our awesome State of the Union, I pushed the new version of the CocoaPods website to Heroku. It comes with a bunch of new features, some new pages and a few interface tweaks, let's go through what's new.

Quality Index

We built a series of quality approximations that sit on top of the deep metrics that exist within CocoaPods. These are a series of rules that we apply against a pod every time a new pod version is pushed. They range from GitHub popularity, to download size and a rough version of how well tested it is.

There are currently 17 metrics (see the code) that we use to estimate the quality of every library. The algorithm starts with a number then adds and subtracts to it based on the metric. They are both positive and negative metrics, for example releasing a Pod under the GPL license will detract some points while having a lot of GitHub stars will add to the number. In order to make this process transparent Hugo Tunis and Esteban Torres created a new web page showing all of the rules that apply to your pod.

Pod Ordering

We've transitioned the default pod search ordering from GitHub stars to the overall Quality Index. In part this is because the CocoaPods ecosystem is bigger than just GitHub, and while popularity is pretty well correlated with GitHub stars it often can just be an indicator that people liked the idea. Using the Quality Index we can take that into account, but also that it is well documented, has tests and many other aspects.

Pod Page improvements

We streamlined the main section of the Pod page. We did this by moving a lot of the interesting metrics that we have to the sidebar, and to re-think the hierarchy of the data on the side. We're actively cleaning up READMEs when displaying in Pod pages for things like CI/Coverage badges and CocoaPods installation notes to keep it focused on just the pods documentation. Installation details are available in the sidebar.

Owner pages

Terminology is important here, an owner is someone who has access to push a Pod to trunk. The library author is someone who created the library. Nearly all of the time they are the same, but there are examples ( ARAnalytics ) where they differ. We have created owner pages for the people with access to push a pod, right now we don't have pretty URLs for your owners but you can jump to any Pods you own and you'll see a link to your page. We show all the Pods an owner has access to, and a little bit of information around the pod.

I'm super happy with the changes to the website, I think it makes it easier than ever to discover higher quality libraries that might not have hit the big-time yet. Everyone can let out a sigh of relief now, we can figure out the best Swift JSON ORM.

2015 CocoaPods State of the Union

Mon, 01 Jun 2015 00:00:00 +0000

It's become an annual tradition for CocoaPods to host an event at WWDC, and we want to make this another great one. Last year we ended up with a waiting list almost double the amount we could get in, so we're pulling a leaf out of Apple's book by holding a lottery.

We've got it set up to favour those who have contributed to the core CocoaPods repos, but registration is open to everyone with a GitHub account. Twilio have graciously offered to host us again this year, June Eighth (Monday) at 6:30 PM, and we can't wait to see you all!

All of the details, as well as the lottery registration link, are available at https://sotu.cocoapods.org/. We'll be closing the lottery and announcing the lucky entrants on Thursday, so hurry up and register!

CocoaPods 0.37 - Pod Caching and Custom Module Maps

Sun, 03 May 2015 00:00:00 +0000

TL;DR: CocoaPods 0.37 has been released, with a new pod download cache and support for custom module maps.

CocoaPods 0.37 has been released, it includes download caching for Pods. This brings a huge speed improvement to commands such as pod spec lint and improves the performance of running pod install when a Pod is in the download cache (which is stored at ~/Library/Caches/CocoaPods/Pods by default).

The update also allows you to define a custom module map file in a Podspec.

Along with these enhancements, 0.37 features dozens of bug fixes.

Updating

To install the last release of CocoaPods you can run:

$ [sudo] gem install cocoapods

Until version 1.0 we strongly encourage you to keep CocoaPods up-to-date.

For all the details, don’t miss the Changelog!

Test Jam 2015

Sun, 19 Apr 2015 00:00:00 +0000

Over the weekend over 150 people met up in meetups, and many joined online, to try and improve the foundational libraries that the Cocoa community rely on. We made more than 30 pull requests and a lot of people got more exposure to testing in Xcode. Read on for stats.

The jam ran over a 14 hour timespan from 12pm GMT to 6pm PST. We had an active IRC with random banter and people asking useful questions. Twitter too.

The @CocoaPods testjam is alive and well at @Substantial in Seattle! Come join us and give back to the iOS OSS community!
— Kai Curtis (@thepelkus) April 18, 2015

Added unit tests and CI to FrameAccessor during the @CocoaPods test jam! Feeling pretty zen, despite the Obj-C. https://t.co/iLzyccp8pP
— Ayaka Nonaka (@ayanonagon) April 19, 2015

Writing tests with cats for the @CocoaPods Test Jam 😻 pic.twitter.com/DVxJyEIXZT
— Michele Titolo (@micheletitolo) April 18, 2015

One of the greatest things about @CocoaPods test jam is seeing different peoples approaches to testing legacy code.
— squarefrog (@squarefrog) April 18, 2015

For the @CocoaPods Test Jam I added code coverage to Form! https://t.co/HJbqDp5uQD
— Elvis Nuñez (@3lvis) April 18, 2015

Learned quite a bit about testing and werewolves @CocoaPods #testjam
— Eytan Biala (@eytanbiala) April 19, 2015

“Why test? It’s not about increasing test coverage. It’s about empowering the ability to change the code.” —@qcoding @CocoaPods test jam
— Ayaka Nonaka (@ayanonagon) April 18, 2015

For the @CocoaPods Test Jam @ams340 and I added test coverage to facebook/KVOController--now adding missing tests! https://t.co/ft5aDbTZ79
— Brian Gesiak（もどかしい） (@modocache) April 18, 2015

We’ve wrapped up our first test jam pod: https://t.co/tBNlwUgP6z
— Ørta (@orta) April 18, 2015

Having fun @CocoaPods #testjam! Adding tests to MGBoxKit https://t.co/rOBgjxBl1h
— Benjamin Encz (@benjaminencz) April 18, 2015

Testing cocoa is exhausting. #testjam @ Artsy https://t.co/rPu9hrzi8J
— Rob Ruffler (@RobRuffler) April 18, 2015

@robbiehanson_15 Gotcha, yeah, you maintain some seriously popular stuff! I set up some unit test for Cocoapods test jam, nothing critical.
— Stepan Hruda (@StepanHruda) April 18, 2015

Thanks to @Daniel1of1 and @iwasleeg for helping organize the cocoapods test jamming meetup yesterday.Fingers crossed https://t.co/XYDqpysNVh
— seanoshea (@seanoshea) April 19, 2015

Talks

Every meetup had the freedom to run it however they like, ranging from two people in a room to speakers known for their testing prowess. Interestingly enough, both talked about adding tests to untested code. Hint: you might be interested in their source material: Working Effectively with Legacy Code

We changed the plan on the day to avoid needing a bot. In this case jammers would assign themselves a pod from a big Spreadsheet and this gave people a chance to find libraries that interested them. Here's a collection of the work done, with more probably happening over a longer time frame. Very cool.

facebook/KVOController#58, facebook/KVOController#59, facebook/KVOController#60, facebook/KVOController#61, andreamazz/AMTagListView#31, chrismiles/CMPopTipView#97, stepanhruda/CocoaAsyncSocket#1, robbiehanson/CocoaHTTPServer#136, AlexDenisov/FrameAccessor#16, kevon-hirsch/KVNProgress#37, mutualmobile/MMDrawerController#369, tombenner/nui#293, pkluz/PKRevealController#224, ruslanskorb/RSKImageCropper#50, hons82/THSegmentedPager#8, slackhq/SlackTextViewController#168, slackhq/SlackTextViewController#167, hons82/THSegmentedPager#8, andreamaz/UIView-draggable#8, marcuswestin/WebViewJavascriptBridge#128, robbiehanson/XMPPFramework#523, intuit/LocationManager#37, facebook/componentkit#133, Flipboard/FLAnimatedImage#74, CocoaLumberjack/CocoaLumberjack#498, CocoaLumberjack/CocoaLumberjack#499, CocoaLumberjack/CocoaLumberjack#500, TransitApp/SVProgressHUD#422, Eldorado234/PAYFormBuilder#23, danielebogo/DBPrivacyHelper#18, cezarywojcik/CWPopup#27, gpambrozi/BlockAlertsAnd-ActionSheets#76, AFNetworking/AFAmazonS3Manager#88, cwRichardKim/RKNotificationHub#10, taiheng/BEMSimpleLineGraph#testjam

As the organiser, I can't be happy enough with how it went. The NYC event helped a lot of people actually start testing. It helped me start to use code coverage as a metric for libraries. It's super easy to add. Hopefully events like this move the baseline of expectations forward a little bit. 👍

If you're interested in doing community work with CocoaPods we're always interested in working with more people on ideas like this. You can get in touch with us via info@cocoapods.org ( this goes to Kyle, Samuel, Eloy and myself.)

Preparations for the Test Jam

Mon, 13 Apr 2015 00:00:00 +0000

The Testjam is this weekend (April 18-19). Let's give as much details as possible:

Meetups

Location	Meetup Page	Hosts
New York City	CocoaPods NYC	Orta Therox, Ash Furrow at Artsy HQ
San Francisco	CocoaPods SF	Samuel Giddins, Kyle Fuller at Realm HQ
Minsk, Belarus	CocoaHeadsBy	Aliaksandr Andrashuk, Yana Poteeva at 9elements
London	NSLondon	Daniel Haight, Raimon Lapuente at Facebook
Durham, NC	NSCoder	Josh Johnson at American Underground
Seattle, WA	Working together	Kai Curtis at Substantial

Don't worry if you don't live in a big city, we'll all be online, follow through to find out the details.

To recap:

TLDR/Elevator Pitch: If the community is going to move towards Swift, then let’s make sure that our Objective-C is in order by adding tests to established libraries.

We have picked out 200 pods without tests, or with very low test coverage, ordered by popularity. These are assigned randomly to interested contributors. They then will aim to:

Add tests to the library.
Add Continuous Integration.
Add Code Coverage support.
Submit a Pull Request to the original repo.

We have already contacted all of the library authors letting them know that this is happening and that it would be cool for them participate. Some authors have written issues stating how they would like to have tests set up.

How it works

We will be focused on trying to improve existing tooling, but this does not mean that we will not be supportive for anyone taking the time to add tests to their own libraries. This is a great time to devote a day or two to improving your own libraries surrounded by people who are in a similar mindset. It will be the perfect time to ask questions in a community. We will be running the chat room based on the Social Rules of the Recurse Center. We're aiming to have a fun space for people to get started with testing.

We will be using IRC to chat, and to interact with our bot. We will be keeping stats inside a web page on CocoaPods.org.

If you are new to IRC, you can connect either via Limechat (Mac App Store), a web-IRC adaptor or any client of your choice. We will be using the channel #cocoapods freenode.net and the CocoaPods Test Jam page will have information on how to get started.

Useful links

Here's a collection of useful links around the Jam and Testing in general:

Automating Everything

Mon, 06 Apr 2015 00:00:00 +0000

A few nights ago, I put out a release of CocoaPods that was unable to actually download new pods. Hoping to learn from that mistake, I turned to automation to ensure the team would never make the same mistake again.

In CocoaPods, we automate a lot of things. Every gem repository has a Gemfile and Gemfile.lock (the Bundler equivalent of a Podfile and Podfile.lock) to ensure that all developers are using the exact same versions of RubyGems dependencies. Every repo has RuboCop enabled, to ensure we keep coding style consistent. Every repo is set up to run on Travis CI and report test results back to GitHub, as well as sending code coverage and quality information over to Code Climate. Every repo has a Rakefile (a super-powered Makefile for Ruby) to define common development tasks, such as running tests, generating data, and running RuboCop. That's a lot of automation, right? Yes, but there's more.

To develop CocoaPods, not only do we have many repositories for different sites and different gems, but we also have a pair of meta-repositories, Rainforest and Strata. They manage the gem and web repos, respectively, and provide a litany of commonly used functionality, such as updating RuboCop configurations, seeding databases, and bootstrapping all of the repos they manage.

Now, back to the story of the botched release (CocoaPods 0.36.2 if you were curious). Rainforest has a lovely release task that goes far beyond the Bundler default release task by validating the version change, that bundle install has been run, and that the CHANGELOG has the correct headers. It also ensures that there are no missing remote commits, and that all the specs pass. It's that last bit that went awry for me -- the CocoaPods Gemfile points to various commits of the master branches of its internal dependencies, even for that final specs run before a release. This is usally no problem, since we release depended-upon gems first, ending with the cocoapods gem. This time, however, I had forgotten to do a release of cocoapods-downloader, which is responsible for actually downloading Pods.

In between CocoaPods 0.36.1 and 0.36.2, I had refactored an internal API to take an array instead of a string, and it just so happening this was an API that interacted with the downloader. Because the CocoaPods Gemfile pointed to a more recent commit of cocoapods-downloader, a normal run-through of the specs didn't reveal the incompatibility. So I released 0.36.2, and it 'broke' CocoaPods for a few hundred users before 0.36.3 was pushed. All in all, it wasn't too big of a crisis, but it left me with a burning desire to make sure that nothing similar happens again. I was determined to bolster the release task to guard against a repition of this sort of mistake.

So I hacked something together the next day to ensure that the final run of the specs before release runs only against already-released gems. On the CocoaPods team, I definitely fall on the hackier side of the scale, but we all share a belief that any sort of process needs to be automated (and thus enforced by machine) to be accepted. Without automation, our distributed team that works random nights and weekends would begin to look more like a rag-tag group of wild coders than a team capable of building dependable software. There are a bunch of sayings that try and touch upon the cost-benefit analysis of automatic even simple tasks, but I don't believe that any of them apply when you're talking about a product that is used by multitudes of people: sure, I might spend five hours on a task, but if it can save each user thirty seconds, it's a net gain.

Additionally, automation has the benefit of being operator-agnostic. As an open source project, there's a steady churn of contributors. We want to look towards the future and make sure that we're not leaving compartmentalized knowledge in any one member of the team, so that any future member can seamlessly step into any role. Basically, when I say 'automate everything', I really mean it -- when I've automated something, I can put it out of my mind, confident that it will work. (Sounds familiar to those of you who write unit tests?)

CocoaDocs Co-located

Mon, 23 Mar 2015 00:00:00 +0000

TL;DR: CocoaDocs.org just got Jazzy support, became more stable, and is now sending stats to our status page.

History.

CocoaDocs is a server that generates CocoaPods documentation. It started out by generating Apple-compliant DocSets via appledoc on a hosted Mac and then sends the results to Amazon's S3 where they are served statically.

Maturation Process

Appledoc is great, but it's not going to be supporting Swift anytime soon. CocoaPods has been supporting Swift Pods since New Year 2014, and we wanted to be able to provide hosted documentation for these pods too. Sam Giddins took the initiative here and added early support for Swift Pods via Realm's Jazzy. You can see a few Pods here: Observable, Moya, JSONJoy and QRReader.swift. There's no fancy design work yet, we will get to that in time.

Given Swift's immaturity, this is going to be an interesting problem, as the CocoaDocs server has no way of determining which version of Swift your library supports. For now this is solved by only supporting stable Xcode releases. In the future, it may make sense to add a range of supported Swift releases to your podspec per-release.

Towards the end of the 2014, the CocoaDocs server was starting to have some real issues, the generator would be down for days, and trying to ssh in would fail. It was turning out that the shared VPS we were using was falling over after a certain amount of time, likely due to running out of RAM. In order to get the server back up and running I had to submit a support ticket and get someone else to reboot it.

Around this time, Button reached out to me to ask if this was a problem they could help solve. Given that until this time I had been paying for CocoaDocs myself, I had done everything I could to optimise it for my wallet. ( CocoaDocs was costing me about $450 a year. ) So we jumped at the chance to do it right. CocoaDocs is now running on macminicolo.net, and it's a dream to ssh or Screen Share.app in. Thanks a lot Button!

In the process of moving I added one more feature. We now send data to the CocoaPods status page saying how many pods have been documented in the last 24hrs. Hopefully this should result in some useful insight into "is it working?" and give a sense of how much work it is doing.

CocoaPods.org Take Two

Mon, 16 Mar 2015 00:00:00 +0000

TL;DR: CocoaPods.org version 2.1 has been released, with support for inline deep search results, and pod pages.

Backstory.

The CocoaPods web site is an interesting beast. In October 2013, we started rewriting the CocoaPods web pages. We centralized the documentation, created a blog and redesigned everything.

We settled on using a mix of middleman pages and jekyll. Given that, at the time, there was no central database for CocoaPods, it made sense to try to keep it as a static site for speed and maintainability. Once CocoaDocs v2 launched in May 2014, I set my sights on trying to move cocoapods.org a little bit closer to my larger vision of what the website would provide.

In an ideal world, you should be able to find a library that fits your constraints using just the front page of CocoaPods.org. Often there is more than one library, and that’s where things gets a bit more complex. In previous versions of the site, in order to choose between multiple libraries, you needed to open them up on GitHub in separate tabs and compare. Now, you don’t need to. 🎉

Here’s how it works

Let’s take a random pod. MiniFuture. This is what happens after a Pod is released:

A new Podspec version is added to Trunk
A webhook from trunk triggers a reindex of the pod in the search engine which uses the generated metadata to sort and display pod results.
Another webhook gets sent to CocoaDocs triggering a documentation build
The documentation build uses Jazzy ( or appledoc for Objective-C projects ) to generate documentation.
Then CocoaDocs starts generating metadata. This provides us with a rich dataset to start providing some useful statistics. This is centralized in metrics.cocoapods.org, where we currently hold up-to-date GitHub metrics also.

// http://metrics.cocoapods.org/api/v1/pods/MiniFuture

{
    "cocoadocs": {
        "created_at": "2015-03-08 16:48:25 UTC",
        "doc_percent": 22,
        "dominant_language": "Swift",
        "download_size": 416,
        "initial_commit_date": "2015-03-01 12:03:09 UTC",
        "license_canonical_url": "http://opensource.org/licenses/MIT",
        "license_short_name": "MIT",
        "notability": 0,
        "quality_estimate": 50,
        "readme_complexity": 72,
        "rendered_readme_url": "http://cocoadocs.org/docsets/MiniFuture/0.1.0/README.html",
        "total_comments": 8,
        "total_files": 4,
        "total_lines_of_code": 327,
        "total_test_expectations": 204,
        "updated_at": "2015-03-08 16:48:25 UTC"
    },
    "github": {
        "contributors": 1,
        "created_at": "2015-03-01 10:09:08 UTC",
        "forks": 0,
        "language": "Swift",
        "open_issues": 0,
        "open_pull_requests": 0,
        "stargazers": 8,
        "subscribers": 2,
        "updated_at": "2015-03-05 01:01:44 UTC"
    }
}

A preview image is generated for the library for Social Media, chat, or really anything that supports open graph previews. Here is how we figure the wording.

We then generate an estimated quality number for the library. This is based on a collection of individual metrics that are applied to the generated metrics data. They take a library and add or remove points based whether the rule applies for that library. These range from the popularity of the library, total test expectations / lines of code to the files, and average lines of code per file in the library.

// https://cocoadocs-api-cocoapods-org.herokuapp.com/pods/MiniFuture/stats

[
    {
        "applies_for_pod": false,
        "description": "Testing a library shows that the developers care about long term quality on a project as internalized logic is made explicit via testing.",
        "modifier": -20,
        "title": "Test Expectations / Line of Code"
    },
    {
        "applies_for_pod": false,
        "description": "Too big of a library can impact startup time, and add redundant assets.",
        "modifier": -10,
        "title": "Download size"
    },
    {
        "applies_for_pod": false,
        "description": "Smaller, more composeable classes tend to be easier to understand.",
        "modifier": -8,
        "title": "Lines of Code / File"
    },
    [...]
    {
        "applies_for_pod": true,
        "description": "A popular library means there can be a community to help improve and maintain a project.",
        "modifier": 5,
        "title": "Is popular"
    }
]

This gives enough metadata to start creating a page that represents the library with the kind of context that is specific to our community. In a lot of ways it can be better than the front page of the GitHub repo.

How it comes together

We use the quality metrics in search to order the results. There are quite a few different sorting options now, so we may look into offering choices there.

We've started exposing a good chunk of the information in a pod's profile pages, and via inline results but not all of it. There's interesting issues around how we can expose more.

Going forward

The APIs we use are all available for anyone to build things on top of. This data is pretty solid, the API routes won't be changing and work is on-going to make it more accurate. We'll only be expanding from here.

It's not perfect, but a website isn't an iOS app and we can deploy daily. We re-wrote the homepage to run directly from the new databases and it's simplified the development process a lot. So it's easy for anyone to contribute and help out. We'll be iterating on it for a while before stablizing, so we'd love feedback in an issue or on twitter.

It took a bunch of people too

Whilst I have been championing this feature for the last 8 months, I've had a lot of help:

Florian Hanke, Samuel Giddins, Hugo Tunis on metrics, search and a CocoaDocs API.
Kyle Fuller on countless CocoaDocs improvements and maintainace
David Grandinetti, Mike Lazer-Walker, Phil Tang, Brian Gesiak and Danny Hertz on Quality/Popularity Metrics

CocoaPods 0.36 - Framework and Swift Support

Wed, 11 Mar 2015 00:00:00 +0000

TL;DR: CocoaPods 0.36 has been released, with the long-awaited support for Frameworks and Swift.

CocoaPods 0.36 adds support for dynamic frameworks, and with that it also brings enhanced support for dependencies using Apple's new programming language, Swift. This has been one of the largest singular changes in CocoaPods, affecting almost all of CocoaPods' subsystems such as Xcodeproj.

And there were Swift & Dynamic Frameworks on iOS

Dynamic frameworks have always been available on OS X. That's different for iOS. Apple's mobile platform introduced third-party dynamic framework support in iOS 8. So the least common denominator was found before with using static libraries, which have always been supported on both platforms.

At the same time Dynamic Frameworks were introduced on iOS, Apple also introduced Swift. If you have third-party dependencies in Swift, you have only two choices: Either throw them in your project and compile one fat binary, which is no practical solution as this increases build times by limited availability of incremental compilation and makes it hard to generically manage very different dependencies, which could require different build settings etc. Or you can facilitate frameworks. Static libraries are not an option anymore.

Why is that the case? Because Apple doesn't let you build static libraries that contain Swift. Unlike Objective-C, Apple doesn't ship the Swift standard runtime libraries with iOS. This decouples the language version from the platform version. When you build an app with Swift, you're responsible yourself to ship them. By default, Xcode uses swift-stdlib-tool to handle copying the Swift runtime dylibs, but the tooling falls short when attempting to ship frameworks that use Swift with an app that is Objective-C only. Your app executable and the frameworks you ship will all use the same set of dylibs, which are embedded into the Frameworks subdirectory of the application bundle. First, that's because you can't link against different versions of the standard libraries. Furthermore it is desirable to embed them only once and not multiple times, because of constraints to memory size and network speed, which are relevant for distribution.

With this release, we initially allow you to use both in combination with CocoaPods. You can make CocoaPods integrate to your project via frameworks instead of static libraries by specifying use_frameworks!. If that's not present, you won't be able to integrate dependencies, if you depend on a pod which includes Swift source code. This is an all or nothing approach per integrated targets, because we can't ensure to properly build frameworks, whose transitive dependencies are static libraries. This release goes along with probably one of the most drastic changes of the whole project, which includes CocoaPods itself, but also required similar changes to Xcodeproj as well.

Dynamic Frameworks vs. Static Libraries

So what's the difference between those both product types?

One difference is obvious in their names: Dynamic and Static are opposites. This explains how they are linked to your code when integrated. Static libraries are just archives of your compiled source code, which can be partly integrated. They are not linked themselves before they are linked somewhere else. Dynamic libraries are final linked executables. When they are built, they are linked and the linker encodes what their dependencies are and where those are expected to be. Once they are built, the binary itself isn't altered anymore.

Another difference is their file system representation: Frameworks are bundles, which basically means that they are directories, which have the file suffix .framework and Finder treats them mostly like regular files. While libraries are just single FAT-binaries, which can't carry any resources as distinct files. If you tap into a framework, you will see a common directory structure:

They bundle some further data besides a binary, which is in that case dynamically linkable and holds different slices for each architecture. But that's only part, which static libraries covered so far. Belong the further data, there are the following:

The Public Headers - These are stripped for application targets, as they are only important to distribute the framework as code for compilation. The public headers also include the generated headers for public Swift symbols, e.g. BananaKit-Swift.h.
A Code Signature For The Whole Contents - This has to be (re-)calculated on embedding a framework into an application target, as the headers are stripped before.
Its Resources - The resources used e.g. Images for UI components.
Hosted Dynamic Frameworks and Libraries - This can be the case for so called Umbrella Frameworks provided by Apple. There is no use-case, where this happens with CocoaPods.
The Clang Module Map - This is mostly an internal toolchain artifact, which carries declarations about header visibility and module link-ability.
An Info.plist - This specifies author, version and copyright information.

Caveats

One caveat about bundling resources is, that until now we had to embed all resources into the application bundle. The resources were referenced programmatically by [NSBundle mainBundle]. Pod authors were able to use mainBundle referencing to include resources the Pod brought into the app bundle. But with frameworks, you have to make sure that you reference them more specifically by getting a reference to your framework's bundle e.g.

[NSBundle bundleForClass:<#ClassFromPodspec#>]

NSBundle(forClass: <#ClassFromPodspec#>)

This will then work for both frameworks and static libraries. There are only very rare cases, where you want to reference the main bundle directly or indirectly, e.g. by using [UIImage imageNamed:].

The advantage to the improved resource handling is that resources won't conflict when they have the same names. They are namespaced by the framework bundle. Furthermore we don't have to apply the build rules ourself to the resources as e.g. asset catalogs and storyboards need to be compiled. This should decrease build times for projects using Pods that include many resources.

`@IBDesignable` - Another Reason for Frameworks

Xcode 6 allows you to preview your own custom view components in Interface Builder. To make use of that, the view component must live in its own framework.

More about Frameworks

If you want to learn more about Frameworks, take a look into the Framework Programming Guide. Even though this was not written specifically for the new Cocoa Touch Frameworks, how Apple calls them in their Xcode target template, those are mostly the same to the classic OS X frameworks, so this document is still a helpful introduction.

Private Pods and `source`

On a last note, another change in this version is regarding private spec repositories.

In CocoaPods 0.36 and onwards, when using pods from private spec repositories, you will need to explicity list all the spec repositories that are used, using the source directive in your Podfile.
This is important for ensuring everybody in your team uses the same reference of specs whatever their local configuration is.

Note that if you don't use private pods (and only use pods from the official spec repo), you don't need to list any source as this will defaults to only using CocoaPods/Specs.

Updating

To install the last release of CocoaPods you can run:

$ [sudo] gem install cocoapods

Until version 1.0 we strongly encourage you to keep CocoaPods up-to-date.

For all the details, don’t miss the Changelog!

Test Jam

Sat, 21 Feb 2015 00:00:00 +0000

Last year, around this time, we ran a Bug Bash over a weekend. It went beautifully. We triaged a whole lot of issues, got a lot of minor issues fixed and found some new members for the core team.

Not ones to repeat ourselves, we’ve begun preparations on the next big community event. It’s a test jam, and everyone is invited.

TLDR/Elevator Pitch: If the community is going to move towards Swift, then let’s make sure that our Objective-C is in order by adding tests to established libraries.

Find out more below.

Date: April 18th + 19th 2015 Locations: NYC / SF / + More

We have picked out 200 pods without tests, or with very low test coverage, ordered by popularity. These are assigned randomly to interested contributors. They then will aim to:

Add tests to the library.
Add Travis CI.
Add Coveralls Support.
Submit a Pull Request to the original repo.

We will be operating a chat room with a lot of high high profile names in Cocoa testing over the weekend offering advice. So if testing is new to you, it may be a perfect time to start.

Which tool each contributor chooses to write tests is up to the owner of a library. This isn’t about wrestling control from them, but supporting the project. They could prefer XCTest, Specta / Expecta , Kiwi or Cedar. Each project will, ideally, have an issue stating this upfront. If not, it’s up to the contributor to decide.

We’re planning on emailing all authors soon offering the chance to opt-out or to advise on how to communicate a project’s testing intentions.

Finally we’ll likely be having office space in NYC (Artsy HQ), SF (Realm HQ) and more (feel free to email us if you want to do one in your city.) So you can sit with fellow testers, discuss difficulties and share triumphs.

🎉

The captain leaves the bridge

Mon, 02 Feb 2015 00:00:00 +0000

TL:DR I've had a fantastic 5 years making CocoaPods what it is today, but now it is time to care for my other babies: my new job, my house boat, and my actual baby!!! I will still work on CocoaPods, but not as much. Thank you all for a great 5 years!

I don’t know about you, but for me 2015 is going to be a year full of changes. I’ll be very busy and as such will have to make some concessions, but I’ll get back to that at the end. First, I’d like to share some of the amazing events that I will encounter this year.

New job

Starting today, I’ll commence at my new job as a mobile software engineer at Artsy. This is an exciting opportunity for me, both for the technical challenges and the admirable mission to bring all visual art online.

For now this means that I’ll be spending the better part of February getting up to speed with work at Artsy.

New houseboat

For the past decade, my wife and I have been living on a houseboat in Amsterdam and for the last four years we’ve been trying to get a new one built. This time was, unfortunately, mainly spent dealing with bureaucracy, but last year we finally got all permits approved and building commenced.

While the expected shipping date has been slowly delayed, the new boat is expected to ship in February (pun intended). Around this time, I’ll have to spend significant amounts of time on finishing work on the boat.

Actual baby

While CocoaPods and the building of our new houseboat could be considered “babies”, there is no substitution for the real deal.

I'm absolutely thrilled to say that my wife and I have been blessed with the gift of an actual human baby. We’re now at the 20 week mark, we now know it will be a boy, and that he’s in great health.

With the expected delivery set for the end of May, you can imagine the amount of time I will be spending on preparing our new houseboat for the baby.

CocoaPods

When I started on CocoaPods 5 years ago, I got to implement all the code myself and I had great fun doing that, but I have always wanted CocoaPods to be a community project and not have it stick to my name necessarily.

As such, over the past two years I have been doing less and less actual code implementation and more and more lead and maintainer coordination work. Most days I spent at least a couple of hours a day on CocoaPods. The amount of work I put in could easily be considered a part-time job.

During this time we have done an amazing amount of work, I have probably learned more about Xcode than any human should, helped more than a few people get started with open-source contributions, and helped at least a few to make their name and advance their careers. I am immensely proud of all of this and thankful for having been a part of this.

However, with all the changes for 2015 listed above, I am sure you can imagine the time constraints I will be under in this coming year. That combined with the amount of time I used to spend daily on CocoaPods work would leave little time for fun stuff to work on, lead to guilt over not getting tasks finished on time, or be feasible at all.

Therefore, I am now announcing, with slight pain in my heart, that the time has come for me to step down.

What does this all mean for the future?

I am not going away, I am simply moving more to the background. The most important parts being that I will relinquish day-to-day lead and maintainer work. These jobs will be taken over by the excellent Kyle and Orta.

Kyle will focus on the technical aspects, such as identifying issues, reviewing patches, and release management; summarized as the technical lead.

Orta, on the other hand, will focus on the user oriented design aspects, ensuring that the command-line interface and DSLs are kept as simple and intuitive as possible; summarized as the user-experience lead.

They have already gradually been taking on these roles over the past months and with great success. With the support of the other core members, myself included, I have no doubt that they will make the homestretch to version 1.0.0 a successful one.

During this homestretch there are a few fun tasks that I will then have time to work on and I can't wait to work on those and show them to you.

For now, keep being awesome. With <3 from Amsterdam.

Pod Authors Guide to CocoaPods Frameworks

Thu, 25 Dec 2014 00:00:00 +0000

TL;DR: CocoaPods 0.36 will bring the long-awaited support for Frameworks and Swift. It isn't released and considered stable yet, but a beta is now available for everyone via [sudo] gem install cocoapods --pre. Pod authors will especially want to try this version to make sure their pods will work with the upcoming release. This is because if a single dependency in a user's project requires being a framework, then your Pod will also become a framework.

What is special about Frameworks integrated by CocoaPods?

With CocoaPods, Frameworks are mostly set up in way similar to how it is done via Xcode. This is to make the entire integration inspectable, understandable and allows us to unleash the power of the whole existing toolchain.

Many of the tools only play nicely together in an Xcode environment where certain build variables are present. Cocoa Touch Frameworks use Clang Modules, which are also required to import and link them to your Swift app. Therefore the module map is included in the built framework bundle.

Dynamic Frameworks vs. Static Libraries

So what's the difference between those two product types?

Dynamic Frameworks are bundles, which basically means that they are directories with the file suffix .framework and Finder treats them mostly like regular files. If you tap into a framework, you will see a common directory structure:

They bundle extra data besides a binary, which is in that case dynamically linkable and holds different slices for each architecture. Up to this point it is the same as a static library. However, a framework holds the following additional data:

The Public Headers - These are stripped for application targets, as they are only important to distribute the framework as code for compilation. The public headers also include the generated headers for public Swift symbols, e.g. Alamofire-Swift.h.
A Code Signature For The Whole Contents - This has to be (re-)calculated when embedding a framework into an application target, as the headers are stripped before.
Its Resources - The resources used e.g. Images for UI components.
Hosted Dynamic Frameworks and Libraries - This can be the case for so called Umbrella Frameworks provided by Apple. There are no use-cases where this happens with CocoaPods.
The Clang Module Map and the Swift modules - These are mostly internal toolchain artifacts, which carry declarations about API / header visibility and module link-ability.
An Info.plist - This specifies author, version and copyright information.

One caveat about bundling resources is, that until now we had to embed all resources into the application bundle. These resources were referenced programmatically by [NSBundle mainBundle].

Pod authors were able to use mainBundle referencing to include resources the Pod brought into the app bundle. But with frameworks, you have to make sure that you reference them more specifically by getting a reference to your framework's bundle e.g.

# in Objective-C
[NSBundle bundleForClass:<#ClassFromPodspec#>]

# or in swift
NSBundle(forClass: <#ClassFromPodspec#>)

This will then work for both frameworks and static libraries. There are very few cases where you want to reference the main bundle directly or indirectly, e.g. by using [UIImage imageNamed:].

The advantage to this improved resource handling is that resources won't conflict when they have the same names because they are namespaced by the framework bundle. Furthermore we don't have to apply the build rules to the resources ourselves as e.g. asset catalogs and storyboards need to be compiled. This should decrease build times for project using Pods that include many resources.

Module Names

Names of Clang Modules are limited to be C99ext-identifiers. This means that they can only contain alphanumeric characters and underscores, and cannot begin with a number. Looking through the official spec repo, we discovered some popular pods, which don't match these requirements.

Before, as a Pod author, you could use header_dir to customize the name prefixing your headers from the user target. E.g. if your pod is named 123BánànâKit, you could set it to BananaKit, it is available by import <BananaKit/BananaKit.h> instead of #import <123BánànâKit/BananaKit.h>.

We are still supporting this usage, but also introducing a new attribute module_name, which you declare in your Podspecs. This new attribute has the advantage that it will be properly linted and verified, otherwise we will work from the header_dir option. If either attribute is not present then we will derive with the spec's name to match the Clang Module name requirements.

In a nutshell, look at the following Swift snippet, which concisely expresses the way in which we determine the module name.

//let c99ext_identifier: String -> String?
func module_name(spec: Specification) -> String {
  return spec.module_name
    ?? c99ext_identifier(spec.header_dir)
    ?? c99ext_identifier(spec.name)!
}

Module Maps

A Module Map is a declaration of the headers, which form the public (or private) interface of a Clang Module. Luckily, those have been designed so that they can stay in the background and the developer can leverage known and existing structures, without having to learn the DSL. The default modulemap looks basically always the same:

framework module BananaKit {
  umbrella header "BananaKit.h"

  export *
  module * { export * }
}

This references only one file explicitly: the umbrella header.

You can export the public API for your framework inside a umbrella header and all transitive imported headers. Clang will take care of making module exports that can be imported by Objective-C and Swift.

What Does Transitive Imported Mean In This Context?

Transitive relations are a mathematical concept:

Whenever an element a is related to an element b, and b is in turn related to an element c, then a is also related to c.

We have here the binary relation of a header file, which imports another header file. The transitive closure means that all headers, which are imported by header files, which you have imported from a certain file are indirectly imported to that file, too. That's also the same for all header files, which are imported by the collection of those headers. Surely, you know this property from your app target, whenever you import a header, which imports other headers, the classes and symbols, which are defined there, are also available in your app code. The same has to apply for import statements in Umbrella Headers and effect the module visibility with Clang modules.

What are Umbrella Headers?

For our example it could look like this:

#import <Foundation/Foundation.h>

@import Monkey;

#import "BKBananaFruit.h"
#import "BKBananaPalmTree.h"
#import "BKBananaPalmTreeLeaf.h"

FOUNDATION_EXPORT double BananaKitVersionNumber;
FOUNDATION_EXPORT const unsigned char BananaKitVersionString[];

The original purpose is to index all public headers of a directory to have a shorthand for imports/includes to access the full API of a library. Over time, they began to cover more and more purposes:

With (Cocoa Touch) Frameworks: they allow quick access to versioning values defined in their Info.plist by on-the-fly generated C code. Therefore they have to define an interface to make them accessible. These are the constant declarations found in the Xcode template prefixed by FOUNDATION_EXPORT.
With Clang modules: they are used to define the public interface of a module.
With Swift: they are the bridging header for the framework module, which essentially means that all Objective-C code you're interfacing from Swift within your framework has to be part of its public API.

Current Situation with Existing Podspecs

There has never been a declarable Umbrella Header in Xcode. So Pod authors have never had to specify one.

Though it has always been a known pattern to have one public header, which imports all other public headers transitively. This isn't always the case.

For this reason, CocoaPods takes responsibility and generates a custom Umbrella Header (e.g. Pods-iOS Example-AFNetworking-umbrella.h). This is injected by a custom module map, so that we don't run into name ambiguities. Otherwise, the default module map would assume it has the same name as the framework, which could already been taken.

Our generated header imports all declared public headers. This also defines the FOUNDATION_EXPORTs for the versioning constants, with the name which is used by CocoaPods for the framework to integrate. Furthermore this avoids problems in some special cases: e.g. AFNetworking has a subspec, which provides categories for UIKit that has its own mass-import header AFNetworking+UIKit.h, which isn't imported by the AFNetworking.h header for OSX compatibility.

To use this subspec in Swift without a generated umbrella header, you would need to create a bridging header and use an import like #import <AFNetworking/AFNetworking+UIKit.h>. With the generated umbrella header, you just need to import AFNetworking if you have the subspec included in your Podfile. If your pod doesn't work out of the box, you can use pod lib lint --use-frameworks <YourPod.podspec>, to check what is wrong. We tried that with different popular pods and sometimes ran into issues caused by misconfigured public headers.

About Public Headers

Public Headers in Podspecs are declared by s.public_header_files = ["Core/*.h", "Tree/**.h"].

If you don't include this specification, then all your headers would be public. This isn't recommeded for most cases.

Generally, you should make sure that you have self-contained headers and that those only expose the parts of your implementation which is consumed by your Pods users. This has several advantages:

It allows you to refactor the private implementation part without necessarily releasing a major update, which makes the version migration easier and allows you to focus on further improving your pod instead of explain your users how the API has changed.
It impedes misusage, because you would need to modify header access to use or manipulate classes or properties, which are not intended to be used externally.

Common Header Pitfalls

If you have an header like this:

/// BKBananaFruit.h

#import "BKBananaTree.h"
#import "monkey.h"

@interface BKBananaFruit
@property (nonatomic, weak) BKBananaTree *tree;
- (void)peel:(Monkey *)monkey;
@end

And if you get an error like the one below, don't let it fool you.

You can include headers inside frameworks, but not quoted headers, which are not in scope of the framework's public headers. So you have two choices in this case: Either make the header BKBananaFruit.h private by excluding it from the public header declaration or use a system import to import the monkey.

-#import "monkey.h"
+#import <monkey/monkey.h>

Xcode Oddities

We have seen this error a few times during development.

<unknown>:0: error: could not build Objective-C module 'BananaKit'

An error like above can appear, if you develop a framework in Xcode, and you alter header visibility to fix build problems like described previously and try to ensure a clean build state by executing the Clean action (⌘+ ⇧+K in Xcode). In this situation, it can be helpful to nuke the products build directory (alas DerivedData) manually from the file system.

Availability

CocoaPods only supports Swift on OS X 10.9 and newer, and iOS 8 and newer.

Here's why:

Swift is supported on OS X 10.9 / iOS 7 and newer, as stated by Apple numerous times.
There is no support for building static archives with Swift.
Dynamic frameworks are supported on all versions of OS X.
Dynamic frameworks are unsupported on iOS versions prior to 8:

ld: warning: embedded dylibs/frameworks only run on iOS 8 or later.

From this we can conclude that it is not possible to support Swift on any platforms earlier than OS X 10.9 and iOS 8.

To use Swift libraries on apps that support iOS 7, you must manually copy the files into your application project.

Updating

To install the latest Beta of CocoaPods you can run:

$ [sudo] gem install cocoapods --prerelease

Until version 1.0 we strongly encourage you to keep CocoaPods up-to-date. For more user facing changes, you can take a look at our upcoming official release blog post.

For all the details, take a look into the PR!

Search Engine

Mon, 15 Dec 2014 00:00:00 +0000

TL;DR: The CocoaPods search engine is not web scale, but instead tailored to our needs. Here's why and how.

First let's look at some numbers... Currently, the CocoaPods search engine indexes 7378 pods. From these pods, it indexes name, author, version, dependencies, platform, summary, and synthesized tags.

On average, people search 13 times per minute, more during the week, less on weekends (switch to the Month view to see that). The occasional spike is roughly ten times that, so about twice per second. These spikes are not visible on the status page, as the number of requests are averaged over five minutes. As you can see, the search engine never rests: CocoaPods are searched for at all times.

How do our users search?

Searching on cocoapods.org

CocoaPods can be searched via the Search API, so for example at http://search.cocoapods.org/api/v1/pods.flat.hash.json?query=author:tony%20author:arnold, or via cocoapods.org.

The latter, the web site front end interface, uses the former and is more interesting, so let's have a look at that:

It is a fast as-you-type search – if you don't type for 166 ms, it sends a query to the Search API.
The second feature I'd like to look at in more detail in the next section: showing where your query words were found and offering the most appropriate guess.
It lets you know when it hasn't found anything, but offers helpful suggestions, such as when you search for datanotfound. To do that, it tries to split your query based on the indexed data. It also displays a tag facet cloud.
It sorts the results by popularity, a metric orta came up with together with David Grandinetti. This is the default sorting algorithm right now, but we're working on more. Adding a new algorithm is easy and has already been done.

Other features include storing the query in the URL for easy copying, or a results addination (portmanteau of "adding" and "pagination"), or being able to select which platform the pods are filtered with.

With the search-as-you-type feature, we encountered an interesting issue: Because shorter queries yield more results, and therefore take longer, it was possible that a request made earlier could arrive after a request made later. This led to a jarring "jumping" of results.

To solve this issue, we only show results that arrive in the order we sent them. If we send requests A, B, and C, and A returns first, we show it. If then C returns, we show it too, as it arrived in order. If then B arrives after C, we discard it, as it is out of order. That neatly solves the issue of jumping results, and also ensures a very responsive feeling for a user.

But what is the second feature about?

Picky

Picky is a semantic text search engine, running on Ruby. It is fast (it uses C for the core bits), flexible (it uses Ruby for maximum flexibility), and versatile. On the other hand it does not yet offer a drop-in server, so if you need a web service, you need to write one, such as we did. We use Picky for search.cocoapods.org.

Using Picky had two main impacts: we were able to create a highly specialized search engine for pods, and we can harness the power of a semantic search engine.

So what is this semantic search you mention? If you run orta, in the top right corner you can see an "Author 5". This means that Orta has been found five times as an author. This may not be too exciting.

However, if you enter two words, or parts of words, then Picky can start guessing what you mean. For example, if you enter orta m, then Picky guesses that you meant "Author+Name" (2 results) first, and "Author" (1 result) second. The former refers to the two pods which are named "M*" and have Orta as an author. The latter refers to the Mixpanel pod which has two authors: Orta and Mixpanel (which is why the M* finds that one).

If you click one of these suggestions, then you can see that it's possible to let Picky know what you are looking for, if you already know ("author:orta name:m"). Normally you don't need it, but it can help if you have almost no idea anymore what the pod was called. For example, perhaps you still remember that the author may have been Bob or Bert, so you enter a "B". The pod almost certainly has a word with a c in it, so you add a "C". Then Picky will show you all possibilities that a query like "B* C" results in. This query is the resulting one.

To decide what combination of categories the query words are most likely in, Picky decides based on probability. However, since we also know what combinations people will most likely look for, we've told Picky what to prefer: for often occurring combinations, we've added boosts. So if your query is found in name (+3) and dependencies (-4), then it will most likely show the name results on top.

And how is it specialized for pods? For example, when indexing pod names, we give the search engine the pieces we expect will be queried for. That usually means e.g. for "TICoreDataSync", we use the whole word, split it into the two uppercase initials, and each word starting with an uppercase letter, and also the whole word without the two initials. This enables you to search for "coredata" and get the "TICoreDataSync" pod. Or you can search for "network", and get AFNetworking.

Personally, I feel very strongly about creating specialized search engines if you want to provide the best experience for your users.

Limitations

As the CocoaPods team cannot afford a server farm, but only a single server on Heroku, and a cheap shared CPU at that, we needed to be smart in designing the infrastructure. We started with a list of requirements:

It should fit and work on a shared Heroku CPU.
It should reindex pods using Trunk web hook calls. So if a pod is pushed to Trunk, search should know about it ASAP (in less than 30 seconds).
It should be stable. Nobody likes not being able to search.
It should have little downtime when restarting.

To satisfy these requirements, we started thinking about the design.

Design

From running the search engine for a few years, we knew:

For it to be responsive, we need multiple web workers.
Searches are generally fast.
To handle Trunk webhook calls (similar to GitHub webhook calls), we needed a HTTP endpoint serving these.
To index pods while searches are being made, we need it to be done in the same process (since we use the Picky memory index, the fastest option, and Redis wasn't an option with our budget).
Indexing a pod takes almost negligible time.
No downtime on a single Heroku CPU is impossible, because restarts cannot be avoided.
We don't need to serve a 1000 requests a second, even though a performance-lover like me wants to. 20-30 is enough by far (1200-1800 per minute), and we should design for that.

As a result, we arrived at this design:

Before Unicorn spawns two web workers, we fork off an analytics and a search process. Both only load what they need after forking. Before we fork any of these, we open up channels so the web workers can communicate with the search process and the analytics process.

When a web worker forks, it chooses one of the above channels to communicate with the search engine and analytics process. Web workers are very thin – they only send the queries to the search engine process. This means any web worker can be restarted without problem, as they are relatively light.

Handling queries

If any query comes in, it is handed off to the search engine process, and also sent to the analytics process. The analytics process is only concerned with sending analytics data to Google Analytics. We need it to run in a separate process as currently we are using a synchronous library which would block the process.

The search engine process jumps straight into an event loop after forking. While looping, it checks if any requests have arrived via channels. After that, it starts indexing pods, taken from the database, a few at a time. In this way we can avoid long downtimes, as we can immediately return a few pods. A drawback of this technique is that people won't get all pods they would usually get as for example only 100 pods may yet be in the index. However, we index the pods in the order of popularity, so we fill them in from the top of the results list, so to speak. So even if the search engine is still indexing, you get relevant results.

This event loop also counts the queries for display on status.cocoapods.org. Every 30 seconds, it sends the stats to the statuspage. To not stop the event loop, we fork off these web service calls.

One issue that occurred about 9 hours after putting this live was that the search engine ran out of resources. After investigating, I had to shamefully admit that I forgot to clean up after these forks. This resulted in that single Heroku process handling on the order of 2000 child processes until it croaked, which occurred at about 9 hours after restarting. I was and am impressed at Heroku going for that long. Now, for example, we send calls to the status page every 30 seconds, remember the child process PID and clean it up again before we send off the next call. Now the search engine purrs along nicely.

Handling Trunk webhook calls

To be able to index on the fly, any of the three web workers handle Trunk webhook calls. They then inform the search engine process, also via channels, which then will reload the right pod from the Trunk DB and reindex it. This has resulted in a less than 30 second delay between you pushing to Trunk and the search engine spewing out updated results. Note that there is some browser caching of results going on, so when you try it, please clean the cache and reload.

Summary and The Future

To make a truly CocoaPod-specific search engine that would enable us to experiment and at the same time fit on a single shared Heroku instance, we used Picky, Heroku and a multiprocessing-based structure (with a single process search event loop), while still being able to serve enough results at a time.

We are currently working towards a CocoaPods search interface version 2 that will - I think - blow your minds. It will be the culmination of months (seriously!) of volunteer work and will pull together data from our many APIs to provide the snazziest pod searching interface possible.

Please leave your ideas if you have an idea to add.

Metrics API

Thu, 11 Dec 2014 00:00:00 +0000

TL;DR: We have a new metrics API that you can now use.

For the past nine months, we've had a metrics API where we gather data for each pod, currently only from GitHub.

API

Currently the API provides GitHub metrics, per pod. The provided format is JSON, which is also the default.

It's best if you give it a try yourself. Here's a popular pod: http://metrics.cocoapods.org/api/v1/pods/AFNetworking.json

And here's a not yet popular pod: http://metrics.cocoapods.org/api/v1/pods/KFData.json

The API pattern is, you guessed it: http://metrics.cocoapods.org/api/v1/pods/PODNAME.json

Each pod's data is updated roughly every 2 hours.

To check the status of the metrics app, you can call: http://metrics.cocoapods.org/api/v1/status

This will tell you the total amount of pods, and how many have been found on GitHub, and how many have not been found after three tries.

Design

The metrics app is very straightforward. It lives on Heroku and consists of two pieces: A round robin updater, and a resetter.

The updater is forked off as the web app is started. It runs forever and goes through each pod, one by one. Every second, it queries GitHub for metrics data of another pod. Currently, all pods are updated roughly every two hours.

If it can't find the pod, it marks the pod as once not found. If your pod is not found three times (on GitHub), roughly 6 hours, it gives up on the pod. Currently there are 117 pods which have no corresponding repo page on GitHub. This is ok, as not everybody is or needs to be on GitHub.

If a pod is not found, won't metrics ever try again? We've got that covered. The resetter listens to the Trunk (where you push pods) web hooks. The trunk web hook system pings many CocoaPods websites to inform them of updated pods. If a new pod has been added, just a new versions, or a new commits – it pings for example the metrics webapp. If the metrics app receives the Trunk app's bat signal, it resets the pod's not found count. From then on, metrics will try to find the pod's metrics again on GitHub.

Closing words

Why use this instead of the GitHub API? You can access it via a pod's name and it's designed to be extensible, so more exciting metrics will be added.

We hope you'll use the API for success and profit. If you do, let us know.

Also, if you feel strongly that another service (besides GitHub) should be included, let us know.

Go forth and measure!

CocoaPods 0.35 and Molinillo

Wed, 19 Nov 2014 00:00:00 +0000

TL;DR: CocoaPods 0.35 has been released, with major improvements to the dependency resolution process, thanks to Stripe's support. Making the 0.35 release possible is the concurrent release of Molinillo 0.1, our new dependency resolution module.

The CocoaPods 0.35 is much more limited in scope than 0.34 was, but the improvements in this version center on the heart of what CocoaPods is: a dependency manager. While the list of new features may seem short, don't be disappointed: this is a major step forward for CocoaPods.

Dependency Resolution

At the heart of any dependency managers is its Resolver, whose job is to take a list of dependencies (defined in a Podfile) and transform those explicit requirements into a complete set of Pods to install. With CocoaPods 0.35, the core dependency resolution code has been completely rewritten, giving birth to Molinillo, a generic dependency resolution module. This change should improve the experience of using CocoaPods by making things work in a more predictable manner and allowing you to focus more on your project instead of making things easier for CocoaPods.

Automatic Conflict Resolution

Consider the following Podfile and note that CocoaPods will by default, when no version requirements are specified, try to activate the latest available version of a pod. (The versions in this example are based on the latest available versions of the pods in question at the time of writing).

pod 'AFAmazonS3Client' # Version 2.0.0 activates AFNetworking with: >= 2.0.0 && < 3.0.0
pod 'CargoBay'         # Version 2.1.0 activates AFNetworking with: >= 2.2.0 && < 3.0.0
pod 'AFOAuth2Client'   # Version 0.1.2 activates AFNetworking with: >= 1.3.0 && < 2.0.0

On prior versions of CocoaPods, attempting to pod install would yield an error saying Unable to satisfy the following requirements since the latest versions of all three pods have incompatible dependencies on different versions of AFNetworking. With the old resolver, we would naïvely try to activate the latest spec version for the first dependency and continue from there, which would lead to a conflict, since there was no way to get to an older version of AFNetworking (or any of the pods that depended upon it). No more. With the transition to Molinillo, a generic dependency resolution gem I've been writing at Stripe, Podfiles like this will have such conflicts automatically resolved.

Let's take a look at the same Podfile in CocoaPods 0.35:

pod 'AFAmazonS3Client' # Version 1.0.1 activates AFNetworking with: >= 1.3.0 && < 2.0.0
pod 'CargoBay'         # Version 1.0.0 activates AFNetworking with: >= 1.0.0 && < 2.0.0
pod 'AFOAuth2Client'   # Version 0.1.2 activates AFNetworking with: >= 1.3.0 && < 2.0.0

From the above, it is clear that the latest versions of AFAmazonS3Client and CargoBay are not compatible with the requirements of AFOAuth2Client. As such, the new resolver will now backtrack and try to satisfy the requirements of AFOAuth2Client by looking for older versions of AFAmazonS3Client and CargoBay that are compatible with AFNetworking versions between 1.3.0 and 2.0.0, thus activating AFNetworking version 1.3.4 and correctly satisfying all of the dependencies in the Podfile.

The resolver is now able to backtrack when conflicts arise, thus allowing it to simultaneously satisfy all dependency constraints, or definitely state that the Podfile is unresolvable. The development of a language-agnostic resolver integration suite made this possible, and will hopefully ensure that other dependency managers can provide a consistent resolution process.

Improved Locking

CocoaPods has always had a version locking feature (it's your Podfile.lock) that tries to ensure that, whenever someone clones a project and runs pod install, they will get the same dependency versions as you. Well, in CocoaPods 0.35, that version locking has been extended to implicit dependencies as well, so your Podfile.lock is now an absolute source of truth.

Pre-Release Dependencies

At CocoaPods, we love it when people make pre-release versions of their libraries -- we do it ourselves! In order to more strictly conform with Semantic Versioning, pre-release versions of a Pod will now only be considered in the resolution process if there is any dependency on the pod with a pre-release version in its requirement.

Thus, if you want a pre-release version, such as a beta, you will have to specify that in your Podfile, like so:

pod 'AFNetworking', '~> 2.0.0-RC1'

External Source Optimizations

Handling of dependencies with external sources (e.g., pod 'RestKit', git: 'https://github.com/RestKit/RestKit.git') has been optimized and clarified in this release. CocoaPods now only downloads each Pod with an external source once, which has the nice side effect of making linting specifications that have a lot of subspec dependencies faster. CocoaPods also lets you know when there are conflicting dependencies, so you can remove unwanted duplication from your Podfile. Finally, CocoaPods lets you know if you specify the same Pod with different external sources, instead of a random source being chosen.

Locking Checkout Options

At the intersection of improved locking and external source optimizations is CocoaPods 0.35’s final feature: the lockfile now hold the information necessary to ensure that dependencies directed installed from a repository will be locked to the same revision until updated. That means this Podfile, along with its corresponding Podfile.lock, will ensure that every member of your team is always on the same revision of all of your dependencies:

pod 'AFNetworking', :git => 'https://github.com/AFNetworking/AFNetworking.git'
pod 'RestKit', :git => 'https://github.com/RestKit/RestKit.git', :branch => 'development'
pod 'ARAnalytics', '~> 2.9.0'

AFNetworking will continue to use the same commit that was downloaded when you first ran pod install, so you don’t have to worry about changes sneaking in when you run pod install on a new machine. As always, pod update AFNetworking will update you to the latest commit.

Performance Improvements

Molinillo makes resolving a normal application's Podfile roughly 1.5x faster than the old resolver, which is astonishing given the wider breadth of its feature-set. Additionally, the external source optimizations should make fetching multiple subspecs from an external source many times faster.

The vast majority of this release's performance improvements come from Eloy's work on optimizing expensive operations in Xcodeproj. This makes CocoaPods' integration steps blaze by!

Bonus News

I’ve been working on bringing Molinillo over to Bundler so we can hopefully share a dependency resolution implementation in the future.

Updating

To install the last release of CocoaPods you can run:

$ [sudo] gem install cocoapods

Until version 1.0 we strongly encourage you to keep CocoaPods up-to-date.

For all the details, don’t miss the Changelog!

2014

Tue, 18 Nov 2014 00:00:00 +0000

CocoaPods is a reflection on the Cocoa community, a mirror that reflects the effort of thousands on individual contributions to a greater idea of sharing and helping each other to improve. As the community grows, so does the tooling around it, growing on both complexity and size.

A year ago we unveiled the new CocoaPods branding. It was the culmination of 6 months of design and development work for a few volunteers in their spare time. Let's take a look at what else has changed in the last year.

Contributions

We had two people paid to work full time for a period on CocoaPods this year. The first, Fabio Pelosin, used his time sponsored by SoundCloud on refactoring internals, helping to bring in support for CocoaPods plugins and per-config Pods, then finally improving the command line interface. The second, Samuel Giddins, has been mostly working on a iterative dependency resolver for both CocoaPods and Bundler ( CocoaPods for Ruby. )

The team in general has shifted too. A lot of the current major commiters were not working on CocoaPods last year. We've increased the number of active developers from roughly 4 to roughly 8. This is hard to judge because CocoaPods is a side project for most. But there's a lot of new and very welcome faces in the contributors chat room.

Web Properties

A year ago, documentation existed in four places; the CocoaPods homepage, a developer reference based on the ruby source code, a docs subsite and the GitHub wiki. This was consolidated into a single guides site which everything important goes into, with the expectation that StackOverflow would fill in gaps.

The traffic for the website went from a 60,000 impressions/month to a combined 180,000. This splits out from cocoapods.org: 120,000, blog.cocoapods.org: 8,000, guides.cocoapods.org: 55,000.

We changed the focus of the homepage to reflect what we were seeing in analytics; people were spending a lot of time using our search. The new design moved search front and center on the website and it shows in our analytics, we went from 70,000 searches per month, to a massive 825,000. It increased its complexity, and was re-written to deal with the scale. It also now uses our metrics to derive a sorting algorithm for popularity. It's not perfect, but it's a great step in where we want to go.

We introduced a few new web services, there's a metrics engine that constantly grabs metrics from GitHub (and soon CocoaDocs for quality) for all Pods. This will make up the bulk of a true CocoaPods API.

There's an authentication server, trunk, which provides library authors with the ability to control who can push releases of their library. Previously we were using Pull Requests, of which the community make 12,000+, making us one of GitHub's most active repos. Now it's bigger, and automated. Because of this we saw an increase of contributors to the specs repo go from 1,800 to 4,200. On the other side, we're now seeing roughly 1,500 downloads of the Specs repo a day.

Community

As a nice metric of interest, the @CocoaPods twitter account has gone from 4k to over 10k. We split out the new pod announcements to a separate twitter account @CocoaPodsFeed in order to deal with the number of new pods.

On the subject of new Pods, this vastly increased 2,400 to 7,000. I expect this is in-part due to the network effect, and reducing the barrier to entry. We devoted a considerable amount of time towards making a OSS library very easy with the command pod lib create offering best practices as defaults.

Events

We ran a some CocoaPods events, a few meetups which went swimmingly. A hackathon based around a CocoaPods plugin. The most interesting was a CocoaPods bug bash. The idea was that we try deal with as many small issues as possible, we planned it for a weekend but had completed by the first day. The second day was spent improving CocoaPods. The bash gave us some great experience in onboarding and bootstrapping people to work on CocoaPods which resulted in a meta-repo, Rainforest, that holds all the repos. It also introduced new contributors who are invaluable now.

CocoaPods

We hit 1,000,000 total downloads of the CocoaPods Gem this month.

The last release in October 2013 was CocoaPods 0.26. Since then CocoaPods has added:

Config based Pods
Plugin support
Updating a specific pod
Vastly reduces networking around local caching
Moved to support JSON podspecs
Switched to pre-built libraries
Added a command to try any Pod instantly
Handles Xcodeproj merge conflicts elegantly
Added the ability to deprecate a Pod
Release Candidates for CocoaPods

1.0

The future is very bright with the imminent next release bringing in the work on the resolver.

Then Swift CocoaPods. This has a singular Pull Request you can follow. I've personally migrated the Artsy iOS Swift App to remove all submodules and use just CocoaPods. Making a Swift or Dynamic Framework pod will be no different from an Objective-C one.

We've been working towards a stable 1.0 release which means long term support. As an issue can only be in one milestone our official 1.0 milestone is a little empty. Swift support pushed us back a bit on this, but not considerably.

On a personal note. It's been super gratifying to work on such a high profile tool used by so many people. I think that CocoaPods considerably lowers the barrier to entry for new programmers, and makes it easy for the experienced to improve their codebases by covering the entire ground from library discovery to Xcode integration. This is the fourth year since the first CocoaPods commit and it has been the best so far.

Starting Open Source

Sat, 25 Oct 2014 00:00:00 +0000

On July the 7th I attended the CocoaHeads Stockholm meetup. For this particular meetup the brilliant, but unknown to me at the time, Orta Therox held a talk about open source, CocoaPods and how they work at Artsy.

For very long time beforehand I had felt that I was not contributing enough back to all the awesome projects that I used daily; CocoaPods being one of them. Orta really inspired me to take the first steps to contribute back. I promptly went home and started working on a issue I found among the CocoaPods issues on GitHub. After finishing that I jumped straight on to another related issue. After a landing a few PRs I was invited to the CocoaPods slack team to discuss further. This post talks about my first steps into contributing back to a large project.

Why do Github issues often become filled people saying things like +1, I need this and Would be awesome instead of PRs solving the issue?

I can relate to this, I have made my fair share of +1 and I need this comments. From my very personal, but probably non-unique experience, it's really a mentality issue more than anything. Ultimately it's related to my confidence as a programmer and a slight touch of Impostor Syndrome.

I can't provide value

A statement that I often used to justify my passivity was I can't provide value here, the other contributors are just too skilled. It's true that many open source projects are huge behemoths with a lot of code and things to understand, but every single contribution still matters and provides value to the project. A project without contributions, big or small, will stagnate.

I think there's also an important point to be made here about making the project accessible for new contributors. It should be as simple as possible to get started, that means setup of environment and finding issue which are suited for contributors who are not yet familiar with the code base. CocoaPods does both of these very well.

For setup there's a repository called Rainforest which contains a rake task to setup everything needed to develop CocoaPods. Additionally almost all repositories contain a rake task called bootstrap which will setup the repository for development.

For finding issues CocoaPods uses a labelling systems to illustrate how difficult an issue is as seen here. The label easy is perfect for finding tasks for new contributors. In fact I have started working on quite a few of them, but many times I ran into problems which were too difficult or things I simply didn't understand well enough. I abandoned quite a few issues because of getting stuck, which is both good and bad. It's good because it's important that you are able to try your hand at solving issues and failing without being assigned the issue or feeling pressure to finish it. The bad part leads me to the next issue I had, asking questions.

I shouldn't waste the core contributors time by asking trivial questions

Even after getting passed the initial feeling of not being able to provide any value, landing my first PR helped with this, I was still reluctant to ask the core contributors questions because I felt like I was wasting their time. To quote myself from a discussion we had.

That's one of my concerns. I know that everyone else can implement trivial things much faster than me. I try to weigh asking question against that to not produce negative value

While it's true that having core contributors spending time on helping you might produce negative net value in the short term, in the long term you will end up with more developers who are productive and familiar with the code base.

This was best expressed by one of the core contributors.

Let me just re-iterate @k0nserv: please ask us any and every question you have. That's why all of us work on CocoaPods

Conclusion

After forcing myself to submit my first PR to CocoaPods things got a lot easier. I felt happy for contributing something and because it was received in a good way by the maintainers. Getting past my doubt to ask question was really only about getting told it wasn't the problem I was making it out to be.

So back to the original problem, since my first contributions to CocoaPods I have sent numerous PRs to other projects where I saw that something was lacking. This has been things like SSL improvements to the AWS cookbooks and a minor spelling error for a gem I was considering for work. I truly feel like I have stepped out of the +1 mentality and into the I'll submit a PR fixing the problem I found mentality. Starting out with open source contributions is one of those things where you just need to take a plunge and soon you'll find yourself doing it naturally.

Recommendations for contributors

Do you want to contribute to open source, but are having the same doubts as me or maybe completely different doubts? Here are my tips for getting started.

The initial hurdle is mainly about deciding to do it and picking a project. For the project it makes sense to pick something that you use yourself and even more so if you already have a task identified. If you don't have a specific task you want to work on checkout the issues on GitHub and if you can't find something that seems like a good fit for a new contributor in the issues ask the maintainers. Good candidates for projects are dependency managers, libraries, and other supporting tools.

So you picked your project and task and started working on it. If it's a fairly large project such as CocoaPods it's good to remember that it's perfectly fine that you don't grasp all the ins and outs of the code, in fact you don't have to. The important thing is understanding enough of the code which is related to the task you are working on. If you work with iOS or OSX CocoaPods is of course the perfect choice of project.

When you finished your task make sure that you have tests covering any new code or old tests which might have had to be adjusted also make sure that you're adhering to any style guides set by the project. Submit your PR and wait. Fix any issues raised by the maintainers and hopefully your PR will be merged. Good job!

The next time you find yourself frustrated with something missing or not working in an open source tool you use remember that you have the power to fix it!

Recommendations for maintainers

If you want to have more contributors helping out with a project you are maintaining(why wouldn't you?) make sure that it's accessible and provide a good introduction for new contributors. This includes things like setup, running tests, code conventions, CI, labelling of issues.

Answer questions when asked and encourage a community where questions should be asked not silenced.

I feel like CocoaPods really is a good project to be inspired by in this regard. It's a truly an awesome project to get started with.

And Remember

Coins

Wed, 22 Oct 2014 00:00:00 +0000

Physical objects for abstract ephemeral work.

Working on tools is all about levels of abstraction. CocoaPods abstracts away the idea of dealing with the transmission, setup and installation of a Cocoa Library into just pod "FDModel". The bits and pieces behind the internals are just as abstracted away from CocoaPods through ruby gems like Xcodeproj, Molinillo and CLAide.

Devoting time to CocoaPods is not a thank-less task, those who have become known for their work on CocoaPods have vastly improved their Klout score. Being a person who has submitted two or three pull requests probably hasn't though. We want to try and do something to say thanks in a meaningful way. We opted for token of our gratitude in the form of a coin. We'll be getting these sent out to the top 80 contributors to CocoaPods the tool.

Turns out a friend from my old hometown has started up a company selling custom metalwork objects. When I was over last they let me share their office and showed me some beautiful pieces they had been making. I knew this was the perfect answer to the question I had been thinking about for a while "How can we give something back?".

Most commits from people outside of the top 15 are people scratching their own itches. Annoyed at the tool they use isn't quite working how they'd like. For a lot it's their first entry into writing ruby code. The dev team guides and helps out as much as possible but it still took someone to take the first step on their own. Our selection process for the top 80 isn't even that strict, if you submitted a lot of grammar and spelling fixes to the websites you've also made a really useful contribution to the community. It helped.

They're gold because you're awesome.

They're hefty because we care.

The core dev team aren't the only people making CocoaPods.

Thank you all

fabiopelosin, alloy, orta, floere, segiddins, kylef, neonichu, lukeredpath, AliSoftware, Keithbsmiley, mtitolo, Kapin, nolanw, goonzoid, mrackwitz, siuying, supermarin, jasl8r, yas375, dbgrandi, subdigital, kommen, ianyh, xslim, swizzlr, pietbrauer, pbernery, 0xced, clarkda, mk, jweinberg, carsonmcdonald, Manfred, nevyn, fmccann, k0nserv, squarefrog, luisdelarosa, tayhalla, dlackty, gfontenot, blakewatters, Thomvis, joe-loco, groue, AshFurrow, heyzooi, dev4dev, croach, farcaller, samstewart, dlvenable, dcutting, nskboy, Ashton-W, rivera-ernesto, lazerwalker, phatblat, ulrikdamm, chriseidhof, drodriguez, olarivain, MaxGabriel, schneiderandre, andreamazz, nmccann, Lascorbe, dhoerl, Noreaster76, l4u, seivan, netbe, paulyoung, kattrali, fluidsonic, alexrothenberg, martincik, btaylor, listrophy, modocache and atomkirk.

I'm not looking forward to mailing these!

CocoaPods 0.34

Fri, 26 Sep 2014 00:00:00 +0000

TL;DR: CocoaPods 0.34 which includes the work sponsored by SoundCloud has been released. The highlights? Support for scoping Pods per build configuration, declaration of source repositories, and faster downloads.

This release will require making changes to your Podfiles

I would like to thank SoundCloud and the Travis Foundation for their support. Without their contribution, this release wouldn't have been nearly as extensive. Initiatives like this constitute an important engine to foster the development of the CocoaPods community.

Dependencies per build configuration

Read this:

pod 'Lookback', :configurations => ['Debug']

Are you getting it?

Finally you can specify dependencies per build configuration. This is one of the most requested CocoaPods features… ever.

The work on this functionality was kick-started by Joachim Bengtsson with what I could describe only as a great open source attitude. Joachim was interested in curating the complete experience of Lookback, including installation with CocoaPods. Instead of just opening an issue he went above and beyond and proposed one of the most ambitious pull requests which we ever received. Unfortunately given its implications with the integration strategy, the patch entered a limbo where it remained stuck for more than a year. However, thanks to the support of SoundCloud (and the patience of Eloy) this feature has been released.

There are some caveats to keep in mind though:

Currently, dependencies can be scoped by configuration only by Pod rather than by individual subspecs.
All the resources are copied regardless of the build configurations.
The Acknowledgements files generated by CocoaPods include all the Pods regardless of whether they are scoped by build configuration.

Private spec repositories

Another feature which our users frequently ask for is the support for declaring spec repositories in the Podfile. With this change the Podfile becomes fully deterministic. This feature was kickstarted by François Benaiteau. Here is how it works:

source 'https://github.com/CocoaPods/Specs'
source 'https://github.com/Organization/Specs'

You might be wondering what happens when a repository is not already cloned on the user’s system. Well, wonder no more, because Samuel Giddins has taken this feature to the next level. If a repository is missing, CocoaPods will automatically clone it and it will even finely craft a suitable name.

To ease the transition, the pre 0.34 behaviour of implicitly including all the repos is still being supported, if no repo has been specified in the Podfile. However this logic as been deprecated, so this is a good time to adopt the new syntax in the Podfile.

Another thing to keep in mind is that the order of the repositories matter. CocoaPods will only consider the versions of a Pod available in the first repo where that Pod is available. Higher versions of a Pod specified in repositories declared after one including the Pod are not considered. This feature prevents a Pod switching to another repository by accident during an update because a new higher version has been introduced. This can be case with a private repo where the last version of a Pod available in the master repo is customised.

Faster downloads

97% of the Pods available in the master repo use a git source (6193 out of 6403 to be precise). We noticed this trend early on during the development of CocoaPods and we have adopted a cache for this download strategy. This solution worked reasonably well for users cycling a common pool of Pods and upgrading them. However, it had the disadvantage of incurring in a performance hit during the first clone of a Pod. This hit was dramatically stronger for repositories with a complex history.

Fortunately Marin Usalj come to the rescue and proposed to move away from the caching system in favour of shallow cloning git repos. The result? A faster experience and an even faster pod try.

Reorganisation of the Pods directory

The Pods directory has not been the pinnacle of human organisation. With the development of CocoaPods different artefacts have been added and the layout of the CocoaPods home has became a bit cluttered. We decided that the time to tidy up our room has come. However we couldn’t leave existing installations in the cold. So we have implemented a migration mechanism that completely automates the transition. This is the tree that we are aiming at:

Unfortunately during the release candidates we discovered that a non negligible number of Pods rely on the unsupported PODS_ROOT configuration setting instead of using the vendored_frameworks and the vendored_libraries attributes. To prevent issues we reverted the change which moved the sources of the Pods in the directory aptly named Sources – I know this name is pure art. However, this is a temporary band aid and Podspecs maintainers should update their specifications as soon as possible.

Foundation work

The support from SoundCloud and the Travis Foundation extended to a less visible but certainly not less important level.

Many of the CocoaPods dependencies have been cleaned up. Most of their issues have been solved. Code-base style and the coverage was taken care of. Solid dependencies means that the CocoaPods-Core team now can focus only in the last mile, especially in the integration strategies.

Another tiny, tiny, tiny, but very significant change is that now requires_arc defaults to true on Podspecs. This might look like the easiest patch ever (just one line of code) however it provides an insight on the real complexity of CocoaPods development: preserving existing installations… a.k.a backwards compatibility. So this innocent looking issue required to switch the entire specs repo to JSON (in order to safely edit all the specs programmatically) which in turn required to implement the trunk (in order to prevent the mater repo from becoming a Babel of different formats). Of course stating that those features stemmed from this issue is a stretch, but at least for me, their seed was planted there. I’m personally super happy to see it finally closed after more than two years. By the way, if you have a custom and private Podspecs I would recommend to check them to avoid any issue.

Updating

To install the last release of CocoaPods you can run:

$ [sudo] gem install cocoapods

Until version 1.0 we strongly encourage you to keep CocoaPods up-to-date.

For all the details, don’t miss the Changelog.

pod lib create v2

Thu, 26 Jun 2014 00:00:00 +0000

pod lib create has been our way of trying to encourage standards, and to make it easy to create a new library. Before today it would leave a lot of setup at the developer's discretion. The new version automates a lot of common problems away and starts you with a new library structure. Read on for details.

Or just go straight to the Using Pod Lib Create guide.

Rather than explain what it does, which the guide does a better job of, I want to show the end result:

You can edit your Podspec metadata, like the README and Library Podspec in Xcode.
There is an automatically generated project with your own Prefix settings.
Extremely easy to start writing library tests, we include stubs for Specta/Expecta and Kiwi.
Your library is set up as a Development Pod.
We include some useful Pods for bootstrapping your project.

This update is available today because of how Fabio built templates to allow for custom repos, and it definitely accepts pull requests and issues.

Pod Roulette Hackathon SF Summary

Thu, 12 Jun 2014 00:00:00 +0000

Last Saturday we ran the first CocoaPods hackathon with a great turn out especially considering post-WWDC tiredness.

We ran it based on Pod Roulette, and surprisingly most projects stayed true to the theme. We assigned each team three random Pods which needed to be used in their projects, adding additional Pods was fine, but you had to use each randomly assigned Pod in some fashion.

Here's what we ended up with:

StickyHeaderFlowLayoutFiltersSortDescriptorWilsonRank, dubbed the Instagram of beatboxing by @topwobble and team. Source on GitHub and Audio Snippet.
PullToRefreshPopperToolsImageDownloader, an Imgur Roulette app by @alexdaukrainian and team. Source on GitHub and Video.
InterfaCSSStatusBarBlurryTableViewController, a MultiPeerConnectivity enabled app by @orta and team. Source on GitHub. Orta also worked on an iOS 8 keyboard, for offering quick access to popular animated GIFs.
GtmHttpFetcherCoreLinkCocoa, an app for remote controlling a PJLink-enabled projector with your Pebble by @hbehrens and team. Source will be available after cleanup.

Apart from those fun projects, we even got some useful stuff as well:

@simjp worked on jazzy, a better way to generate documentation using Xcode's SourceKit!
@blakewatters released FMDBMigrationManager, a library for managing SQLite database schemas with FMDB.

Thanks a lot to Layer for hosting the event and graciously providing food and drinks!

Stripe's Open Source Retreat

Mon, 09 Jun 2014 00:00:00 +0000

Today, I am beyond excited to announce that I will be working full-time on CocoaPods this autumn, courtesy of Stripe's Open Source Retreat.

For three months, in addition to my normal work on CocoaPods, I will be working to write a reference implementation of an iterative dependency resolver that will be shared by CocoaPods and Bundler (and available to any developer that wants to use it). As part of the project, I will also be writing a language-agnostic test suite to help standardize behavior across different implementations of resolvers.

Ever since I first joined GitHub, I have dreamed about writing open source software for a living. Stripe is both making my dream a reality and truly supporting great open source work.

Since joining the CocoaPods Core team two months ago, I have set my eyes on the resolver. Right now, it has a 'naive' implementation: we just go through the dependencies list and pick the highest version that 'fits' with the current requirements. The right way to do this is to add automatic conflict resolution: when we run into a versioning conflict, we need to 'back up' and try another set of versions. This is a tough algorithmic problem, and exploring the best way to do it (both in terms of algorithm and architecture) has prevented us from tackling it before now. With this rewrite, we will be a giant leap closer to CocoaPods 1.0.

Come September, I will be in San Fransisco, taking a year off of university, working on CocoaPods full-time. This means I'll be working on even more issues, contributing more features, and hopefully writing a few interesting updates on my progress.

The entire CocoaPods team and I are incredibly grateful to Stripe for supporting our work and sharing our visions for the future of open-source.

Pod Roulette Hackathon - San Francisco - 7th June 2014

Sat, 31 May 2014 00:00:00 +0000

Have you heard of pod-roulette? If not, here's their elevator pitch:

Just moved to the big city, got a seed investment but don't have an idea what to do next?

Pod Roulette will find three random pods and prepare a project for you in a few seconds.

After seeing this project, we knew that there should be a hackathon using this.

And now there is: right after WWDC, on Saturday, June 7th 2014, we will meet at 10am and hack on our randomly determined projects until 5pm, then there will be presentations from 6pm to 7pm. Of course you can also come around and hack on something else, for example we can set you up with getting started to contribute to CocoaPods itself.

The hackathon will be hosted at Layer HQ, which can be reached by a short bus ride from Moscone. They will be graciously providing lunch, dinner and drinks - thanks!

Join our meetup group and RSVP online.

As always, don't be a jerk --> Code of Conduct

On Launching CocoaDocs Version 2

Mon, 26 May 2014 00:00:00 +0000

In March 2013 I uploaded the initial commit for CocoaDocs. This action triggered a roller-coaster year for me. I'm super excited to announce the second iteration of CocoaDocs is now running and parsing new Docsets.

Key Features List

Travis CI is now important
Documentation number of shame
Easy access to License info
Per library style settings
Programming Guides
Dash specific layouts

So it came to me as a surprise that CocoaDocs narrowly beats the CocoaPods Guides in terms of web traffic. It was the original point at which I (orta) had made a major contribution to the OSS community, and whilst it's great technically, it has always bothered me that I was constrained in the design. It bothered me enough that I started a redesign process for the entire of CocoaPods. Now I am free of this burden.

With the mostly solid foundations of CocoaDocs working, I was free to sit back and debate the wider reaching implications. CocoaDocs at its core is about best practices, adding documentation is an important part of a libraries lifecycle. I believe testing is another, because of how easy it is to get started with Travis CI and the fact that it is free for open source it is in my opinion a no-brainer to include that metadata in a library.

Getting started

I also felt that CocoaDocs was a black box for developers who didn't want to read the source code, which is basically everyone. So I've taken the liberty of creating a CocoaDocs Developer Docs. This is an area where you can preview your custom styling, and get the answers to a lot of the questions I've answer on twitter.

Coming up

This is not a full release of CocoaDocs 2, I'm waiting till post-WWDC 2014 to know whether the world has changed yet again to start the process of running CocoaDocs on over 15k libraries. During this time period new libraries get the new style, old libraries keep the old style. There are still a few open issues on CocoaDocs but there's time, we're at a solid 95% now.

CocoaDocs could not have existed without help from appledoc, Danger, the CocoaPods Dev Team and everyone who has contributed a library.

CocoaPods AltLabs - San Francisco - 5th June 2014

Fri, 23 May 2014 00:00:00 +0000

It's been a busy week, with the introduction of Trunk and CocoaPods 0.33. We're delighted to announce another event in San Francisco, this time it's AltLabs, a labs session dedicated to CocoaPods. Special thanks goes to AltConf for hosting the session.

The labs session will give you a perfect opportunity to come along and meet some of the team behind CocoaPods. We will be able to assist you on any issues you have with CocoaPods along with migrating your pods to the brand new trunk system. Our session will also allow you to get help setting up a development environment and making your first contribution to CocoaPods.

Since we have a lot going on during WWDC, I'm going to take this opportunity to give you a quick reminder of all the events we are hosting so you don't miss out:

Cocoa Kucha 4 (28th May 2014)
The CocoaPodsAlt State of the Union (2nd June 2014)
CocoaPods Labs (5th June 2014, 9am - noon)

The session will be hosted at Jillian's which is right across the street from both AltConf and Moscone West. So you have absolutely no excuse not to pop over if you are in San Francisco for either events.

Join our meetup group and RSVP online.

Code of Conduct

CocoaPods 0.33

Wed, 21 May 2014 00:00:00 +0000

TL;DR: CocoaPods 0.33 has been released. It is shiny and brings a huge change for our community… the support for CocoaPods Trunk.

New command line UI

The help banners of the command line have been tuned:

Each element now is consistently identified by a single colour. The highlighting is also performed in the descriptions of the commands to make them more readable.
The alignment of the various elements and of their description has been carefully crafted.
The descriptions and other bodies of text now are consistently wrapped to the width of the terminal (or to a maximum value to preserve readability for full screen windows).

There is still some debate about how to handle light backgrounds. So if you have a well-construed argument share your view on CocoaPods#2159.

Another interesting enhancement is the inclusion of a suggestion for unrecognised arguments, which makes typos much easier to catch.

Finally, a galore of minor tweaks have been implemented:

The naked pod command doesn’t default to pod install anymore because it presented an error if the Podfile was not found. This context dependant behaviour was not the experience we are looking for our new users.
The --version option is not available anymore in sub-commands and gained the ability of presenting the versions of the installed plugins if coupled with the --verbose option.

Command line completion

The --completion-script option has been implemented for the pod command. It prints a completion script for the current shell (currently only the Z shell is supported). The result is: faster than ever CocoaPoding:

We choose to generate a script because this approach is much faster than invoking the pod command line tool to provide the completions. Unfortunately this approach will not pick changes relate to the installation (or the removal) of plugins or changes due to CocoaPods updates.

If you are using a properly configured Z shell, you can install or update the completion script with the following commands:

$ rm -f /usr/local/share/zsh/site-functions/_pod
$ pod --completion-script > /usr/local/share/zsh/site-functions/_pod
$ exec zsh

cocoapods-trunk

CocoaPods trunk is the new way to share specs via the CocoaPods Master repo. If you haven’t heard about it yet, you can read the details about it in the dedicated blog post. For CocoaPods users it is relevant to know that the pod push command has been moved to pod repo push (a temporary alias has been provided) because since this version it is intended to be used for private repos. Moreover, to prevent users sharing accidentally private specs with world, the pod repo push command will abort if there is an attempt to push to a repo where the master repo as the remote.

During the development of trunk we discovered that some users are not properly leveraging private repos:

If you are using the master repo to add your own private specs, don’t do this.
If you are using the name ‘master’ for you own private spec-repo, don’t do this.

Things will break.

cocoapods-plugins

David Grandinetti and Olivier Halligon have been hard at work to tame the proliferation of plugins. The result is the extremely meta cocoapods-plugins plugin which can list, search and check the available versions of the most useful CocoaPods plugins. Moreover, Boris Bügling created a template (pod plugins create) so getting started has never been easier.

A great example of a new CocoaPods plugin is podroulette.

Updating

To install the last release of CocoaPods you can run:

$ [sudo] gem install cocoapods

Until version 1.0 we strongly encourage you to keep CocoaPods up-to-date.

For all the details, don’t miss the Changelog.

Claim Your Pods

Tue, 20 May 2014 15:38:00 +0100

Today we are introducing the ‘Trunk’ web-service. An awesome new way for podspec authors to submit their libraries to the master specs repository. For authors who have previously had push access the workflow should be very similar using the pod push subcommand. For more information on the ‘Trunk’ web-service itself, see the previous blog post.

Along with these changes we are adding a hierarchy of ownership to submitted podspecs. This way library maintainers will have complete control over submissions of their specs to the master repo.

Moving forward this ownership will be determined by the first user to submit a new spec. With existing podspecs, granting ownership will be a little more complicated.

Claim your Pod

Claim submission

For the next few days we will be taking applications from spec authors to claim their pods. This will set initial ownership for your libraries within the ‘Trunk’ web-service allowing you, and the people you allow, to push new specs for the given library. To do this we'll need you to fill out this form with the email address you would like use to identify with as an owner and the pod name you're claiming. Be sure to use the email address you use with Github so the commit logs will show your Github account.

Claim collisions

In the case that someone has already submitted a claim for the pod you are claiming we'll have to grant ownership differently. If you are one of many maintainers of the pod, it's likely that your co-maintainers have already gained ownership to the repo and can add you.

Co-maintainer access

If you maintain a spec along with a few other contributors you can all be added as owners to that spec. The initial owner can add other contributors through the command line interface.

Moving forward

We will take submissions for ownership until most specs have owners. We estimate this will take a week or so.

After this any new specs you submit will default to your ownership. In the future ownership claims will be handled by the CocoaPods dev team. One important side effect of this new workflow is how submitting pods will change besides just using the push command.

Currently many spec authors rely on Travis to validate the correctness of their new spec versions. We will no longer be using Travis for CI builds. When submitting a new version of your podspec the command line tool will run a local pod spec lint verifying the spec's validity locally.

After submitting a new version of a spec any revisions to that version must be submitted as a pull request to the master repo. Because of this I would recommend that you thoroughly test your spec with the linting tools and by using it in your real applications and/or demo applications to make sure everything works as expected. This is your responsibility from hereon out.

CocoaPods Trunk

Tue, 20 May 2014 15:37:00 +0100

After a year of architecture design and hard work, we are proud to introduce the ‘Trunk’ web-service, which will dramatically improve the user-experience of podspec publishers.

TL;DR We have good reasons for why and how we’re going to continue from here, but feel free to skip over the history lessons and straight to: ‘Trunk’, our solution.

The past and the why

Many have asked “why doesn’t CocoaPods have a simple way to publish new Pods, like RubyGems and NPM etc have?”, so let’s shine some light on that.

Arguably, configuring a black-box such as Xcode and getting native code to be compiled for various platforms, deployment targets, and architectures to build and the permutations thereof is way harder than what RubyGems, NPM, and the likes have to do. Obviously this is a huge benefit of scripting languages, which (often) do not need to deal with these seemingly arcane workflows.

So, back when I started work on CocoaPods, I did not want to spend much time on a centralised web-service yet if we didn’t even know all the details about our ‘core-business’ yet. Even if you can create a web-service “over a weekend”, that doesn’t mean it’s particularly helpful to the process of figuring out the hard parts, namely resolving, installing, and integrating your dependencies.

In fact, starting off with a web-service makes the whole process harder, because running a web-service means you now suddenly have to do maintenance on that, as the community will expect it to be up 100% of the time. And if there is one thing I have learned, then it’s that having this responsibility as a group of volunteers –doing a lot of this in their spare-time and for gratis– it is that inevitably there will be burn-out and/or the need to raise a lot of money due to possibly hard to maintain architectural decisions. (Examples of this are the amount of pressure on the RubyGems.org volunteers in the case of downtime etc and scalenpm.org in the case of needing large funds to maintain their infrastructure.)

I also wanted to design the architecture so that, for instance, companies that want to use their private dependencies through CocoaPods would not have to configure and host a web-service either. Nobody wants to do more than is necessary, not in the least because it just makes for a frustrating server-admin experience.

From these reasons stems the simple solution to host these in a simple directory structure and use established SCM systems to keep these versioned and simple to distribute. This strategy to keep things simple has served us rather well. However, at a certain scale, and especially in a Open-Source environment such as our ‘master’ spec-repo, there inevitably comes a time where you need to take it to the next level…

The problem

Our ‘master’ spec-repo boss, Sir Keith Smiley, is a review-and-merge-monster and has been able to keep-up with all of the pull-requests that you have been sending his way for the last two years. But, as we can clearly see the rising trend of number of Pods being published, at some point even Keith won’t be able to handle your scale.

Another issue we noticed is that the current workflow of creating a pull-request and automatically getting feedback from Travis in addition to manual reviews from Keith and Paul has lead to many podspec publishers being too ‘lazy’ and instead of properly testing whether or not a podspec will actually work well for a user by testing it in their own applications, they end-up updating and pushing their specs until it supposedly works. This is not only an abuse of the time our volunteers have, but it also shifts the responsibility to ensure proper working podspecs away from the publisher.

Other people in the community would like to create web-services around CocoaPods and for this they need some form of API and a format other than Ruby, to be able to interpret the podspecs and provide any meaningful service around them.

Finally, at some point, even the most well-intended person will slip up. A good example of this is when an unauthorised person pushed a podspec for an non-existing AFNetworking version. Obviously, the only person that should be allowed to do so is Mattt (the author of AFNetworking) and possibly other (maintainers) that Mattt gives his blessing to do so.

The solution? An automated web-service and a database of registered 'owners' with an ACL layer that only allows designated people to release new versions.

‘Trunk’, our solution

Cocoa Pods in varying levels of ripeness growing on the trunk of a tree. – Wikipedia

Today we are launching our web-service to remedy the aforementioned problems. The introduction of the ‘Trunk’ web-service means that publishers can now publish Pods directly from the command-line, without the need to create a pull-request.

The first person to publish a pod automatically gets designated as the ‘owner’ of that pod name in the scope of the ‘master’ spec-repo. The ‘owner’ can then add other ‘owners’ as they see fit. Only ‘owners’ are allowed to publish subsequent versions of said pod. For more information on this and interacting with ‘Trunk’ in general, see this guide.

Note that we are still hosting the canonical database of available Pods and their specifications in the same git repo on GitHub. This means that if something were to affect the uptime/stability of this database, our users can rely on GitHub’s professional and 24/7 support. Thus, if ‘Trunk’ were to go down, for whatever reason, our normal users are not affected and only ‘owners’ will be unable to publish new Pods during that time-frame. All in all, this means better stability for you, our users, and less stress on us, the volunteers. A simple overview of our architecture is shown in the following diagram:

With regards to ensuring that a podspec works properly, you, the ‘owner’, and only you are responsible for a podspec working properly. We only validate your podspec on our end for the bare-minimum meta-data that we need to be able to register your podspec. We will no longer validate your podspec for you on Travis. And we will not accept updates to published podspecs without a rigorous review process that is to be performed through a pull-request on the ‘master’ spec-repo. Thus, it is highly recommended that you test your podspec in your own real applications and/or demo applications before you publish a podspec.

Finally, the ‘Trunk’ web-service will no longer store the podspecs in the Ruby format. Instead these will be stored as JSON and thus will directly be usable by people wanting to create other web-services around the CocoaPods ecosystem.

Transition

While we transition to the ‘Trunk’ web-service, we will have a grace-period during which all the currently known Pods can be claimed by their respective ‘owners’. During this period pod trunk push will be disabled, until we are satisfied that the majority of the (important) Pods are claimed. Please read Keith’s blog post on this topic for more information on claiming your Pods.

Frequently Asked Questions

I’m getting a "[!] Push access is currently disabled." message, what’s wrong?

During the claims period, pod trunk push will be disabled. Please see the ‘Transition’ section.

Will I still be able to make modifications to a published podspec?

Once a podspec for a specific version of a pod is published, you won't be able to modify it. At least not in an automated fashion. The majority of update requests are a results of contributors not sufficiently testing their podspec beforehand. Generally what you want to do is to publish a new version for a pod, not edit an already published version in-place.

However, if you really fall into some exceptional case and really have to modify an already published podspec for a given version, you may still create a pull-request against the ‘master’ spec-repo; but we will not necessarily accept it and we do not offer any guarantees on turn-around time.

How can I distinguish the format of a podspec.

Podspecs using the Ruby DSL will use the .podspec extension, JSON based podspecs will use .podspec.json.

Will the specs in the Ruby format be deprecated?

No, they are here to stay and are the preferred method if you need to be able to perform automatic generation, such as collecting a list of all the source files from disk. The pod trunk push command will take care of converting the podspec to JSON. This means that you do not have to change any existing podspecs.

Will private repositories need to adopt the JSON format?

No. Moreover, the pod push command will keep the old behaviour, except that we are moving this into pod repo push to emphasise the distinction. Just keep in mind that if two files are available CocoaPods will prefer the JSON format.

Can I access the specs via HTTP?

Yes, you can use the following endpoints of the GitHub API. At a later point we will introduce a public API on ‘Trunk’ that you can use to standardise this, although it should be noted that if you do not need more than what the GitHub API already offers, it’s best to just use that, as GitHub will be able to offer better uptimes than we can.

To the get the list of the available Pods:

https://api.github.com/repos/CocoaPods/Specs/contents/Specs

To the get the available versions of a Pod:

https://api.github.com/repos/CocoaPods/Specs/contents/Specs/ObjectiveSugar

To fetch the podspec of a version of a Pod:

https://api.github.com/repos/CocoaPods/Specs/contents/Specs/ObjectiveSugar/0.9/ObjectiveSugar.podspec.json

Cocoa Kucha 4 - San Francisco - 28th May 2014

Fri, 02 May 2014 00:00:00 +0000

Orta has been kind enough to organise yet another Cocoa Kucha. This time he's pulled together an awesome collection of talented people based in San Francisco, along with a couple of visitors down for WWDC. Cocoa Kucha 4 is generously hosted by HipByte after their RubyMotion #inspect conference, which is just days before WWDC kicks-off.

Like with the other Kuchas, this meetup is in the style of Pecha Kucha where there are 8 speakers doing short talks related to Objective-C for 6 minutes and 20 seconds. The speaker must go though 20 slides, 20 seconds per slide. This keeps them to the point and makes it a lot easier for people to get started.

Speakers

I'm excited to share the list of speakers, which includes five members of the CocoaPods dev team:

Andy Arvanitis - @andyarvanitis
Delisa Mason - @kattrali
Kyle Fuller - @kylefuller
Leonard Grey - @speednoise
Marin Usalj - @_supermarin
Michele Titolo - @micheletitolo
Rebecca Goldman - @RebeccaGoldman
Sam Soffes - @soffes
Eloy Durán - @alloy

The event is hosted at Fort Mason after the first day of the #inspect conference. Join our meetup group and RSVP online.

Code of Conduct

CocoaPods 3rd WWDC Meetup: 2nd June 2014

Mon, 21 Apr 2014 00:00:00 +0000

Apple have their developers state of the union address. We have ours. We're working with the Alt Conference to have a great opening event to the WWDC week: The CocoaPodsAlt State of the Union. You should come along.

CocoaPods is a dependency manager for Objective-C, it makes it very easy for people to use open source code or to share code between multiple apps elegantly. It's become an annual tradition now for CocoaPods to host an event at WWDC, we want to make this another great one.

There will be a keynote by Orta Therox with both Eloy Durán and Fabio Pelosin skyping in to assist. We will go through some of the large changes that are happening behind the scenes in CocoaPods, show-off some new things and talk about future plans.

We will also have a large contingent of the CocoaPods dev team giving some talks on some of the work they've been doing around the community:

Boris Bügling - On learning Ruby by contributing to CocoaPods.
Marin Usalj
Michele Titolo - On Private Pods
Kyle Fuller - Creating your first Pod

We were planning on hosting it at 7:00pm and should be over by around 10:00pm, this should give everyone chance to then move on to some of the late night parties that will be happening around San Francisco. The meetup will be hosted at the Twilio offices, who are just a short walk away from the Moscone Center. They will be graciously providing both food & beer.

Join our meetup group and RSVP online.

Code of Conduct

CocoaPods 0.32

Tue, 15 Apr 2014 00:00:00 +0000

TL;DR: CocoaPod 0.32 is here! It brings a vastly improved update command and a galore of improvements. Including the ability to deprecate pods.

Update Command Improvements

Marius Rackwitz just added one of the most requested CocoaPods features:

pod repo update NAME

Exactly. Now you can scope your update to only one Pod.

This is not the only improvement to the update command, as Andrea Mazzini also took care of polishing the experience by adding to the installation output the version from which a Pod is being updated.

Development Pods

Now the file references in Xcode are absolute or relative depending on how they are specified in the Podfile. This feature was implemented by Samuel Ford

Deprecations

Another feature that we've received a lot of requests for is Pod deprecation. Thanks to the work of Paul Young this feature is already supported at the DSL level.

You can either specify whether a Pod is just deprecated:

spec.deprecated = true

Or whether it has been deprecated in favor of another Pod:

spec.deprecated_in_favor_of = 'NewMoreAwesomePod'

Unfortunately CocoaPods doesn’t display this information yet, but the super prolific Samuel E. Giddins is already on it.

Linter

The linter has seen a lot of activity and now is more aggressive than ever. Expect some great linting on the new Pods. Now it even checks the validity of screenshots.

Updated CocoaPods Feed

feeds.cocoapods.org now shows the latest new CocoaPods libraries released in the last few days. Consider it an alternative to the @CocoaPodsFeed twitter feed.

And off course we display the beautiful screenshots of the Pods (including gifs):

Updating

To install the last release of CocoaPods you can run:

$ [sudo] gem install cocoapods

Until version 1.0 we strongly encourage you to keep CocoaPods up-to-date.

For all the details, don’t miss the Changelog.

AppIe Acquires CocoaPods

Tue, 01 Apr 2014 00:00:00 +0000

Update: We hope you enjoyed our April Fools’ day prank! We are still an independent open-source project and fully committed to you, our users. In case it wasn’t completely clear to you, you may have thought that this post mentions a big well-known technology company, however, it in fact mentions ‘Appie’, which –with our sans-serif font– looks different when spelled with a capital ‘I’ ;) Appie is Eloy’s dog, we are not sure whether or not this prank was planned years ahead…

Big news, everybody! AppIe* has finally acquired CocoaPods.

After several months of discussions and meetings we are proud to finally be able to announce big news: CocoaPods has been acquired by AppIe for US$ 20 Million on the 1st of April, today.

CocoaPods @ AppIe

With one exception (see below), the existing CocoaPods Core Team will move to the AppIe Campus. We can't describe how excited we are to continue to improve giving you the best in pod-based dependency handling under AppIe's fold.

CocoaPods will become an extension to Xcode. For just $4.99 you get access to over 3000 existing pods, and this is a one-time purchase, valid forever.

What this means for you

We anticipate not everybody agreeing with our course of action. So here's what this move means for you, our most appreciated pod writers.

Existing pod owners will be remunerated via one of our generous plans: Bean, Pod, or Plantation (details on the sizes will follow). If you do not feel happy with one of our plans, please contact us privately, and we will be able to work out a deal that will benefit all parties.

Future Developments

We have several exciting plans for the future: Each pod will be able to charge a price and also offer in-pod purchases. It will also be possible to remotely remove a faulty pod from a client. We feel that this will enhance security and usability for our clients. Initially, we will charge a price for each uploaded version, but we are aiming to remove this by the middle of 2014.

Eloy Durán

Sadly, we have to add a bitter drop to this otherwise sweet nectar. While the CocoaPods core team stood as one behind this decision, founder Eloy Durán could not be persuaded to stay on board and was convinced to leave the OSS group he had founded, even after we offered him a generous severance package (in his own words): "Please accept this free license for life for CocoaPods."

We regret his decision but wish him all the best and good luck in future endeavours. We also hope that he can somehow support his idealistic lifestyle despite not recognizing great financial opportunities.

Update: RubyMotion has just announced Eloy's real reasons to leave CocoaPods. Read more about it in their tweet. We hope his boat will survive the move!

See you soon

The CocoaPods Core Team will be taking a few weeks off in Hawaii as part of this deal. See you on soon on an Xcode near you!

*Here's a company portrait of AppIe.

CocoaPods 0.31

Mon, 31 Mar 2014 00:00:00 +0000

TL;DR: The bug bash has been a massive success: all the tickets have been triaged at least once, almost 80 were closed, with 16 Pull Requests sent to fix or enhance CocoaPods. The result? CocoaPods 0.31!

The CocoaPods Bug Bash

  4 meetups world wide, 
  33 people, 
  16 pull requests, 
  6  claimed issues still being worked on, 
  86 issues confirmed as existing, 
  55 closed issues, and a total of 428 triage actions by participants.

We managed to raise the number of participants in the CocoaPods dev tools to over 170 contributors. With the top contributor Neonichu submitting 9 PRs, and still finding time to contribute to other projects during the weekend. Mind-blowing.

Things new to CocoaPods

Laurent Sansonetti Ordered the output of pods correctly when versions went over two digits in the pod spec commands.
Richard Lee made linter checks if your homepage works so you won't accidentally link to the wrong place, on top of that he made sure that when running pod install on Travis CI it runs with the right shell encoding.
Robert Zuber wrapped up Stefan Damm's PR to include the versions of the Pods to the output of pod list.
Marc Boquet Unset the CDPATH env variable before shelling-out to prepare_command.

The most important fix

Resolve crash related to the I18n deprecation warning.
Eloy Durán #1950

For all the other fixes, check the Changelog.

Updating

To install the last release of CocoaPods you can run:

$ [sudo] gem install cocoapods

Until version 1.0 we strongly encourage you to keep CocoaPods up to date.

For all the details, don't miss the Changelog.

CocoaPods 0.30

Sat, 29 Mar 2014 00:00:00 +0000

TL;DR: CocoaPods 0.30 dramatically reduces setup time & download size, introduces compatibility adjustments for Xcode 5.1 and the Rainforest!

Smarter Setup

Sometimes the small changes have the biggest impact. Folks with slow interwebs, rejoice! Because this patch contributed by Jeff Verkoeyen will prevent the download of the history of the master repo during setup and consequently will dramatically reduce the download size (from >200MB to roughly 3.5MB). Nippy.

Xcode 5.1

Finally we can say bye bye (at least until the next update of Xcode) to that pesky warning about updating the build settings of the Pods thanks to Romans Karpelcevs. Additionally, the file references of frameworks have been fixed to work on Xcode 5.1.

Rainforest

If you are a CocoaPods contributor or if you plan to hack on it, this new repo will definitely interest you. Rainforest is the home of CocoaPods development and makes setup of the CocoaPods dependencies as it should have always been: super simple!

$ git clone https://github.com/CocoaPods/Rainforest.git
$ cd Rainforest
$ rake bootstrap
$ rake local_dependencies_set
$ CocoaPods/bin/pod --version
0.30.0

And now lets experiment with some real hacking:

$ sed -i '' 's/UI.puts VERSION/UI.puts "#{VERSION} Hacked!"/' CocoaPods/lib/cocoapods/command.rb
$ CocoaPods/bin/pod --version
0.30.0 Hacked!

Whoah!

Other Improvements

This release is decorated with minor touches all around the way, from word wrapping help banners to the terminal width to saving in the Podfile the name of the project in pod init.

Mike Walker improved robustness against spaces and quotes in paths.
banjun added support to ignore SVN externals.
Kyle Fuller added support for the docset_url attribute.
Piet Brauer added the support for the specification of a template URL for the pod lib create command.
Carson McDonald had been on fire and added a bunch of missing tests – let me sneak in a personal thanks to him – to CocoaPods.

Updating

To install the last release of CocoaPods you can run:

$ [sudo] gem install cocoapods

Until version 1.0 we strongly encourage you to keep CocoaPods up to date.

For all the details, don't miss the Changelog.

CocoaPods Bug Bash

Fri, 14 Mar 2014 00:00:00 +0000

With the announcement that Fabio will be working full time on CocoaPods (thanks SoundCloud!) for three months, we looked for ways to get the most bang for our buck on his time. In true Open Source style we looked at ways of getting people to help out cleaning out the GitHub issues.

We then looked for interesting incentives, and we have some compelling icing on the proverbial cake.

The Plan

We want to clean up our issues, remove duplicates, improve the writing and make them easily reproducible.

Fixing issues themselves would be lovely, but it's not the focus. This means you don't have to know a lot of ruby, but more apply general debugging skills to the problem.

How will it work?

On the last weekend of March, the 29th / 30th we will be in the CocoaPods IRC channel ( chat.freenode.net#cocoapods ) offering help to people. There will be an IRC bot that will assign people random CocoaPods GitHub issues when they request them, they then can triage it. We will then generate a leaderboard from the number of issues dealt with and give out some prizes at the end. This is a great opportunity to give back to the CocoaPods project and to say hi to the authors and other Objective-C developers in the chat room.

You mentioned prizes?

Well, we reached out to some of the great indie dev tool makers - tools I use everyday - asking if they would be kind enough to donate a license or two. We'll be able to give out licenses for the top contributors for the following apps:

AppCode - The alternative Objective-C IDE.
Bee - Mac issue tracker supporting GitHub Issues, FogBugz and JIRA.
Dash - Instantly access developer documentation.
GIFBrewery - The best tool for converting MP4 to .gif.
Reveal - The best way to explore the iOS view hierarchy.
RubyMotion - An awesome toolchain that lets you quickly develop and test iOS and OS X using Ruby.

Guides and Blog Deploys with Travis-CI

Mon, 10 Mar 2014 00:00:00 +0000

TL;DR Both the Guides and Blog now auto-deploy when we push to master.

We are always looking for ways to make contributing to CocoaPods easier, and a quick win for us is auto-deploying the guides and blog. Now any member of the team can accept a PR, and Travis will deploy the changes within minutes.

Scripts

Travis needs instructions on how to build this code. While you can add all of those commands to the Travis config directly, that is difficult to debug and removes the ability to manually setup and deploy.

Every CocoaPods repository has a rake bootstrap command to ensure the environment is setup, and every site has a rake deploy command. Taking the time to set these up in the past made it incredibly easy to integrate this process with Travis.

Pushing to Github Pages with Travis

Setting up these two repositories to push to Github pages was pretty trivial, once I figured out the correct steps.

1. Travis needs to be a user

Since Travis needs to push to Github, it needs a user. Pick or create a user, and get a Personal Access Token. This token is generated in Account Settings on Github. We chose to use the CocoaPods Bot account.

2. Authenticate with that user

In order to identify as this user, Travis needs credentials. I chose to encrypt the user information using the travis gem. I ran the command below from within the project directory with the add flag so it automatically adds the encrypted output to the .travis.yml

travis encrypt 'GIT_NAME="Account Name" GIT_EMAIL=example@example.com GH_TOKEN=SOMEREALLYLONGSTRING' --add

3. Setup and Deploy

Travis build on a completely fresh checkout, so setting up the environment is key. Thankfully both sites had the rake bootstrap command, so I was able to reuse that.

The deploy script turned out to be the tricky part. The important step here is to make sure the deploy script relies upon the git remote that's setup. All of our static sites have a rake deploy command, which I modified to remove the hardcoding of the remote.

4. travis.yml

Configure git settings in .travis.yml. By default, Travis doesn't have a user, so you should set the user.email and user.name to push with. These should match the credentials you encrypted with the token.

install:
- git config --global user.email "bots@cocoapods.org"
- git config --global user.name "CocoaPods Bot"

5. Updating the remote

In this setup, Travis doesn't have ssh access to the repository. Change the git remote to point to https with your token attached. The token is used to authenticate the push. Here's what the Blog setup looks like:

git remote set-url origin "https://${GH_TOKEN}@github.com/CocoaPods/blog.cocoapods.org.git"

6. Turn on Travis builds

This is done from Settings. Also, since this is a deploying build, make sure that you do not build when pull requests are made.

7. Commit and push your changes.

Hopefully everything will work. If not, you can make more changes, push, and wait for Travis to build.

The .travis.yml

language: ruby
branches:
  only:
  - master
rvm:
- 2.0.0
install:
- git config --global user.email "bots@cocoapods.org"
- git config --global user.name "CocoaPods Bot"
- rake bootstrap
script:
- git remote set-url origin "https://${GH_TOKEN}@github.com/CocoaPods/blog.cocoapods.org.git"
- rake deploy
env:
  global:
    secure: XXXX

In Conclusion

So that's how we have our Travis deploys setup now. CocoaPods is a community effort, so lowering the barrier for contributions has been one of our goals. This new setup does just that. Edit away!

SoundCloud Announcement

Sat, 08 Mar 2014 00:00:00 +0000

Today at the mdevcon conference we have been glad to announce that SoundCloud in collaboration with the Travis Foundation will sponsor CocoaPods development.

Photo by Luis Ascorbe

In the words of SoundCloud's Developer Evangelist Erik Michaels-Ober:

Our iOS team uses CocoaPods every day to manage the dependencies of our mobile apps. We hope that will lead to improvements that benefit the entire Mac and iOS developer ecosystem.

This means that I will be able to work full-time on CocoaPods for 3 months. I'm very excited by this and I plan to release at least one major feature each month. In addition I will take advantage of this great opportunity to iron out minor issues and refactor parts of our core, to ensure a solid basis going forward.

As requirements always change I won't go into specifics about them at this moment. However, as work progresses I will keep you up-to-date with blog posts about the specific features. We think you will like them!

Eloy and I are very thankful to SoundCloud, Travis, and the great people there that share our passion and for helping us to help you.

Search API Version 1

Sun, 02 Feb 2014 00:00:00 +0000

I'm going to break up the doom & gloom around the Specs Repo change with some good news. We have opened up v1 of our search API!

This is the API used in CocoaPods.org and soon on CocoaDocs. Read on to find out how to use it in your own applications, I'm really excited to see what people do with it.

API Description

Pods Endpoint

http://search.cocoapods.org/api/pods

Query String Parameters

query:    The query string.
amount:   The number of results requested [Default: 20].
start-at: The offset in the set of results [Default: 0].

Example

http://search.cocoapods.org/api/pods?query=test&amount=100&start-at=50

What query string do I use?

The query string you use is what you type into the search engine on CocoaPods.org. In addition, you can filter on either or both platforms by prefixing the query string with on:ios, on:osx, or on:ios on:osx (we hide this behind the four radio buttons).

For example, if you'd like to only see "test" pods that run on iOS then you prefix the query string with on:ios:

curl 'http://search.cocoapods.org/api/pods?query=on:ios%20test'

Formats

We return 4 different formats, all in JSON:

Picky-style results with pod data as hashes.
Picky-style results of pod names as string.
Flat list of results with pod data as hashes.
Flat list of results of pod names as string.

What format you'd like you need to provide via the Accept header. The 4 options above translate into:

Accept: application/vnd.cocoapods.org+picky.hash.json; version=1
Accept: application/vnd.cocoapods.org+picky.ids.json; version=1
Accept: application/vnd.cocoapods.org+flat.hash.json; version=1
Accept: application/vnd.cocoapods.org+flat.ids.json; version=1

Defaults

You don't have to provide all the details. For example, providing no version will return the latest version. We recommend that you always provide the version nonetheless.

See a list of all specs. All of these parameters will return a result.

The default format is Picky-style results with pod information as a hash.

Examples

Formats

curl 'http://search.cocoapods.org/api/pods?query=name:kiwi' \
  -H "Accept: application/vnd.cocoapods.org+picky.hash.json; version=1"

curl 'http://search.cocoapods.org/api/pods?query=name:kiwi' \
  -H "Accept: application/vnd.cocoapods.org+picky.ids.json; version=1"

curl 'http://search.cocoapods.org/api/pods?query=name:kiwi' \
  -H "Accept: application/vnd.cocoapods.org+flat.hash.json; version=1"

curl 'http://search.cocoapods.org/api/pods?query=name:kiwi' \
  -H "Accept: application/vnd.cocoapods.org+flat.ids.json; version=1"

Query Params

curl 'http://search.cocoapods.org/api/pods?query=name:test' \
  -H "Accept: application/vnd.cocoapods.org+flat.ids.json"

curl 'http://search.cocoapods.org/api/pods?query=name:test&start-at=3' \
  -H "Accept: application/vnd.cocoapods.org+flat.ids.json"

curl 'http://search.cocoapods.org/api/pods?query=s&amount=1000' \
  -H "Accept: application/vnd.cocoapods.org+flat.ids.json"

Convenience Endpoints

It's not always convenient to use curl on the command line and type the Accept header. So we also offer 4 further endpoints, for quick result viewing in a browser.

http://search.cocoapods.org/api/v1/pods.picky.hash.json?query=test
http://search.cocoapods.org/api/v1/pods.picky.ids.json?query=test
http://search.cocoapods.org/api/v1/pods.flat.hash.json?query=test
http://search.cocoapods.org/api/v1/pods.flat.ids.json?query=test

Caveats

As we improve the search engine, it might be down for half a minute at a time, sporadically. Please allow for this eventuality in any user interfaces.

Have fun with it - we are curious what you all are coming up with! Personally, I'd love a CocoaPod that parsed Picky-style results and provided it to other applications <3

Cocoa Komittee - NYC

Sat, 01 Feb 2014 00:00:00 +0000

One should avoid repeating oneself. New York City is where we started running Cocoa Kuchas last year and whilst there's a lot more stories to tell here it's time to move on.

This month we will be hosting a panel on iOS Testing. Find out more inside.

The Komittee is an event where we will take people with strong opinions, and get them started on a contentious topic and see if we can learn something from the process. Testing in general is a hot topic. Mix that with a tight platform, closed tools and you've got a lot of flames.

Details

We are graciously being hosted by Spotify, at their NYC HQ on the 25th of February at 7pm.

Topics

QA vs Automated Unit testing
Testing units of code vs Testing behavior
Obj-C implementation strategies vs other ecosystems
Time management
Ways to improve testing for everyone

The Panel

db - @dblockdotorg
Benjamin Jackson - @benjaminjackson
Mike Lazer-Walker - @lazerwalker
Klaas Pieter - @klaaspieter
Paul Young - @py
Brian Gerstle - @b_gerstle
Landon J Fuller - @landonfuller

Meetup Page

Here

Show notes

Landon Fuller

Unit Testing

OCUnit for projects supporting <= iOS 6, and <= Mac OS X 10.7

XCTest for projects supporting >= iOS 7, >= Mac OS X 10.8
Continual Integration

Jenkins: http://jenkins-ci.org/

Confluence: https://www.atlassian.com/software/bamboo/

Paul Young

Frameworks

Specta

Expecta - https://github.com/specta/expecta
OCMockito - https://github.com/jonreid/OCMockito

I used to use OCMock but had hang ups because:

It reports test failures by raising exceptions (not useful enough, weird output, can’t click and go to the test failure). Klaas mentions this in his article linked.

Expectations aren’t cleared when you call `stopMocking` which means you can’t use a setup step/beforeEach block to make your spec DRY. “Partial" mocks allowed me to mock part of the subject under test which seems wrong. OCMockito doesn’t allow this.
Tools

Rake - a la AFNetworking https://github.com/AFNetworking/AFNetworking/blob/master/Rakefile

XCTool - although having an issue currently: https://github.com/facebook/xctool/issues/314

Travis - followed this article: http://www.objc.io/issue-6/travis-ci.html but there were a few gotchas:

Travis devs forgot to add CocoaPods to the VM so you have to install the gem in your before_script phase. It works but makes the build take a lot longer. You can make it quicker by not installing the docs for the gem. https://github.com/travis-ci/travis-ci/issues/1657

Travis devs forgot to set some of the environment variables: https://github.com/travis-ci/travis-ci/issues/1769

Hockey - http://hockeyapp.net/features/ - The apps are pretty good: http://hockeyapp.net/apps/

I followed the objc.io article to push from Travis to Hockey on a successful build in master. Thinking about seeing if Shenzhen (https://github.com/nomad/shenzhen) by Matt Thompson is a better long term solution.

Klaas Pieter Annema

I use Specta, Expecta and OCMockito. I've also been using Barista for integration tests. Everything is automatically run on Travis. Tools I use: Cocoapods, Bundler (so I can have a specific Cocoapoads version per project), Rake and xctool.

Repairing Our Broken Specs Repository

Thu, 30 Jan 2014 00:00:00 +0000

Note: If you got this problem after running gem update, jump here to find a solution.

Unfortunately we've encountered a bug in libgit2 and we are going to have to force push into the Specs repository. (Also known as the ‘master’ spec repo.)

What does this mean for you?

Well, basically your CocoaPods setup is going to break. You are going to have to manually delete any local copies of the Specs repository and re-clone the new version of the Specs repository. You can do that with the following commands:


    $ sudo rm -fr ~/.cocoapods/repos/master
    $ pod setup

NOTE 1: If you have any local commits or changes to the Specs repository which are not merged, you should ensure you have a copy of them. I would recommend that you manually copy these changes over and re-commit them. You can fix your repository without deleting, however, this is not a simple process, so we are instead recommending that you delete your copy of the Specs repository and any forks of it.

NOTE 2: In case you are storing private podspecs in your clone of the Specs repository or you have a private spec repo that was forked from the Specs repository, this is a great time to clean that up by using private spec repositories The Proper Way. This way your private spec repository should never be affected by issues in other spec repositories.

If you really know what you’re doing and don’t want to re-download the complete repo, follow these instructions.

Why did this break?

The Specs repository has unfortunately broken due to a bug in libgit2 which powers GitHub's web editor. This has caused our git repository to become corrupt:

As fsck noted, it has duplicate entries, which is a violation of Git's object format. GitHub check objects as they are pushed into each fork; anyone who has built on top of the broken tree will have their push rejected, as they are trying to bring the broken object into their fork (as a result of it being reachable from their new commits).

We are looking into how this broken object got into the repository in the first place. At this point it looks like a web-edit […], that was then merged on the site via a pull request ([…] it looks like a bug in GitHub rather than any kind of user error). We're looking both into fixing the bug, but also into giving better protection to broken objects entering the repository (i.e. this is the exact sort of problem that the fsck-on-push checks are there to prevent, but they do not currently extend to web edits).

The only solution is to rewrite the history of the repository and force push the rewritten tree. Rolling out this fix basically means that all copies of the repository have to be reset. This can be a delicate process, so deleting and re-cloning is the safest and simplest way to do so.

Will this happen again?

There is a fix in the works to fix the bug in libgit2. This fixes a bug which would prevent libgit2 from corrupting a repository in this particular case.

GitHub are also working on putting checking measures in-place on the web-editor so that it wouldn't be possible to save a corrupt repository, and to prevent any similar problems in the future. (As is already the case when using git-push, which runs git-fsck on GitHub’s end.)

Acknowledgements

We would like to thoroughly thank the following people for their help in both investigating and resolving this matter. It is very much appreciated by all of us at CocoaPods HQ and shows the power of a (larger) community of people coming together.

Jeff King (@peff)
Roberto Tyley (@rtyley)
Abizer Nasir (@Abizern)

We are very sorry for all time this issue takes away from our great early adopters and pod providers. We are very thankful for your patience and understanding while we work towards a smoothly functioning version 1 of CocoaPods and its architecture.

I got linked here after updating my gems, what to do?

This issue is being tracked down to an issue located in Psych. To fix it please use the following command:

rm -fr ~/Library/Caches/CocoaPods && \
gem update --system && \
gem update && \
gem cleanup && \
pod setup

Now instead of seeing this:

Setting up CocoaPods master repo
Already up-to-date.
[!] There was an error reading '/Users/xxxxx/.cocoapods/repos/master/CocoaPods-version.yml'.
Please consult http://blog.cocoapods.org/Repairing-Our-Broken-Specs-Repository/ for more information.

You'll see this:

Setting up CocoaPods master repo
Setup completed

You can find more information related to this issue here and here

– @kylefuller, @SmileyKeith, and @alloy

Cocoa Kucha 3 - Berlin - 22nd Jan 2014

Tue, 07 Jan 2014 00:00:00 +0000

And just like that the next Cocoa Kucha was declared. As part of a world-wide community outreach program I've been in talks with Chris Eidhof and Engin Kurutepe about running a Cocoa Kucha with the CocoaHeads Berlin.

As the timeframe for the event is smaller than I normally plan, I'd like to open the doors to speakers. We accept pull requests including yourself on the roster. Like most CocoaHead Berlin events is hosted at CodeKollektiv and starts at 19h. Add it to your kalendar.

Currently confirmed for the 22nd:

Claudiu-Vlad Ursache - @ursachec - About his work on Tor on iOS.
Robb Böhnke - @ceterum_censeo - What's coming in Mantle 2.0
Wojtek Czekalski [voy•tech check•all•ski] - @wczekalski - I have created a popular open source project. And I hate it.
Florian Hanke - @hanke
Boris Bügling - @NeoNacho - Xcode plugins
Jens Ravens - @JensRavens - Meteor, Realtime APIs and CoreData

Florian Hanke is one of the CocoaPods Dev team, he is the man responsible for the search API and has been collaborating with me on all aspects on the website. I'm really excited to both meet him for the first time & see him talk.

You can keep up to date by either watching my organization issue, or by keeping track on the CocoaHeads google group.

CocoaPods 0.29

Tue, 24 Dec 2013 00:00:00 +0000

TL;DR: CocoaPods 0.29 introduces the pod try subcommand, the social media URL podspec attribute & complete inhibition of header warnings.

Every now and then we hear about tiny yet huge feature requests for CocoaPods. Pod try is one of these. Suggested by Laurent Sansonetti, pod try quickly gained a spot among the features of CocoaPods that I love the most. But… What is it?

Pod Try

Pod try is a new subcommand which allows you to quickly launch the demo project of a Pod. It can be used to assess the quality of a library – very useful for user interface elements – or to quickly get up to speed on how to use it.

In other words the command automates the following steps:

Checkout the source of the Pod in a temporary directory.
Search for any project looking like a demo project using some simple heuristics.
Install any CocoaPods dependencies if needed by the located project.
Open the workspace/project in Xcode.

To check it out just update to the last release of CocoaPods and run:

$ pod try FLKAutoLayout

It is new, so we'd like feedback as issues on the repo please.

As you might know, the @CocoaPodsFeed account posts notifications about new Pods. We have been aware from a long time that some users replied to those tweets and that the conversation, as the tweets are generated by an automatic service, was unfortunately lost. When it was suggested to include the Twitter handle of the author of the Pod in the feed we decided to take action.

Identifying a solution was not easy because on the one hand we didn't want to include a DSL attribute dedicated to a proprietary platform like Twitter; on the other hand, we recognized that Twitter was a very convenient channel for discussing Open Source Projects. After discussing for 75 minutes we managed to come up with a solution which was able to satisfy our requirements: the social media URL. Instead of asking to specify a Twitter handle we opted to ask for an URL.

spec.social_media_url = 'https://twitter.com/cocoapods'

When we generate the Tweet for a new Pod we just check if the social media URL includes the twitter.com domain and in that case we include the handle in the tweet (shortening the description of the Pod if needed). We expect this feature to improve the visibility of Pods authors and increase the engagement with their libraries. The result is the following:

[AOCUDL by @hypercrypt] An alternative shorthand syntax to Dustin Bachrach's OCUDL. http://t.co/HURVc1080e
— CocoaPods New Pods (@CocoaPodsFeed) December 8, 2013

Header warnings

Another great feature in this release is the ability to completely silence header warnings.

This feature was contributed by the new core team member swizzlr

Bug fixes

Bug fixes might not be the best argument to read about – unless they are affecting you – but definitely are the foundation of solid software. Luckily we got our bases covered thanks to Joshua Kalpin who appears to be on a streak! Among the many fixes the one related to the pod lib lint subcommand deserves a quick mention.

Updating

To install the last release of CocoaPods you can run:

$ [sudo] gem install cocoapods

Until version 1.0 we strongly encourage you to keep CocoaPods up to date.

For all the details, don't miss the Changelog.

Cocoa Kucha 2 - 16 Jan 2014

Tue, 17 Dec 2013 00:00:00 +0000

Cocoa Kucha is back, this time in London on the 16th of January. I'm excited to announce that Fabio Pelosin is going to make an apperance. Fabio is the biggest contributor to CocoaPods with well over 3000 commits across the various repositories. Along with Fabio, both Orta Therox and myself will be there. Orta has organised this event, and it's kindly hosted by Daniel Haight from NSLondon.

Like last time, this meetup is in the style of Pecha Kucha where there are 8 speakers doing short talks related to Objective-C for 6 minutes and 20 seconds. The speaker must go though 20 slides, 20 seconds per slide.

There is a great line up of speakers for the upcoming Cocoa Kucha, ranging from the author of SBJson, Stig Brautaset to Damien DeVille, a software engineer at the ever popular Realmac Software.

Currently confirmed for the 16th

Alex Rozanski - @alexrozanski
Damien DeVille - @DamienDeVille
Fabio Pelosin - @fabiopelosin
James Addyman - @jasarien
Luca Bernardi - @luka_bernardi
Rolandas Razma - @rolandas_razma
Stig Brautaset - @stigbra
Sally Shepard - @mostgood

You can join the NSLondon meetup group to keep up to date, and the event will allow RSVPs 2 weeks before on the 2nd of January.

Cool URIs don't change.

Mon, 02 Dec 2013 00:00:00 +0000

TL;DR: We broke some URIs but this is how we ensure people still get the info they were looking for.

To try and simplify where you can find CocoaPods documentation we deprecated docs.cocoapods.org in favour of guides.cocoapods.org and there will be further subsites with different focuses. To ensure a smooth transition I built a small sinatra app that might be of use to other people.

Whilst not entirely living up to the W3C dream of the content changing but the URI not changing I felt a system of smart HTTP 302 permanent redirects would work quite elegantly for our system. Previously we had a static site that was held on github pages, this meant we had no ability to do true redirects, only HTMLs property <meta http-equiv="refresh">. This is a sledgehammer approach to redirects and we wanted to use a smaller tool.

So I brought out ruby, the language CocoaPods is built in and created a small app using sinatra that can be used to make a map of URLs to redirect to. Luckily there were not that many pages in the docs and we had equivilent pages in the guides. This is then turned into a heroku app and made to be the new docs.cocoapods.org silently redirecting people to the new website with the same information they were looking for.

require 'sinatra'

NEW_URL = "http://guides.cocoapods.org"
ROUTES = {
  "/" => "/",

  # References
  "/podfile.html" => "/syntax/podfile.html",
  "/specification.html"=> "/syntax/podspec.html",
  "/commands.html"=> "/terminal/commands.html",

  # Guides
  "/guides/philosophy.html"=> "/using/faq.html",
  "/guides/installing_cocoapods.html" => "/using/getting-started.html",
  "/guides/dependency_versioning.html" => "/using/the-podfile.html",
  "/guides/closed_source_pods.html" => "/making/private-cocoapods.html",
  "/guides/working_with_teams.html" => "/making/private-cocoapods.html",
  "/guides/contributing_to_the_master_repo.html" => "/making/specs-and-specs-repo.html",
  "/guides/creating_and_maintaining_a_pod.html" => "/making/specs-and-specs-repo.html#how-do-i-update-an-existing-pod?",
  "/guides/creating_your_own_repository.html" => "/making/private-cocoapods.html",

  # Gem specifics should be handled by rubydoc 
  "/cocoapods/*" => "http://rubydoc.info/gems/cocoapods",
  "/cocoapods_core/*" => "http://rubydoc.info/gems/cocoapods-core",
  "/xcodeproj/*" => "http://rubydoc.info/gems/xcodeproj",
  "/claide/*" => "http://rubydoc.info/gems/claide",
  "/cocoapods_downloader/*" => "http://rubydoc.info/gems/cocoapods-downloader"
}

ROUTES.each_key do |key|

  # Create a sinatra route for each key, check if it's value starts with http
  # and either redirect to the new site with the same query.

   get key do
     if (ROUTES[key][0..3] == "http") 
       redirect ROUTES[key], 302
     else
       url = NEW_URL + ROUTES[key] + request.query_string
      redirect url, 302
     end
   end
 end 

 # If we've missed anything just go to the root of the new URL

 error Sinatra::NotFound do
   redirect NEW_URL + request.query_string
 end

The repo can be found here github.com/orta/CocoaPods-Docs-Redirector/

CocoaPods Beta

Sun, 24 Nov 2013 00:00:00 +0000

TL;DR: CocoaPods just got a facelift.

Interested in finding the CocoaPods Logo? Check out our Media Pack.

I believe design is important. CocoaPods is probably the most public facing Objective-C project. Applying design to open source projects is a sign of maturity, and of stability. Whilst we're still not 1.0 yet, having a cohesive brand is a step towards that.

This post documents some of the work involved in making the new CocoaPods web properties.

The CocoaPods devs welcomed me with open arms after I started regularly contributing via the Specs repo, and encouraged by their work I started a project called CocoaDocs. Once it became quite obvious that CocoaDocs was going to be an important part of the CocoaPods ecosystem I branded it with the CocoaPods styling, and it was treated as a sister project.

Around the same time we were seeing issues with documentation, it was user contributed and spread out among the cocoapods website and a collection of wikis, so Michele Titolo & I started to mock out the guides structure and Michele started collating documents and creating a single source for the markdown files.

Andy and I went back and forth on logos for a few months until we came up with the version shown in the top left and in this blog post announcing the new blog. Andy (quite correctly) believed that we couldn't just announce a logo without showing it in context, that meant re-thinking the homepage. I spent some time with Florian Hanke digging into the site analytics to try and get an understanding how people were using the current website. Turns out everyone is using it to search for Pods. Who'd have thought?

So that gave us a direction for what the site should orient itself towards. We knew that search should be a high priority, and that a lot of the documentation should move into a guide leaving a lot more breathing space in the homepage. The new design was worked on in secret until we felt there was enough context around the branding. You can't re-think something this big in a weekend, and showing incremental work isn't always the best option when you are making drastic moves. Luckily Eloy Durán & Fabio Pelosin trusted that we knew what we were doing when I said that the old CocoaPod illustration will have to go.

With buy-in from the rest of the team, and some helpful tips we all discussed the scope of the changes. We'd have to break the current website into 3 separate projects, sharing assets, design and code as much as possible. This meant we could incrementally build the sites as staticly generated content and upload it to github. It was an easy sell that we needed a blog, and it was an easy sell that we should split out the CocoaPods twitter into one specifically for new Pods. The blog meant we could wax lyrical about new releases, keep people up to date and have a sense of permenance in the CocoaPods team voice. Keith Smiley started building the blog the moment it had some mockups. Setting up a shared repo for all our assets and design notes.

Fabio & I announced the redesign at NSSpain. We had stickers. It went well.

Building this blog gave us chance to start dealing with some of the navigation issues that just aren't obvious during design stage. Andy & I iterated quickly on design and implementation. We used Bootstrap 3 to build the sites and I'm definitely a fan of the system. Everyone on the CocoaPods team took an OSS break for iOS7. Our developers chat room was a desert for a while. Once that hurdle had been jumped a few of us got started thinking about full fleshing the guides out.

The guides were an interesting navigation problem, we knew roughly the overall structure and a lot of the problems came in dealing with heirarchy and ensuring consistency in the documentation. It took one sentence from Artsy's head designer Robert Lenne and the index page was figured out.

During this period Florian started work on the API changes required for the new site, as it was to be a static site meaning we can dogfood our now 2 year old API. We've started work on splitting the API out into it's own project to accomodate the ideas Andy & I wanted for the search experience. Florian has done an amazing job on the feel of the search interface, and it is super fast. We just worked off and on over the course of a few weeks together on the cocoapods.org domain until it felt right.

There's still a bunch of work to be done, like the about page, and some more work on mobile, design tweaks, but overall the experience is definitely a step forwards. We've had a lot of help from everyone in the core team, and people who have taken the time to discuss ideas with me and the rest of the team. This is one step of many, and it will probably be a while before we remove that beta in the top corner. In true open source style we take both pull requests and issues, and as much of the content has a button to go directly to the source to submit changes.

Let us know what you think either on twitter (@CocoaPods) or if your idea is too big for 140 characters, write us an issue. This was a team effort, and I'm super proud to have been a part of it. !m!

CocoaPods 0.28

Thu, 14 Nov 2013 00:00:00 +0000

TL;DR: CocoaPods 0.28 introduces support for plugins.

Fighting feature creep in CocoaPods is not easy. We hear about a lot of great ideas and many of them don't make the cut as they would not be useful for at least 80% of our users. The ideal solution would be support for third-party plugins and, luckily, an elegant and lean patch from Les Hill has introduced it.

Plugin support allows one to tweak the internals of CocoaPods and to insert additional commands. As a matter of fact, two new commands are available right from the start:

The discoverability of plugins is another important topic that we considered. Our solution is to adopt a non-enforced convention: plugins should be named after the cocoapods-PLUGIN_NAME format. In this way, to check for the available plugins, you can just use this handy RubyGems search.

This release also includes a galore of bug fixes, mostly related to the handling of xcassets resources.

Creating plugins

A CocoaPods plugin is a gem which includes a file named cocoapods_plugin.rb. CocoaPods will load this file for any installed gem that includes it. The file will be loaded before running any command, but after CocoaPods’ files (and those of its dependencies) have been loaded. The convention is to use this file to require the actual implementation of the plugin.

For example cocoapods-open has the following cocoapods_plugin.rb:

require 'pod/command/open'

To create a new gem you can use bundler which provides a convenient command:

$ bundle gem NAME

Adding subcommands

Adding new subcommands is very easy. You just need to create a subclass of the command that will be used as the namespace. Subsequently, it is necessary to provide the metadata of the new command and its logic. For more information you can check the documentation of the CLAide gem and the source code of the CocoaPods commands.

If this sounds complicated, don’t be scared; we love simplicity! Actually the implementation of those steps is simpler than their description. Following you can find the complete implementation of the pod spec doc command.

# lib/pod/command/spec/doc.rb

module Pod
  class Command
    class Spec
      class Doc < Spec
        self.summary = "Opens the web documentation of a Pod."

        self.description = <<-DESC
          Opens the web documentation of the Pod with the given NAME.
        DESC

        self.arguments = 'NAME'

        def initialize(argv)
          @name = argv.shift_argument
          super
        end

        def validate!
          super
          help! "A Pod name is required." unless @name
        end

        def run
          path = get_path_of_spec(@name)
          spec = Specification.from_file(path)
          UI.puts "Opening #{spec.name} documentation"
          `open "http://cocoadocs.org/docsets/#{spec.name}"`
        end
      end
    end
  end
end

APIs

As of yet, an explicit API to access CocoaPods logic has not be defined. So try to fail as gracefully as possible in case a future version of CocoaPods breaks your usage. Also please let us know about your needs, so we can take them into account to finalize APIs.

Checklist

Name the plugin after the cocoapods-PLUGIN_NAME convention.
Include a cocoapods_plugin.rb file.
Use the cocoapods_plugin.rb file to load the actual implementation.
Fail gracefully when relying on CocoaPods methods.
Let us know if you make something cool!

Updating

To install the last release of CocoaPods you can run:

$ [sudo] gem install cocoapods

Until version 1.0 we strongly encourage you to keep CocoaPods up to date.

For all the details, don't miss the Changelog.

CocoaPods → CocoaPodsFeed

Thu, 07 Nov 2013 00:00:00 +0000

TL;DR: New library notifications have moved from the @CocoaPods twitter to the @CocoaPodsFeed twitter account

If you want to follow the new libraries on CocoaPods, Follow @CocoaPodsFeed

In thinking about ways that CocoaPods can communicate news, updates and ideas one of the first things that came out in discussion was "Let's make the Twitter more relevant."

Right now if you want to keep up to date with CocoaPods you also end up keeping up to date with every new library on the platform. This can be too much sometimes, especially for people who don't follow hundreds of people.

To deal with this effectively we've moved out notifications on to a separate twitter account allowing the CocoaPods twitter feed to become a relatively low-chaff high information yield source for those interested in keeping up on Objective-C Open Source.

CocoaPods 0.27 and improved installation UX

Thu, 24 Oct 2013 00:00:00 +0000

TL;DR: Compilation as part of the CocoaPods gem install process is dead. Long live precompiled gems!

The CocoaPods gems will now be installable without the need for installing the Xcode Command Line Tools and fixing the Ruby headers location on OS X (Mountain Lion and Mavericks).

History on the underlying problem

While CocoaPods and most of its dependencies are implemented in pure Ruby there is one dependency that requires a bit of C code, or –in Ruby parlance– a ‘Ruby C extension’.

Typically, a ‘Ruby C extension’ will be compiled on the user’s machine during installation of the gem it belongs to. While this leads to better portability, it does add the requirement of having a compiler and the Ruby C headers, both of which are not available on OS X by default.

To be fair, Mavericks does come with the Command Line Tools pre-installed, and thus with a compiler, but it does not place the Ruby C headers in the right location and manual intervention is required.

The dependency with a C extension that we have is Xcodeproj, the library that powers our Xcode project parsing and generation. It does this by utilising the OS X Core Foundation API called CFPropertyList. This API allows us to read any type of PList, including the deprecated ASCII format that Xcode still uses, and generate a PList readable by Xcode. While there were –at the time of implementing Xcodeproj– some pure Ruby libraries to read or write one of the PList formats, there was none that implemented them all to our satisfaction. Finally, as a Xcode project is an undocumented format, we did not want to spend a lot of time on implementing and possibly having to replace it in the future if Apple would ever decide to change the format.

UX Perspective

You can skip to ‘The solution’ if you’re not interested in a discussion on the ramifications of how to get things done with Ruby and the status quo.

These sorts of issues make the out-of-the-box UX for pure Ruby users really bad. CocoaPods is such a tool that has many more users whom are not Ruby developers. I.e. Ruby is somewhat of an implementation detail. This understandably leads to frustrated users.

To add insult to injury, such users –in their willingness to give CocoaPods a second chance– will usually google for a solution leading them into, what I call, the ‘developer bubble’ of Ruby developers.

In this ‘developer bubble’ there is no sane Ruby environment unless you at least build your own Ruby, but preferably including one or more of the following tools: homebrew, RVM, rbenv, and many other alternatives.

Here’s a recent blog post that gives this illusion and here’s a typical tweet that illustrates how this suggestion leads a pure Ruby user astray:

Soooo... I need to install homebrew for rvm, ruby-install, and rbenv, and then will be able to `gem install cocoa pods`? #shitshow
— ¡ɜɿoɾɪɹℲ (@frijole) October 21, 2013

Shitshow indeed.

The sad part is, it isn’t even necessary. Not if you are a Ruby developer, let alone if you are a pure user. We in the Ruby community need to fix this perspective and look at the mess we’ve gotten ourselves in from the outside and better frame our suggestions in context. But I digress, for now.

Solution

The solution is simple and, in our case, two-fold:

The only remaining –but very valid– concern is that, by default, you will have to use sudo when installing gems. (This is only an issue for the duration of the gem installation, though.)

If you do not want to grant RubyGems admin privileges for this process, you can tell RubyGems to install into your user directory by passing either the --user-install flag to gem install or by configuring the RubyGems environment. The latter is in our opinion the best solution. To do this, edit the .profile file in your home directory and add or amend it to include these lines:

  export GEM_HOME=$HOME/gems
  export PATH=$GEM_HOME/bin:$PATH

Note that if you choose to use the --user-install option, you will still have to configure your .profile file to set the PATH or use the command prepended by the full path. You can find out where a gem is installed with gem which cocoapods. E.g.

  $ gem install cocoapods --user-install
  $ gem which cocoapods
  /Users/eloy/.gem/ruby/1.8/gems/cocoapods-0.27.0/lib/cocoapods.rb
  $ /Users/eloy/.gem/ruby/1.8/gems/cocoapods-0.27.0/bin/pod install

Provide prebuilt binaries for the Ruby versions that come with OS X.

In our case this means a prebuilt version of the C extension for Ruby 1.8.7 on OS X 10.8.x and for Ruby 2.0.0 on OS X 10.9.x. On these versions, the user does not have to install the Xcode Command Line Tools, nor fix the Ruby C headers.

If you are using a custom Ruby version, however, regardless of it being the exact same Ruby version for which we provide prebuilt binaries, you will have to compile the C extension and thus need the Xcode Command Line Tools.

This all works transparently, so you don’t need to think about it much. If, however, for whatever reason you wish to control this then you can use the XCODEPROJ_BUILD environment variable. Set it to 1 to always compile or to 0 to never compile.

Note that you can recognize that you’re using the prebuilt binary by the following sentence in the gem install output:

[!] You are using the prebuilt binary version of the xcodeproj gem.

Notes for RubyGems developers

Over the course of figuring out the best way to cater to our users, I came to the following insights:

RubyGems built-in prebuilt binaries support.

RubyGems automagically installs a CPU-architecture + OS-version specific version of your gem if one exists with the following filename: [NAME]-[VERSION]-[ARCH]-[PLATFORM].gem. E.g.: xcodeproj-0.14.0-universal.x86_64-darwin13.gem.

While this allows you to prebuilt for specific architectures and OS versions, it doesn’t allow for control over which Ruby version you have. This means it is not an option for us, as we have to check if the Ruby you are using is in fact a pre-installed OS X Ruby version. (In case there is a modifier to control the Ruby version, please let me know and I will update this section.)

RubyGems installation without the need for `make`.

Because we have to check if the Ruby version you are using is a version that comes pre-installed with OS X, we have to perform these checks at the time that the gem is being installed. Typically, RubyGems authors ‘abuse’ their extconf.rb to generate a no-op Makefile in the case that no compilation is required. This, however, means that the user will still need to have make installed, which is not the case on OS X 10.8.

Luckily Eric Hodel, one of the RubyGems maintainers, pointed me to an undocumented feature. Instead of specifying the extension like so:

  s.extensions = "ext/xcodeproj/extconf.rb"

You can alternatively specify a Rakefile, in which case RubyGems will leave running make, or whatever you need to run, up to your rake task:

  s.extensions = "ext/xcodeproj/Rakefile"

Prebuilt binary packaging helpers.

The rake-compiler library is very helpful in prebuilding extensions and understanding how RubyGems handles these gem filename formats. However, if you are going to target very specific Ruby versions which are the same regardless of user/machine –like we do– then it’s much simpler to just vendor the result of your extconf.rb (i.e. the Makefile and possibly extconf.h) and use those to build your extensions. Here’s our final solution.

Cocoa Kucha - 20 Nov 2013

Sun, 13 Oct 2013 00:00:00 +0000

CocoaPods is more than just a tool, CocoaPods is a community of over a thousand commiters, six thousand Podspecs and hundreds of thousands of users. To say the community is growing is a mild understatement. One of the cool things about a big community is that there's the chance that people will get clumped enough together to make meeting up and sharing ideas a possible. I'd like to announce our first attempt at trying to bring people together, starting in New York City this November.

Cocoa Kucha is a meetup in the style of Pecha Kucha. The idea is we get 8 people to talk about a topic related to Objective-C for 6 minutes and 20 seconds. 20 slides at 20 seconds. Mix that with some drinks and conversation and I think we've got a nice evening.

The format of a Pecha Kuchas makes it a great way to start experimenting with public speaking. The first time I spoke publicy was at a Pecha Kucha on folk dancing in the UK, and then later on the history of the game monopoly. At this point I'd like to open invites for people to talk, currently all of the slots are open and I will edit this post when all the slots are closed.

You can join our NYC meetup group to keep up to date, and the event will allow RSVPs 2 weeks before on the 6th Nov. Thanks to @W5mith & meetup.com for hosting us this time.

Currently confirmed for the 20th

Blake Watters - @adamhowardprice
Nils Hayat - @nilsou
Daniel Amitay - @danielamitay
Dustin Barker - @dstnbrkr
Bryan Irace - @irace
Klaas Pieter - @klaaspieter
Billy Gray - @billymeltdown
Jack Flintermann - @jflinter

CocoaPods 0.26

Tue, 08 Oct 2013 00:00:00 +0000

Today we are releasing CocoaPods 0.26.

The most visible change is that CocoaPods now hides the schemes of the Pod targets. If this doesn't ring a bell the following image should.

Don't fear though, the schemes are still there and if you need to check that a CocoaPods generated target is behaving correctly you can easily make its scheme visible.

Other improvements include the restoration of the compatibility with Xcode 4 which was creating issues in our linting process and the reorganization of the Pods project.

This release also features a contribution from the latest entry to our core team: Kyle Fuller

To install the last release of CocoaPods you can run:

$ [sudo] gem install cocoapods

Until version 1.0 we strongly encourage you to keep CocoaPods up to date.

For all the details, don't miss the Changelog.

On Design

Thu, 03 Oct 2013 01:20:16 +0000

Interested in finding the CocoaPods Logo? Check out our Media Pack.

CocoaPods is arguably one of the most important open source project in the Objective-C community. It's used in thousands of applications and has hundreds of thousands of downloads.

Building the tool, the community and the ecosystem around the project has happened organically with a mix of people coming and helping out to get us to a position where CocoaPods is essential to any project.

Starting from May 2013, I've been working with Andy Myers to try and re-think the systems around CocoaPods, ranging from how we do documentation to the branding. This blog post is to open up our process a bit and to explain how we came to some of these ideas.

The first and most obvious change is the logo. Here it is in mono-colour.

We took ideas from the Objective-C import directives, OS metaphors for text selection and colours from the Cocoa Pods themselves to create a new modern logo.

CocoaPods itself is a collection of projects like the multiple gems that create the terminal tool, the search engine, CocoaDocs and more. We needed to find a way that we can provide a similar identity between all the different sub-projects that are public facing. In my opinion the jQuery foundation did a great job at this. By having the logo neatly split along the selected and unselected edge we can easily extend the logo depending on our needs.

Once we had the logo down the visual identity was starting to appear, we spent some time looking at the analytics for cocoapods.org and tried to get a feel for how the website is used. Turns out most of the outgoing links are based on search queries. So we priorised the initial screen to give precedence for searching and then to go straight into learning for people who have just heard of the project.

Whilst looking at the analytics we were surprised to find that the percentage of mobile browsers wasn't what we hoped it to be. So the designs were done in parallel for mobile and for desktop.

The work on the CocoaPods design is on-going and has just started; there's a lot of focus now on the blog so that we can be sure of the foundations before moving on to the new user documentation. But that is a blog post for another time.

Why we don't accept donations

Mon, 23 Sep 2013 01:20:16 +0000

TL;DR: While we very much appreciate the sentiment, the project (as an entity) does not accept financial donations.

We are passionate about sharing. This means that we will spend time on CocoaPods in our spare-time, even when that is not of immediate financial benefit to us (as described in point 2), but we do get pleasure from working on something that can improve our small piece of the universe, without expecting any financial gains.

It is important to note, though, that the reason we have the opportunity to enjoy this form of spiritual fulfilment is only possible because we’re in well enough financial positions to be able to do this for free. We’re very much aware that some people are in much less fortunate positions and OSS donations are a real source of income.

In principle, we use CocoaPods for our paid work and as such spend time on improving it during work hours. Normally you should still invoice a client for setting up a project, so if that time is usually diminished, the times where we do have to spend some time on CocoaPods for a specific project is balanced out and usually tilts in favour of the client.
CocoaPods, and OSS in general, is our LinkedIn. We get to meet a lot of people around the world, which often leads to great opportunities for our careers in the future. This might not always be obvious to people, but it should not be underestimated.
Financial donations do add a feeling of responsibility, for some, without the financial compensation we would normally offset that with. I.e. our hourly rates for contracting work would be much higher than a typical donation. The reason we do not want to add such feelings of responsibility is that it’s important for us, in the globally connected, fast-paced world we live in, to be able to say “not now, I feel like doing something completely different”. Burnout is something that can hit prolific open-source people pretty fast and we need to actively counteract that.

So what can you do?

Helping out with CocoaPods comes in many forms. For those that are not able to help out with (Ruby) code issues, there are still ways to do so. Writing documentation and triaging tickets before they get to us are probably the most helpful in the sense of relieving us from financial ‘losses’, as they save us a whole lot of time.

Also, by providing the tools for a vibrant community to do their magic, we benefit from the great Objective-C libraries that you all write and so we all do our part in the grand scheme of things.

As a company, you can contract people of the core team for CocoaPods related work on your project.
As a company you can ‘sponsor’ by contracting people of the core team to implement specific features your company needs in CocoaPods (as this is real paid work, as opposed to donations, the tickets you sponsor will be prioritised over others), or implement general CocoaPods improvements, which serve the community as a whole.

Other ways of sponsoring includes wide ranging topics, such as, legal consultancy, t-shirts, stickers, etc.

Note that we do recognise companies for the work described in this section as ‘sponsors’, of which we keep a list in the README.

Finally, as said before, individual people might be in a less fortunate financial position and as such it’s perfectly ok to send donations through means like Patreon, if that individual accepts that. These are not considered to be specific for the CocoaPods project, though.

Using Acknowledgements

Sat, 10 Aug 2013 00:00:00 +0000

CocoaPods will generate two 'Acknowledgements' files for each target specified in your Podfile. If the pods are coming from the master repo, then they must include one. Private pods don't require one. These contain the License details for each Pod and for most of the part having them in your acknowledgements will be enough to conform to the license.

CocoaPods generates a markdown file for general consumption, as well as a property list file that can be added to a settings bundle for an iOS application. You don't need to do anything for this to happen, it will just work. If you'd like to know more about extra things you can do with this, read on.

Customization

If you're not happy with the default boilerplate text generated for the title, header and footnotes in the files, it's possible to customise these by overriding the methods that generate the text in your Podfile like this:

class ::Pod::Generator::Acknowledgements
  def header_text
    "My custom header text"
  end
end

You can even go one step further and customise the text on a per target basis by checking against the target name, like this:

class ::Pod::Generator::Acknowledgements
  def header_text
    if @target_definition.label.end_with?("MyTargetName")
      "Custom header text for MyTargetName"
    else
      "Custom header text for other targets"
    end
  end
end

These are the available methods to override: header_title, header_text, footnote_title & footnote_text.

iOS Settings Bundle

If you are using the generated plist in your settings bundle you might want to update the file every time that you update your pods. This can be accomplished by adding to your Podfile the following post_install hook.

post_install do | installer |
  require 'fileutils'
  FileUtils.cp_r('Pods/Pods-Acknowledgements.plist', 'Resources/Settings.bundle/Acknowledgements.plist', :remove_destination => true)
end

To access this from your Setting Bundle's Root.plist replace your Root.plist with this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>StringsTable</key>
    <string>Root</string>
    <key>PreferenceSpecifiers</key>
    <array>
        <dict>
            <key>Type</key>
            <string>PSChildPaneSpecifier</string>
            <key>Title</key>
            <string>Acknowledgements</string>
            <key>File</key>
            <string>Acknowledgements</string>
        </dict>
    </array>
</dict>
</plist>

Further details can be found in Martin Hicks's blog

CocoaPods Blog

CocoaPods Trunk: Minor security updates

The fix

Worst case scenario

For more information

CocoaPods Trunk Read-only Plan

Timeline

May 2025

Mid-late 2025

September-October 2026

November 1-7th 2026

December 2nd 2026

Contact

CocoaPods Support & Maintenance Plans

How CocoaPods Is Maintained

New contributors

Long term plans

Read-only Specs

I use CocoaPods as a Hidden Abstraction in My Framework

Plodding on

CocoaPods Trunk: 3 Remote Code Execution found, 2023

Worst case scenario

For more information

CocoaPods Web Hosting now Sponsored by Emerge Tools

1.11 Arrives!

Ruby 2.6 and Ruby 3.0

On Demand Resources

Other Notable Enhancements

Xcode 13 Support

What's Next

CocoaPods Trunk: Remote Code Execution found

Patched

How the exploit worked

Worst case scenario

For more information

1.10 Beta Begins!

Ruby 2.0 is out, 2.7 is in!

Revamped XCFramework Integration

Xcode 12 Support

post_integrate Hook DSL

ensure_bundler! DSL

What's Next

CocoaPods 1.9 Beta has arrived!

XCFramework Support

Configuration-based dependencies for Podspecs

Code Coverage in Test Specs

Swift Version Variants

use_frameworks! Linkage Customization

What's Next

CocoaPods 1.8 Beta is Here!

CDN as Default

info_plist Podspec DSL

project_name Podfile DSL

Test Spec Enhancements

UI Test Bundle Support

Customizable App Host

What's Next?

CocoaPods 1.7.2 — Master Repo CDN is Finalized!

Scaling when free and open source

Git as a Database

Directory Listing Denied

Final Lap with Netlify

Usage

CocoaPods 1.7.0 Beta!

Support For Multiple Swift Versions

Linting And Validation

Deprecating .swift-version File

App Specs

Multiple Xcodeproj Generation

Incremental Installation

scheme DSL

.xcfilelist Support

Experimental Features

CDN Support For The Master Specs Repo

Windows Support

What's Next?

CocoaPods 1.6.0 Beta Begins!

Revamped Build Settings

Enhanced Test Spec Integration

Longer Beta Cycle

`post_integrate` Hook DSL

`ensure_bundler!` DSL

`use_frameworks!` Linkage Customization

`info_plist` Podspec DSL

`project_name` Podfile DSL

Deprecating `.swift-version` File

`scheme` DSL

`.xcfilelist` Support

Transition to `https`