This article was published on May 10, 2016

CocoaPods celebrates its version 1.0 release by officially changing how Podfiles work


CocoaPods celebrates its version 1.0 release by officially changing how Podfiles work

CocoaPods has reached version 1.0, and is celebrating its milestone by officially changing how Podfiles work, and giving Pod owners more control.

Though the changes to Podfiles were known (via a migration guide), they’re now official. Of the more important things to note is that targets must now be explicitly defined in Podfiles, and the names must match what’s in Xcode.

cocoapods

CocoaPods is also making abstract pods available for cross-platform dependencies, and have moved some command line options to Podfile installation options.

The 💜 of EU tech

The latest rumblings from the EU tech scene, a story from our wise ol' founder Boris, and some questionable AI art. It's free, every week, in your inbox. Sign up now!

It’s not all about flipping it upside down, though. CocoaPods also have a new linter, which is meant to make sure libraries conform to Podspec before being compiled and imported into apps. Pod owners now have two new commands for trunks: pod trunk deprecate and pod trunk delete. That was implemented because CocoaPods will no longer be accepting pull requests to the specs repo, and felt the commands were a way to ensure Pod owners still had full control of their work.

Finally, deintegration is now standard fare for CocoaPods. If you change targets in a Podfile, it will no longer wreck things when you build in Xcode. To that, cocoapods-deintegrate is a default plugin, and the pod install command now makes sure targets not pointing to Pods have no traces of CocoaPods.

Get the TNW newsletter

Get the most important tech news in your inbox each week.