439

I've been doing iOS development for a couple of months now and just learned of the promising CocoaPods library for dependency management.

I tried it out on a personal project: added a dependency to Kiwi to my Podfile, ran pod install CocoaPodsTest.xcodeproj, and voila, it worked great.

The only thing I'm left wondering is: what do I check in, and what do I ignore for version control? It seems obvious that I want to check in the Podfile itself, and probably the .xcworkspace file as well; but do I ignore the Pods/ directory? Are there other files that will be generated down the road (when I add other dependencies) that I should also add to my .gitignore?

Dan Tao
  • 125,917
  • 54
  • 300
  • 447

20 Answers20

439

I commit my Pods directory. I don't agree that the Pods directory is a build artefact. In fact I'd say it most definitely isn't. It's part of your application source: it won't build without it!

It's easier to think of CocoaPods as a developer tool rather than a build tool. It doesn't build your project, it simply clones and installs your dependencies for you. It shouldn't be necessary to have CocoaPods installed to be able to simply build your project.

By making CocoaPods a dependency of your build, you now need to make sure it's available everywhere you might need to build your project...a team admin needs it, your CI server needs it. You should, as a rule, always be able to clone your source repository and build without any further effort.

Not committing your Pods directory also creates a massive headache if you frequently switch branches. Now you need to run pod install every time you switch branches to make sure your dependencies are correct. This might be less hassle as your dependencies stabilise but early in a project this is a massive time sink.

So, what do I ignore? Nothing. Podfile, the lock file and the Pods directory all get committed. Trust me, it will save you a lot of hassle. What are the cons? A slightly bigger repo? Not the end of the world.

chasew
  • 8,438
  • 7
  • 41
  • 48
