This talk was given at CocoaHeads Kalamazoo on July 18, 2013. It is an introduction to using CocoaPods as a dependency manager and as a means of publishing Objective-C libraries.
third-party libraries by copy-paste? • Who uses git submodules? • Who has used CocoaPods? • Is anyone even a little familiar with Ruby/ RubyGems/Bundler? Tuesday, July 23, 13
in Ruby • Inspired by Bundler • “Improves discoverability of, and engagement in, third-party open-source libraries by creating a more centralized ecosystem.” Tuesday, July 23, 13
to your project. • No manual 3rd-party library build configuration. • Automatically handles ARC/no-ARC. • Clear separation of in-house and third-party code. Tuesday, July 23, 13
to your project. • No manual 3rd-party library build configuration. • Automatically handles ARC/no-ARC. • Clear separation of in-house and third-party code. • Only includes the relevant source files. Tuesday, July 23, 13
to your project. • No manual 3rd-party library build configuration. • Automatically handles ARC/no-ARC. • Clear separation of in-house and third-party code. • Only includes the relevant source files. • Project is always shippable. Tuesday, July 23, 13
Lists the dependencies by name, version, source, etc. • Defines targets, platforms, pre/post-install hooks • Cocoapods uses this to build your *.xcworkspace Podfile (simple) Podfile (hardcore) Highlights • Pods come from CocoaPods/Spec repo by default • Official releases use semantic versioning. • Specify different pods for different targets (i.e. :test) • Can define which project to build *.xcworkspace around • Define platform and version ranges (:ios, :osx) Tuesday, July 23, 13
Architecture changes • Major API changes • Typically incompatible with previous changes • y => Minor release • New functionality is backwards compatible • Should not, but might, have breaking changes Tuesday, July 23, 13
Architecture changes • Major API changes • Typically incompatible with previous changes • y => Minor release • New functionality is backwards compatible • Should not, but might, have breaking changes • z => Patch release • Backwards-compatible bug fixes • Non-breaking API modifications Tuesday, July 23, 13
Architecture changes • Major API changes • Typically incompatible with previous changes • y => Minor release • New functionality is backwards compatible • Should not, but might, have breaking changes • z => Patch release • Backwards-compatible bug fixes • Non-breaking API modifications NOTE: 0.y.z releases are considered initial development. Responsible versioners will typically shift the convention down one decimal place if the library is in active use. However, public APIs should not be considered stable during initial development. Tuesday, July 23, 13
the pod name ‘0.8’ Use this exact version ‘> 0.8’ Any version higher than 0.8 ‘>= 0.8’ Version 0.8 or higher ‘< 0.8’ Any version lower than 0.8 ‘<= 0.8’ Version 0.8 or lower (max 0.8) ‘~> 0.8.2’ 0.8.2 <= version < 0.9 :head (no quotes) Use bleeding edge from the pod’s repository (may not be compatible) Tuesday, July 23, 13
the pod name ‘0.8’ Use this exact version ‘> 0.8’ Any version higher than 0.8 ‘>= 0.8’ Version 0.8 or higher ‘< 0.8’ Any version lower than 0.8 ‘<= 0.8’ Version 0.8 or lower (max 0.8) ‘~> 0.8.2’ 0.8.2 <= version < 0.9 :head (no quotes) Use bleeding edge from the pod’s repository (may not be compatible) • Alternatively, choose a specific commit from the pod’s repository (or a fork) Tuesday, July 23, 13
the pod name ‘0.8’ Use this exact version ‘> 0.8’ Any version higher than 0.8 ‘>= 0.8’ Version 0.8 or higher ‘< 0.8’ Any version lower than 0.8 ‘<= 0.8’ Version 0.8 or lower (max 0.8) ‘~> 0.8.2’ 0.8.2 <= version < 0.9 :head (no quotes) Use bleeding edge from the pod’s repository (may not be compatible) • Alternatively, choose a specific commit from the pod’s repository (or a fork) Tuesday, July 23, 13
the pod name ‘0.8’ Use this exact version ‘> 0.8’ Any version higher than 0.8 ‘>= 0.8’ Version 0.8 or higher ‘< 0.8’ Any version lower than 0.8 ‘<= 0.8’ Version 0.8 or lower (max 0.8) ‘~> 0.8.2’ 0.8.2 <= version < 0.9 :head (no quotes) Use bleeding edge from the pod’s repository (may not be compatible) • Alternatively, choose a specific commit from the pod’s repository (or a fork) • Or create your own podspec to use for a library that doesn’t have one: Tuesday, July 23, 13
the pod name ‘0.8’ Use this exact version ‘> 0.8’ Any version higher than 0.8 ‘>= 0.8’ Version 0.8 or higher ‘< 0.8’ Any version lower than 0.8 ‘<= 0.8’ Version 0.8 or lower (max 0.8) ‘~> 0.8.2’ 0.8.2 <= version < 0.9 :head (no quotes) Use bleeding edge from the pod’s repository (may not be compatible) • Alternatively, choose a specific commit from the pod’s repository (or a fork) • Or create your own podspec to use for a library that doesn’t have one: Tuesday, July 23, 13
• Downloads the relevant files from their source into Pods/<PodName> • Creates a project for each pod from its podspec • Resolves dependency issues between pods • Generates a *.xcworkspace with your projects and all the pods • Generates a Podfile.lock • Preserves version currently installed, and is used while installing instead of the Podfile if it exists. Note: You should always check *.xcworkspace, Podfile, Podfile.lock, and Pods/ into source control. This will protect your project in case the source repository is ever moved or deleted, and ensures that all of the source code in your project is self-contained. It also means that co-workers don’t need to have CocoaPods set up in order to work on the project. Tuesday, July 23, 13
If the repo is rebased, moved, or deleted, updating or cloning is broken. $ git submodule add https://github.com/AFNetworking/AFNetworking.git Vendor/AFNetworking Tuesday, July 23, 13
If the repo is rebased, moved, or deleted, updating or cloning is broken. • Malleability • Allows you to edit, push, update, and track the source code directly. • This may not be a good thing, especially with a widely used library. • No human-readable, reliable version management. • Official releases may be used if tagging is done properly, but it’s not always easy to find them. $ git submodule add https://github.com/AFNetworking/AFNetworking.git Vendor/AFNetworking Tuesday, July 23, 13
If the repo is rebased, moved, or deleted, updating or cloning is broken. • Malleability • Allows you to edit, push, update, and track the source code directly. • This may not be a good thing, especially with a widely used library. • No human-readable, reliable version management. • Official releases may be used if tagging is done properly, but it’s not always easy to find them. • User-Friendliness • Updating is not straightforward • Removing submodules means modifying .git* files manually • Still requires manual importing, organization, and configuration of the project. $ git submodule add https://github.com/AFNetworking/AFNetworking.git Vendor/AFNetworking Tuesday, July 23, 13
If the repo is rebased, moved, or deleted, updating or cloning is broken. • Malleability • Allows you to edit, push, update, and track the source code directly. • This may not be a good thing, especially with a widely used library. • No human-readable, reliable version management. • Official releases may be used if tagging is done properly, but it’s not always easy to find them. • User-Friendliness • Updating is not straightforward • Removing submodules means modifying .git* files manually • Still requires manual importing, organization, and configuration of the project. • Version Control • Unreliable/nonstandard version specification • No dependency resolution - shared dependencies will get messy • GitHub app (and in general, git users) tend to not manage submodules well $ git submodule add https://github.com/AFNetworking/AFNetworking.git Vendor/AFNetworking Tuesday, July 23, 13
be a public or private git repo. • Directory named for each pod • Directory in each pod directory for each release version containing the podspec • Add your repository so your CocoaPods install knows where to look • You can now search for your pods as if they were public • You should have a version directory for every version of a library that is being used in a project. Semantic versioning syntax is required. True semantic versioning is not required, but highly recommended. • You probably shouldn’t ever remove a version directory unless there is a very good reason for it. • In most cases, when you add a new version, all you do is change the version and source ref in the podspec: Notes: * version and tag should match. Tuesday, July 23, 13
be a public or private git repo. • Directory named for each pod • Directory in each pod directory for each release version containing the podspec • Add your repository so your CocoaPods install knows where to look • You can now search for your pods as if they were public • You should have a version directory for every version of a library that is being used in a project. Semantic versioning syntax is required. True semantic versioning is not required, but highly recommended. • You probably shouldn’t ever remove a version directory unless there is a very good reason for it. • In most cases, when you add a new version, all you do is change the version and source ref in the podspec: Notes: * version and tag should match. Tuesday, July 23, 13
all of the repo management for us. A good practice is to keep your master podspec in the actual library’s repository, and keep it updated with the source. Then use pod push to publish official releases after updating the version and tag. Tuesday, July 23, 13
• NO. You should never run arbitrary code on a system (especially production systems) without thorough inspection and testing. • CocoaPods provides a sandbox mode that will disallow and log unsanctioned operations. It’s a good idea to play around with this, though the feature is currently experimental. • If you don’t trust it, don’t use it - report it or fix it. Tuesday, July 23, 13
• NO. You should never run arbitrary code on a system (especially production systems) without thorough inspection and testing. • CocoaPods provides a sandbox mode that will disallow and log unsanctioned operations. It’s a good idea to play around with this, though the feature is currently experimental. • If you don’t trust it, don’t use it - report it or fix it. • CocoaPods is under active development. • While they claim it’s not ready for ‘prime-time,’ that doesn’t mean it shouldn’t be used. Just use with caution. • It is a good idea to check for updates regularly and keep an eye on the CocoaPods CHANGELOG for potentially breaking changes. Tuesday, July 23, 13
in source control: • MyProject.xcworkspace • Podfile • Podfile.lock • Pods/* # Github’s Objective-C .gitignore ignores this by default. • Use the pessimistic version operator: • ‘~> 0.1.8’ to prevent breaking changes when updating or installing pods. Tuesday, July 23, 13
in source control: • MyProject.xcworkspace • Podfile • Podfile.lock • Pods/* # Github’s Objective-C .gitignore ignores this by default. • Use the pessimistic version operator: • ‘~> 0.1.8’ to prevent breaking changes when updating or installing pods. • Isolate your pod installs, updates, and uninstalls into individual commits. • Files will be added/removed, configurations will change, Podfile.lock will be regenerated. All of these things need to be tracked, and these changes should not include unrelated diffs. Tuesday, July 23, 13
in source control: • MyProject.xcworkspace • Podfile • Podfile.lock • Pods/* # Github’s Objective-C .gitignore ignores this by default. • Use the pessimistic version operator: • ‘~> 0.1.8’ to prevent breaking changes when updating or installing pods. • Isolate your pod installs, updates, and uninstalls into individual commits. • Files will be added/removed, configurations will change, Podfile.lock will be regenerated. All of these things need to be tracked, and these changes should not include unrelated diffs. • Read and test the libraries before committing them into master. Tuesday, July 23, 13
in source control: • MyProject.xcworkspace • Podfile • Podfile.lock • Pods/* # Github’s Objective-C .gitignore ignores this by default. • Use the pessimistic version operator: • ‘~> 0.1.8’ to prevent breaking changes when updating or installing pods. • Isolate your pod installs, updates, and uninstalls into individual commits. • Files will be added/removed, configurations will change, Podfile.lock will be regenerated. All of these things need to be tracked, and these changes should not include unrelated diffs. • Read and test the libraries before committing them into master. • Submit issues and pull-requests. Give back to the community. Tuesday, July 23, 13
in source control: • MyProject.xcworkspace • Podfile • Podfile.lock • Pods/* # Github’s Objective-C .gitignore ignores this by default. • Use the pessimistic version operator: • ‘~> 0.1.8’ to prevent breaking changes when updating or installing pods. • Isolate your pod installs, updates, and uninstalls into individual commits. • Files will be added/removed, configurations will change, Podfile.lock will be regenerated. All of these things need to be tracked, and these changes should not include unrelated diffs. • Read and test the libraries before committing them into master. • Submit issues and pull-requests. Give back to the community. • Be nice to open-source developers. Open-source development and maintenance is hard, and free code should not be taken for granted. Tuesday, July 23, 13
in source control: • MyProject.xcworkspace • Podfile • Podfile.lock • Pods/* # Github’s Objective-C .gitignore ignores this by default. • Use the pessimistic version operator: • ‘~> 0.1.8’ to prevent breaking changes when updating or installing pods. • Isolate your pod installs, updates, and uninstalls into individual commits. • Files will be added/removed, configurations will change, Podfile.lock will be regenerated. All of these things need to be tracked, and these changes should not include unrelated diffs. • Read and test the libraries before committing them into master. • Submit issues and pull-requests. Give back to the community. • Be nice to open-source developers. Open-source development and maintenance is hard, and free code should not be taken for granted. • Follow @CocoaPods on twitter. Tuesday, July 23, 13
in source control: • MyProject.xcworkspace • Podfile • Podfile.lock • Pods/* # Github’s Objective-C .gitignore ignores this by default. • Use the pessimistic version operator: • ‘~> 0.1.8’ to prevent breaking changes when updating or installing pods. • Isolate your pod installs, updates, and uninstalls into individual commits. • Files will be added/removed, configurations will change, Podfile.lock will be regenerated. All of these things need to be tracked, and these changes should not include unrelated diffs. • Read and test the libraries before committing them into master. • Submit issues and pull-requests. Give back to the community. • Be nice to open-source developers. Open-source development and maintenance is hard, and free code should not be taken for granted. • Follow @CocoaPods on twitter. • When in doubt, read the docs. When those aren’t good enough, read the source, and consider submitting a pull request to update the docs. Tuesday, July 23, 13
CocoaPods http://www.cocoanetics.com/2013/01/digging-into-cocoapods/ http://www.cocoanetics.com/2013/04/private-pods/ http://www.cocoanetics.com/2013/05/8130/ RestKit using Dependencies and Subspecs: https://github.com/CocoaPods/Specs/blob/master/RestKit/0.20.3/RestKit.podspec Tuesday, July 23, 13
CocoaPods http://www.cocoanetics.com/2013/01/digging-into-cocoapods/ http://www.cocoanetics.com/2013/04/private-pods/ http://www.cocoanetics.com/2013/05/8130/ RestKit using Dependencies and Subspecs: https://github.com/CocoaPods/Specs/blob/master/RestKit/0.20.3/RestKit.podspec TestFlightSDK Podspec using :http source: https://github.com/CocoaPods/Specs/blob/master/TestFlightSDK/1.3.0.beta4/TestFlightSDK.podspec Tuesday, July 23, 13
shekibobo
itsuki_t88
ryosukedtomita
umigishiaoi
codeforeveryone
nealle
uzulla
rkaga
suguruooki
fumiyakume
yktakaha4
yuzneri
primenumber
jonrohan
reverentgeek
matthewcrist
hatefulcrawdad
destraynor
shlominoach
chriscoyier
keithpitt
speakerdeck
quramy
gr2m
tammyeverts
![Josh Kovach [email protected] @shekibobo CocoaHeads Kalamazoo July 18, 2013 CocoaPods](https://files.speakerdeck.com/presentations/e9d165d0d5c6013097b97e4216c7a558/slide_0.jpg){kind=link}
![Getting Started • $ [sudo] gem install cocoapods Tuesday, July](https://files.speakerdeck.com/presentations/e9d165d0d5c6013097b97e4216c7a558/slide_42.jpg){kind=link}
![Getting Started • $ [sudo] gem install cocoapods • $](https://files.speakerdeck.com/presentations/e9d165d0d5c6013097b97e4216c7a558/slide_43.jpg){kind=link}
![Getting Started • $ [sudo] gem install cocoapods • $](https://files.speakerdeck.com/presentations/e9d165d0d5c6013097b97e4216c7a558/slide_44.jpg){kind=link}
![Getting Started • $ [sudo] gem install cocoapods • $](https://files.speakerdeck.com/presentations/e9d165d0d5c6013097b97e4216c7a558/slide_45.jpg){kind=link}
![Getting Started • $ [sudo] gem install cocoapods • $](https://files.speakerdeck.com/presentations/e9d165d0d5c6013097b97e4216c7a558/slide_46.jpg){kind=link}
![Getting Started • $ [sudo] gem install cocoapods • $](https://files.speakerdeck.com/presentations/e9d165d0d5c6013097b97e4216c7a558/slide_47.jpg){kind=link}
![Getting Started • $ [sudo] gem install cocoapods • $](https://files.speakerdeck.com/presentations/e9d165d0d5c6013097b97e4216c7a558/slide_48.jpg){kind=link}
