xcode/cocoapods .gitignore

.gitignore

# Xcode
build/*
*.pbxuser
!default.pbxuser
*.mode1v3
!default.mode1v3
*.mode2v3
!default.mode2v3
*.perspectivev3
!default.perspectivev3
*.xcworkspace
!default.xcworkspace
xcuserdata
profile
*.moved-aside

docset-installed.txt
.DS_Store

Podfile.lock

Hi there! Why did you track the Pods folder and not track the Podfile.lock? I would have done the opposite... The lockfile is used to keep the pods version even across the developers, so everyone should have the same. The Pods folder is just a containers for pods that should be downloaded with the pod install so there's no need to add it to the repo. Am I correct? Please explain :)

@mokagio if you track the Pods folder, then you can easily checkout a commit and build it as-is. If you don't track Pods, then you need to run pod install first, which is not guaranteed to give you the same result independent of time.

Podfile.lock is supposed to guarantee the same resulting deployment.
I have the same opinion than @mokagio, I think the dependencies of a project should not be included into it.

If cocoapods is based on bundle in the Ruby world, you most definitely want to check in the .lock file and most definitely DON'T want to check in the Pods folder.

I agree, same goes for Composer and pretty much every other dependancy management platform. If you're committing the Pods directory and not the lock file it defeats the point in having dependancy management. The lock file will check to make sure for example the same commit for that project is checked out between developers and build environments rather than just the version number.

Why commit the Podfile.lock file? Isn't it better to be more specific in the Podfile? Why do you need two separate files to declare your dependancies?

@sibljon "you need to run pod install first, which is not guaranteed to give you the same result independent of time" - how can this be true? Isn't this the point of dependancy management! I want to be able to clearly state what my app depends on, including exact versions if required, and have pod install give identical results at any point in the future. Can Cocoapods do this? Or is there something I'm missing?

Honestly I just threw this up here as a gist to see if it would inspire more heated discussion than any of the apps I've ever released (sigh).

Nah -- it's copied from somewhere else. Actually from whatever GitHub's official recommendation was at the time, I think.

But I can justify it nevertheless: I've come to mistrust CocoaPods rather deeply, especially as 1) I'm too busy to keep an eye on the CHANGELOG, and 2) CocoaPods seems to be in very rapid development. As a result, I wind up screwing things up all the time -- writing incorrect podspecs that don't jive with the current podspec DSL quite right, etc. And so pods do occasionally get overwritten when they shouldn't.

Consequently, given that clients can be demanding, vicious reptiles, I like to track the exact state of my projects/workspaces so that if someone needs a hotfix and it's 4am on a Wednesday, I can just do it and get back to not worrying about other people. As much.

However, if you have a sane job where it's more important to write correct code and manage dependencies the Right Way, you can tl;dr this whole post. You should .gitignore Pods/ fa'sho. I can't believe you get paid for that shit, though. Shame that I don't see a single pod ' ... ', :head in that sissy little Podfile of yours.