Luke Redpath
  • 10,474
  • 3
  • 27
  • 26
  • 37
    This is definitely the way to use CocoaPods. Not only is it a part of your source because you can't build without it, but your "core application" is also often highly coupled to code in CocoaPods. Very important for versioning to know exactly what version of a pod is being used, and just using Lockfile doesn't cut it. – Joshua Gross Mar 12 '14 at 11:32
  • 42
    Easier when switching branch and when going back in time… This is a massive argument. – MonsieurDart Mar 12 '14 at 12:50
  • 5
    Yes, I could have elaborated on this further, but to me a commit in your repo represents a snapshot of your source in time and if you don't commit your Pods directory, a big part of that snapshot is missing. You can mitigate this by being very specific your Pod versions but also consider this...if you update one of your Pods, if your Pods are in your repo, then that update will be captured in a commit and will be fully diffable. If updating a Pod causes a bug, you can much more easily see why as the underlying change is captured in your own repo. – Luke Redpath Mar 12 '14 at 13:05
  • 6
    I think it's clear it's a matter of personal taste now. People like Seamus are now polarising the debate... it's really not fair to say that not including the `Pods` directory will cause you pain, when checking it in also comes with its own bundle of problems. e.g. a developer bumps a version of a dependency in a `Podfile` without remembering to check in the updated sources in Pods. Murphy's law. `pod install` every time you switch branch costs you precious ... TENS of seconds — but it eliminates that class of problems altogether. – fatuhoku Mar 23 '14 at 09:29
  • 2
    You could also extend this argument to state that you should include your specific compiler version and OS versions as well as these may also impact your build. – Sandy Chapman Apr 01 '14 at 14:29
  • 2
    What do you do with your internal cocoapods and private forks of public coccoapods? Do you also commit their sources in every project that includes them? – Alex Nauda Apr 02 '14 at 01:48
  • 3
    [This interesting article](https://www.dzombak.com/blog/2014/03/including-pods-in-source-control.html) seems quite pro including Pods – Pierre de LESPINAY Jul 04 '14 at 08:41
  • I think this should be a tenet of software development: Your builds need to be reproducible. And a new developer starting from scratch shall be able to check out your project and start working. Their first task should not be to hunt for various bits and pieces you have left out. CocoaPods can be removed by developers; or they move; or specific versions are removed. Whatever - it's the internet, things can happen. Keep what you need to build in the repo. – n13 Jun 23 '15 at 09:26
  • Although I agree that in theory that Pods should be in the repo, in practice it causes more headaches than not, especially if you need to often switch branches. In many cases you will be left with hundreds of files to commit just by switching branches because git doesn't handle removing existing directories well. In addition, you are forced to `pod install` _anyway_ when switching branches, so it seems pointless to add a bunch of files you have to recreate. – memmons Sep 24 '15 at 14:53
  • 1
    This is argument is all dependent on the fact that the build process, for example Xcode, does not run 'pod install'. If it simply did that than a CI server or a team admin will just get latest and build and the Cocoa Pods would already be refreshed. Cocoa Pods are build artifacts, the only reason that is it a best practice to include them in source control is because 'pods install' is not automatic part of Xcode Build. Other platforms have elegantly solved this problem, for example Visual Studio and Nuget, you never check in anything except a package.config and all builds get the libraries – Brian Ogden Oct 15 '16 at 18:56
  • How do you deal with merge conflicts between files in your Pod folder and other pod related files? – Minimi Dec 29 '16 at 00:50
  • 43
    `It won't build without it!` You might as well commit XCode too – Sourabh Jul 12 '17 at 08:31
  • 1
    All the code from Pods folder shows up in merge requests and makes doing code review very difficult. – Chris Gunawardena Oct 11 '17 at 15:12
  • 1
    I recommend adding Pods directory under source control, but always set specific versions of libraries in Podfile (for example pod 'Alamofire', '4.7.0') and only update them from time to time so that for example if someone else from team make pod update then changes in Pods are minimal or none. Also keep in mind that if you do not commit Pods folder and for example author of the library deletes his repo (cocoapods only holds links to the author's repo) or if github is down then you will not be able to run pod install and build your project. – Leszek Szary Mar 22 '18 at 15:01
  • 1
    Good opinions. Especially the case when you are switching branches very often. Can we say the same for node_modules directory for node apps? – Aleksandre Sukhitashvili Apr 17 '19 at 08:32
  • 3
    Are you committing node_modules as well? :joy: I think not.. Ours easily go beyond 700 mb for example.. You just commit yarn.lock and devs/ci do their own yarn install. Same concept goes for pods as well. 'It wont build without it' lol – Frexuz Jun 24 '21 at 03:10
303

Personally I do not check in the Pods directory & contents. I can't say I spent long ages considering the implications but my reasoning is something like:

The Podfile refers to a specific tag or or commit of each dependency so the Pods themselves can be generated from the podfile, ergo they are more like an intermediate build product than a source and, hence, don't need version control in my project.

Matt Mower
  • 3,743
  • 1
  • 18
  • 12
  • 77
    It might be worth mentioning that the CocoaPods project ignores the Pods directory in the [example](https://github.com/CocoaPods/CocoaPods/blob/master/.gitignore). – joshhepworth Jun 14 '12 at 03:26
  • 2
    So could we say in a standard project containing a `Podfile` (where we use `git add -a`) that we should `gitignore` Podfile.lock & Pod directory ? – Pierre de LESPINAY Jan 29 '13 at 17:34
  • 40
    I would consider adding the Podfile.lock file, because then you record exactly what versions of libraries you used for a specific build, and can reproduce it exactly for other team members. Having to ask "what version of X are you using" can be very annoying. Here is a good discussion of the ruby Gemfile equivalent: http://yehudakatz.com/2010/12/16/clarifying-the-roles-of-the-gemspec-and-gemfile/ – Matt Connolly Mar 04 '13 at 11:27
  • 17
    I don't understand why you'd commit the Podfile.lock, shouldn't you just be more specific in your Podfile about exactly what versions you depend on? What am I not understanding? – Michael Baltaks Mar 07 '13 at 00:57
  • 9
    Here's how I see it: If your Podfile specifies exact versions of every pod then the only way to get updates is to know the updates exist and manually specify them. This might be preferred for a popular or mission-critical app. For earlier development, important updates are much easier to come by if you just diff Podfile.lock when it gets updated and then decide if you want the updates, which you probably do most of the time. – davidkovsky Apr 21 '13 at 17:59
  • 1
    I see what you mean, I was just trying to `pod list outdated` (as you'd do in MacPorts), to see which of my installed pod versions is not the current available version, but that functionality works differently. I think I was expecting a python pip style setup, where there is one requirements file that the tool updates for you on request, which seems more elegant than two files with different syntax. So with Cocoapods, when you need to know exactly what code went into a build, commit the Podfile.lock. – Michael Baltaks Jul 12 '13 at 03:58
  • 2
    What about the `proj.xcworkspace` file that was generated by `pod install`? Should it be in `.gitignore` too? – Hlung Jul 18 '13 at 06:03
  • 3
    @Hlung you should definitely check the project's .xcworkspace file in, otherwise other users will have problems using the installed pods. – cbowns Oct 11 '13 at 01:34
  • 49
    It's important to mention `Podfile.lock`: it's called out [by Cocoapods](http://docs.cocoapods.org/guides/working_with_teams.html) as being recommended to be under version control. – cbowns Oct 11 '13 at 01:35
  • 2
    @Hlung - if you don't commit the pods that won't be a problem because you would still need to call pod install (which generates the proj.xcworkspace) – Dennis Jan 04 '14 at 00:26
  • 3
    It might be also worth mentioning that the [guide](http://guides.cocoapods.org/using/using-cocoapods.html#should-i-ignore-the-pods-directory-in-source-control) in cocoapods has recommended against adding the Pods directory to the .gitignore – ken May 05 '14 at 06:12
  • 4
    + committing the pods blows up your repositories unnecessarily! – cschuff Sep 03 '14 at 20:32
  • 3
    @joshhepworth The CocoaPods guides [recommends against adding the Pods directory to the .gitignore file](http://guides.cocoapods.org/using/using-cocoapods.html#should-i-ignore-the-pods-directory-in-source-control). – FernandoEscher Oct 03 '14 at 16:04
  • 4
    They do recommend against adding Pods dir to .gitignore, but then again they do a lot of stuff wrong. Podfile.lock gets changed any time you do pod install with a different version, which leads to spurious file changes. The pods dir contains build artifacts. They can be regenerated, and therefore have no business being in scm. – Karl Feb 26 '16 at 23:58
  • @Karl You might not be able to regenerate Pods folder if for example author of any library deletes his repository on github. Also some people in the past mentioned situations where zip files linked in the podfile were changed on author's server and broke their build after pod update and there had problems with going back to older version as it was not available anywhere. When you keep Pods folder on repo you are always safe and you can be sure that if you try to build your project in the future after one year from now then it will still build in the same way as it does now. – Leszek Szary Mar 27 '18 at 14:36
  • What about this? https://guides.cocoapods.org/using/using-cocoapods.html said that: Whether or not you check in the Pods directory, the Podfile and Podfile.lock should always be kept under version control. – Svitlana Jan 20 '19 at 14:27
  • 'Pods/' in git ignore is the most important and maybe the only line. CocoaPods has dependencies and devs run the check after git clone or download. – Matthew Ferguson Aug 21 '21 at 20:46
169

I recommend to use the GitHub’s Objective-C gitignore. In detail, the best practices are:

  • The Podfile must always be under source control.
  • The Podfile.lock must always be under source control.
  • The Workspace generated by CocoaPods should be kept under source control.
  • Any Pod referenced with the :path option should be kept under source control.
  • The ./Pods folder can be kept under source control.

For more information you can refer to the official guide.

source: I’m a member of the CocoaPods core team, like @alloy

Although the Pods folder is a build artifact there are reasons that you might consider while deciding wether to keep it under source control:

  • CocoaPods is not a package manager so the original source of the library could be removed in future by the author.
  • If the Pods folder is included in source control, it is not necessary to install CocoaPods to run the project as the checkout would suffice.
  • CocoaPods is still work in progress and there are options which don’t always lead to the same result (for example the :head and the :git options currently are not using the commits stored in the Podfile.lock).
  • There are less points of failure if you might resume work on a project after a medium/long amount of time.
Fabio
  • 3,466
  • 1
  • 20
  • 15
  • 6
    Why bother keeping the workspace file? It's generated by Cocoapods anyway. – fatuhoku Mar 23 '14 at 09:22
  • 1
    @fatuhoku For Cocoapods-blind continuous-integration test servers, in my experience. I check it all in because I don't have access to the build script for my CI host (business rule) and treat CocoaPods as a developer tool, not a build system or package manager. – codepoet May 05 '14 at 15:58
  • 2
    ./Pod folder should NOT be kept under source control (it is auto generated) by CocoaPods. Pods folder is an artefact of the build process. The workspace can also be removed from source control unless it has other projects not managed with CocoaPods. – Vlad Oct 19 '15 at 03:03
  • 1
    I think it should be checked in because it's a pain to do a pod install everytime I do a pull. – mskw Dec 23 '15 at 15:09
67

.gitignore file

No answer actually offers a .gitignore, so here are two flavors.

Checking in the Pods directory (Benefits)

Xcode/iOS friendly git ignore, skipping Mac OS system files, Xcode, builds, other repositories and backups.

.gitignore:

# Mac OS X Finder
.DS_Store

# Private Keys
*.pem

# Xcode legacy
*.mode1
*.mode1v3
*.mode2v3
*.perspective
*.perspectivev3
*.pbxuser

# Xcode
xcuserdata/
project.xcworkspace/
DerivedData/

# build products
build/
*.[oa]

# repositories
.hg
.svn
CVS

# automatic backup files
*~.nib
*.swp
*~
*(Autosaved).rtfd/
Backup[ ]of[ ]*.pages/
Backup[ ]of[ ]*.key/
Backup[ ]of[ ]*.numbers/

Ignoring the Pods directory (Benefits)

.gitignore: (append to previous list)

# Cocoapods
Pods/

Whether or not you check in the Pods directory, the Podfile and Podfile.lock should always be kept under version control.

If Pods are not checked-in, your Podfile should probably request explicit version numbers for each Cocoapod. Cocoapods.org discussion here.

Community
  • 1
  • 1
SwiftArchitect
  • 47,376
  • 28
  • 140
  • 179
  • Pods are a dependency. Adding the above # Cocoapods /n Pods/ This is the best answer. This will make it more like a package. The package holds a version. Set the version in the PodFile if you need to lock it down. – Matthew Ferguson Aug 21 '21 at 10:02
39

I generally work on app’s of clients. In that case I add the Pods directory to the repo as well, to ensure that at any given time any developer could do a checkout and build and run.

If it were an app of our own, I would probably exclude the Pods directory until I won’t be working on it for a while.

Actually, I must conclude I might not be the best person to answer your question, versus views of pure users :) I’ll tweet about this question from https://twitter.com/CocoaPodsOrg.

alloy
  • 20,908
  • 2
  • 30
  • 40
  • I'd echo this as well. You can use CocoaPods without your other developers needing to use it (although they should) by checking in the Pods folder. Once CocoaPods becomes ubiquitous, pods will be similar to gems, you'd check them in in the same cases you'd "vendor" ruby gems. – Ben Scheirman Feb 26 '12 at 16:31
  • 2
    I think one have also to consider that sometime pods or pod utility(the good version) may not available. Even more, if two users with different pod utility version run the utility for exactly the same Podspec, the output might differ. – Adrian Mar 14 '13 at 16:53
  • 1
    Checkout, build and run is the most important consideration. Why would you make your build, and ability to build dependent on any external factors? I check in all pods. You might save other developers (or your future self) hours of searching for the correct pods. I don't see any downsides to checking them in either. – n13 Jun 23 '15 at 07:16
20

I check in everything. (Pods/ and Podfile.lock.)

I want to be able to clone the repository and know that everything will just work as it did last time I used the app.

I'd rather vendor things in than risk having different results that could be caused by a different version of the gem, or someone rewriting history in the Pod's repository, etc.

funroll
  • 35,925
  • 7
  • 54
  • 59
  • 4
    The other nice thing about doing this is after an update, you can look at the diff before checking in and see exactly what files in the pods changed. – funroll Feb 13 '14 at 22:05
  • 2
    Additionally, your project doesn't require all of your developers to have CocoaPods installed (which can be a good thing if you want to control who/how dependencies are added and updated). – Tony Arnold Mar 18 '14 at 11:52
19

The answer for this is given directly in Cocoapod docs. You may look at "http://guides.cocoapods.org/using/using-cocoapods.html#should-i-ignore-the-pods-directory-in-source-control"

Whether or not you check in your Pods folder is up to you, as workflows vary from project to project. We recommend that you keep the Pods directory under source control, and don't add it to your .gitignore. But ultimately this decision is up to you:

Benefits of checking in the Pods directory

  • After cloning the repo, the project can immediately build and run, even without having CocoaPods installed on the machine. There is no need to run pod install, and no Internet connection is necessary.
  • The Pod artifacts (code/libraries) are always available, even if the source of a Pod (e.g. GitHub) were to go down.
  • The Pod artifacts are guaranteed to be identical to those in the original installation after cloning the repo.

Benefits of ignoring the Pods directory

  • The source control repo will be smaller and take up less space.

  • As long as the sources (e.g. GitHub) for all Pods are available, CocoaPods is generally able to recreate the same installation. (Technically there is no guarantee that running pod install will fetch and recreate identical artifacts when not using a commit SHA in the Podfile. This is especially true when using zip files in the Podfile.)

  • There won't be any conflicts to deal with when performing source control operations, such as merging branches with different Pod versions.

Whether or not you check in the Pods directory, the Podfile and Podfile.lock should always be kept under version control.

shah1988
  • 2,584
  • 1
  • 19
  • 21
13

I'm in the camp of developers who do not check in libraries, assuming we have a good copy available in another location. So, in my .gitignore I include the following lines specific to CocoaPods:

Pods/
#Podfile.lock  # changed my mind on Podfile.lock

Then I make sure that we have a copy of the libraries in a safe location. Rather than (mis-)use a project's code repository to store dependencies (compiled or not) I think the best way to do this is to archive builds. If you use a CI server for your builds (such as Jenkins) you can permanently archive any builds that are important to you. If you do all your production builds in your local Xcode, make a habit of taking an archive of your project for any builds you need to keep. Something like: 1. Product --> Archive

  1. Distribute... Submit to the iOS App Store / Save for Enterprise or Ad-hoc Deployment / what have you

  2. Reveal your project folder in Finder

  3. Right click and Compress "WhateverProject"

This provides an as-built image of the entire project, including the complete project and workspace settings used to build the app as well as binary distributions (such as Sparkle, proprietary SDKs such as TestFlight, etc.) whether or not they use CocoaPods.

Update: I've changed my mind on this and now do commit the Podfile.lock to source control. However, I still believe that the pods themselves are build artifacts and should be managed as such outside of source control, through another method such as your CI server or an archive process like I describe above.

Alex Nauda
  • 4,126
  • 1
  • 24
  • 24
  • 24
    Cocoapods specifically recommends checking in `Podfile.lock`: http://docs.cocoapods.org/guides/working_with_teams.html – cbowns Oct 11 '13 at 01:36
  • Interesting. Since `Podfile.lock` bakes in paths to local pods, I hadn't considered adding it to version control. However, now that I think about it, it's not different from the local changes I make in `Podfile` but never commit. Thanks for pointing this out. – Alex Nauda Oct 11 '13 at 13:53
  • Has that working with teams link changed? It mentions nothing about the `Podfile.lock` file. – ingh.am Dec 12 '13 at 17:26
  • 4
    @ing0 I think the new link is [this one](http://guides.cocoapods.org/using/using-cocoapods.html) – phi Dec 13 '13 at 03:50
  • The advantage of checking in Podfile.lock is that it's obvious if any of your pods or their dependencies have been upgraded. – Tim Potter Dec 17 '13 at 23:44
  • Cocoapods recommendation: _This file should always be kept under version control._ http://guides.cocoapods.org/using/using-cocoapods.html – djserva Mar 07 '14 at 14:36
  • I think you're making a mistake by not checking in the Pods directory — there's a real danger that the repositories referred to by your Podfile/Podspecs will be moved or deleted. If this happens, your project is effectively useless. I'd argue that they're not build artefacts: they're necessary components of your project. I prefer to check everything (`Podfile`/`Podfile.lock`/`Pods`) in to version control — this has the nice side effect of allowing me to review changes made by `pod update` before committing them to the project, but also means my project always compiles (even without CocoaPods). – Tony Arnold Mar 18 '14 at 11:50
  • I'm starting to change my mind as well — actually. For some reason or other, my `pod` command isn't working because some git command is taking long and isn't completing on time. For all this time that `pod` doesn't work, I'm stuck and cannot even build the project. Committing all the sources is a good idea because it does really speed up switching between branches. – fatuhoku Apr 01 '14 at 21:21
  • @TonyArnold The "real danger" that referenced repositories disappear is exactly why I recommend archiving the entire build as part of your release process. As for checking in the Pods directory, I see two problems with that: 1. It's really not convenient if you often use :path to refer to development versions of internal CocoaPods. 2. It could encourage someone to maintain the checked-in pods' code directly in the project codebase, rather than branching or forking the pod repo as they should. This could be particularly error-prone if you already maintain internal forks of public repos. – Alex Nauda Apr 02 '14 at 01:39
  • Totally disagree with this. In order to understand code and fix bugs, you need the entire source, or as much of it as possible. You want to eliminate as many variables as possible; having the exact Pod version that was used for building is essential. As for your argument against, (2): If developers modify pods (bad!), then that would be a much worse problem when you have *not* checked in the pod. Then that code might just be on that developers machine... good luck with that. – n13 Jun 23 '15 at 09:18
  • @n13 If you're relying on GitHub (or another VCS) for all of your dependency management, what do you do about binary dependencies such as Crashlytics or Sparkle? And do you also have internal pods that are now copied into every single repo that uses them? What about test-specific schemes that include a differing set of dependencies specific to automated testing? What I'm advocating is that there is an alternative way to manage dependencies, outside of GitHub, in your build process and/or your CI system. Once our dependency tree grew moderately complex, we found this to be a better option. – Alex Nauda Jun 23 '15 at 15:00
  • @AlexNauda: Binary dependencies, internal pods are checked in for the same reason. A new developer must be able to check out and do a build. That new developer might be yourself a few months down the road. For automated testing with different sets of dependencies, I'd check them in, too? There's no harm in it. No essential part of the project can be local on one developers machine. And if you're using some kind of sharing, git is as good as any (vs dropbox, your build server, whatever). – n13 Jun 26 '15 at 01:13
11

I prefer committing Pods directory along with Podfile and Podfile.lock to make sure anyone in my team can checkout the source anytime and they don't have to worry about anything or do additional stuff to make it work.

This also helps in a scenario where you have fixed a bug inside one of the pods or modified some behaviour as per your needs but these changes will not be available on other machines if not committed.

And to ignore unnecessary directories:

xcuserdata/
nomann
  • 2,257
  • 2
  • 21
  • 24
10

I must say, I am a fan of committing Pods to the repository. Following a link already mentioned will give you a good .gitignore file to get up your Xcode projects for iOS to allow for Pods but also for you to easily exclude them if you so wish: https://github.com/github/gitignore/blob/master/Objective-C.gitignore

My reasoning for being a fan of adding Pods to the repository is for one fundamental reason which no one seems to be picking up on, what happens if a library which our project is so dependant upon is suddenly removed from the web?

  • Maybe the host decides they no longer want to keep their GitHub account open What happens if the library is say several years old (like older than 5 years for example) there is a high risk the project may no longer be available at source
  • Also another point, what happens if the URL to the repository changes? Lets say the person serving the Pod from their GitHub account, decides to represent themselves under a different handle - your Pods URLs are going to break.
  • Finally another point. Say if you're a developer like me who does a lot of coding when on a flight between countries. I do a quick pull on the 'master' branch, do a pod install on that branch, while sitting in the airport and have myself all set for the upcoming 8 hour flight. I get 3 hours into my flight, and realise I need to switch to another branch.... 'DOH' - missing Pod information which is only available on the 'master' branch.

NB... please note the 'master' branch for development is just for examples, obviously 'master' branches in version control systems, should be kept clean and deployable/buildable at any time

I think from these, snapshots in your code repositories are certainly better than being strict on repository size. And as already mentioned, the podfile.lock file - while version controlled will give you a good history of your Pod versions.

At the end of the day, if you have a pressing deadline, a tight budget, time is of the essence - we need to be as resourceful as possible and not waste time on strict ideologies, and instead harness a set of tools to work together - to make our lives easier more efficient.

leewilson86
  • 101
  • 1
  • 4
  • 2
    This is one of the best answers to the "Do I check my dependencies in to source control" ageless question. First, you explain an actual concrete, risk-based, business justification for your reasoning. Secondly, you remind everyone that at the end of the day, the best solution is whatever gets the job done and gets people working together. You remove the religion from the equation. Nice job! – Brandon Apr 23 '15 at 00:51
9

It depends, personally:

Why pods should be part of the repo (under source control) and should not be ignored

  • The source is identical
  • You can build it right away as is (even without the cocoapods)
  • Even if a pod is deleted, we still have its copy (Yes, this can happen and it did. In an old project where you want just a small change you would need to implement a new library to be able to even build).
  • pods.xcodeproj settings are part of the source control as well. This means e.g. if you have the project in swift 4, but some pods must be in swift 3.2 because they are not updated yet, these settings will be saved. Otherwise the one who cloned the repo would end up with errors.
  • You can always delete pods from the project and run pod install, the opposite can not be done.
  • Even the authors of the Cocoapods recommend it.

Some cons: larger repository, confusing diffs (mainly for team members), potentially more conflicts.

Jakub Truhlář
  • 20,070
  • 9
  • 74
  • 84
8

At the end is up to you the approach you take.

This is what Cocoapods team thinks about it:

Whether or not you check in your Pods folder is up to you, as workflows vary from project to project. We recommend that you keep the Pods directory under source control, and don't add it to your .gitignore. But ultimately this decision is up to you.

Personally I'd like to keep Pods out, as node_modules if I were using Node or bower_components if I were using Bower. This apply for almost any Dependency Manager out there, and is the philosophy behind git submodules aswell.

However there are sometimes that you might want to be really sure about the state-of-art of a certain dependency, that way you are carry own the dependency within your project. Of-course there are several drawbacks that apply if you do that, but concerns do not only apply to Cocoapods, those applies to any Dependency Manager out there.

Below there is a good pros/cons list made by Cocoapods team, and the full text of the quote mentioned previously.

Cocoapods team: Should I check the Pods directory into source control?

zevarito
  • 362
  • 4
  • 9
8

Pros of not checking in Pods/ to version control (in subjective order of importance):

  1. Much easier to merge commits, and review code diffs. Merging is a common source of issues in a code base, and this allows you to focus only on things that are pertinent.
  2. It's impossible for some random contributor to edit the dependencies themselves and check the changes in, which they should never do (and again would be hard to identify if the diff is massive). Editing dependencies is very bad practice because a future pod install could occlude the changes.
  3. Discrepancies between the Podfile and the Pods/ directory are found quicker among teammates. If you check in Pods/ and, for example, update a version in the Podfile, but forget to run pod install or check in the changes to Pods/, you will have a much harder time noticing the source of the discrepancy. If Pods/ isn't checked in, you always need to run pod install anyway.
  4. Smaller repo size. Having a smaller byte-footprint is nice, but that doesn't matter much in the grand scheme. More importantly: having more things in the repo also increases your cognitive load. There is no reason to have things in the repo that you shouldn't be looking at. Refer to documentation (the abstraction) to know how something works, not at code (the implementation).
  5. Easier to discern how much someone contributes (since their lines of code contributed won't include dependencies they didn't write)
  6. JAR files, .venv/ (virtual environments), and node_modules/ are never included in version control. If we were completely agnostic about the question, not checking in Pods would be the default based on precedent.

Cons of not checking in the Pods/

  1. You must run pod install when switching branches, or reverting commits.
  2. You can't run a project just by cloning the repository. You must install the pod tool, then run pod install.
  3. You must have an internet connection to run pod install, and the source of the pods must be available.
  4. If the owner of a dependency removes their package, you can't use it (though you shouldn't be using a deprecated dependency in the first place - this just forces you to have dependency hygiene earlier).

In summary, not including the Pods directory is a guardrail against more bad practices. Including the Pods directory makes running the project easier. I prefer the former over the latter. You won't need to debrief every new person on a project about "what not to do" if there is not a possibility for making certain mistakes in the first place. I also like the idea of having a separate version control for the Pods which alleviates the Cons.

efthimio
  • 592
  • 5
  • 19
3

To me, the biggest concern is future proofing your source. If you plan to have your project last for a while and CocoaPods ever goes away or the source of one of the pods goes down, you're completely out of luck if trying to build fresh from an archive.

This could be mitigated with periodic full source archivals.

Shawn
  • 416
  • 5
  • 18
2

Check in the Pods.

I think this should be a tenet of software development

  • All builds must be reproducible
  • The only way to ensure builds are reproducible is to be in control of all dependencies; checking in all dependencies is therefore a must.
  • A new developer starting from scratch shall be able to check out your project and start working.

Why?

CocoaPods or any other external libraries might change which might break things. Or they might move, or be renamed, or be removed altogether. You can't rely on the internet to store things for you. Your laptop might have died and there is a critical bug in production that needs to be fixed. The main developer might get hit by a bus and his replacement has to start up in a hurry. And I wish that last one was a theoretical example but it actually happened at a startup I was with. RIP.

Now, realistically, you can't really check in ALL dependencies. You can't check in an image of the machine you used to create builds; you can't check in the exact version of the compiler. And so on. There are realistic limits. But check in all you can - not doing so just makes your life harder. And we don't want that.

Final word: Pods are not build artifacts. Build artifacts are what gets generated from your builds. Your build uses Pods, not generate them. I'm not even sure why this has to be debated.

n13
  • 6,843
  • 53
  • 40
2

TL;DR: when you track the Pods/ folder, the project is easier to pick up from. When you don't track it, it's easier to improve on when you work in a team.

Although the Cocoapods organization encourage us to track the Pods/ directory, they say it's up to the devs to decide whether or not to do it based on these pros and cons: http://guides.cocoapods.org/using/using-cocoapods.html#should-i-check-the-pods-directory-into-source-control

Personally, I usually track the Pods/ folder just for projects that I won’t be working on anymore for a while. That way any developer can quickly pick up from it and continue the work using the proper version of the cocoapods.

On the other hand, I think the commit history gets cleaner and its easier to merge the code and review another person's code when you are not tracking the Pods/ folder. I usually set the cocoapod library's version when I install it to make sure anyone can install the project using the same versions as I.

Also, when the Pods/ directory is being tracked all the devs have to use the same version of Cocoapods to prevent it from changing dozens of files every time we run pod install to add/remove a pod.

Bottom line: when you track the Pods/ folder, the project is easier to pick up from. When you don't track it, it's easier to improve on.

marcelosalloum
  • 3,481
  • 4
  • 39
  • 63
1

In theory, you should check in the Pods directory. In practice, it is not always going to work. Many pods well exceed the size limit of github files so if you are using github you are going to have issues checking in the Pods directory.

Matt
  • 688
  • 5
  • 15
0

Seems like a good way to structure this really would be to have the "Pods" directory as a git submodule / separate project, here's why.

  • Having pods in your project repo, when working with several developers, can cause VERY LARGE diffs in pull requests where it's nearly impossible to see the actual work that was changed by people (think several hundreds to thousands of files changed for libraries, and only a few changed in the actual project).

  • I see the issue of not committing anything to git, as the person owning the library could take it down at any time and you're essentially SOL, this also solves that.

jaredpetker
  • 560
  • 5
  • 8
0

Whether or not you check in your Pods folder is up to you, as workflows vary from project to project. We recommend that you keep the Pods directory under source control, and don't add it to your .gitignore. But ultimately this decision is up to you:

Benefits of checking in the Pods directory

  1. After cloning the repo, the project can immediately build and run, even without having CocoaPods installed on the machine. There is no need to run pod install, and no Internet connection is necessary.
  2. The Pod artifacts (code/libraries) are always available, even if the source of a Pod (e.g. GitHub) were to go down.
  3. The Pod artifacts are guaranteed to be identical to those in the original installation after cloning the repo.

Benefits of ignoring the Pods directory

  1. The source control repo will be smaller and take up less space. As long as the sources (e.g. GitHub) for all Pods are available, CocoaPods is generally able to recreate the same installation.(Technically there is no guarantee that running pod install will fetch and recreate identical artifacts when not using a commit SHA in the Podfile. This is especially true when using zip files in the Podfile.)
  2. There won't be any conflicts to deal with when performing source control operations, such as merging branches with different Pod versions. Whether or not you check in the Pods directory, the Podfile and Podfile.lock should always be kept under version control.
Sourabh Mahna
  • 52
  • 4
  • You can use this link for any doubt: http://guides.cocoapods.org/using/using-cocoapods.html#should-i-ignore-the-pods-directory-in-source-control – Sourabh Mahna Jul 23 '15 at 09:36
0

You should remove pods from git and then gitignore will work..

git rm -rf --cached ios/Pods
jamal zare
  • 1,037
  • 12
  • 13