SUZIE: Dad, I need your help.
TODD: Why sure, Suzie, what's on your mind?
SUZIE: I have two tickets to The Wallabies concert this weekend,
and I don't know who to invite.
I was thinking maybe Laura because she's new in town.
But Pamela's been my best friend since forever,
except that she's been ignoring me ever since she started
going steady with Johnny.
TODD: Well, here's the thing about friendships.
Friendships are sort of like gift baskets.
Each one has its own unique set of, umm, OK look,
I was really kind of hoping this was going
to be a CocoaPods question.
Do you have one of those for me?
SUZIE: You're not a very good father.
TODD: I know.
But seriously, CocoaPods, hit me.
SUZIE: Well, now that you mention it,
I've been noticing these Podfile.lockfiles
in my project.
What are those?
TODD: Ah, so this is a question I can answer.
So don't let that lock name confuse you.
It's not like there's another CocoaPods process somewhere
that's editing a file somewhere.
See, a CocoaPods lockfile is important in that it
keeps track of every version of every library
that CocoaPods has installed for you.
You can think of it as something like a snapshot
of exactly what CocoaPods has installed in your iOS project.
SUZIE: That doesn't seem very important.
It really just sounds like something that
would satisfy my curiosity.
TODD: Au contraire, sweetie.
See, a lockfile is very important
if you're working together with a team.
This will help you all make sure that all of your files
are in sync.
SUZIE: Really?
How?
TODD: Let's say that you and Mark are working on a project
together.
You two are still dating, right?
SUZIE: Yep.
TODD: You know how I feel about boys who put
side effects in their getters.
SUZIE: I don't really care, Dad, I love him anyway.
TODD: OK, you know what?
Let's watch this.
OK, so let's say you go ahead and add a line like this
to your Podfile.
SUZIE: Hey, that's the Twitter walker from the last video.
TODD: Aw, you watched.
Now shut up, I'm talking.
Now you run pod install.
Now let's assume the latest version
of our hypothetical library is 1.3.3,
so you'll get that version added to your project.
Now let's say a few days later, the author of the library
updates it to version 1.4.
You don't run pod update, so you're still happily plugging
away on version 1.3.3.
But now let's say Mark gets a copy of your project
and he runs pod install.
Well, without that lockfile around,
CocoaPods would just go out and install
version 1.4 on his machine.
If he starts using features that aren't in version 1.3.3,
it could break your code when you merge in his changes.
SUZIE: Dad, how does a lockfile help?
TODD: I'm getting to that, be patient.
Now on the other hand, if you have your lockfile checked
into your project, it'll record what version
you have installed.
Then when Mark runs pod install, even though version 1.4 is
out there, CocoaPods will see that-- according
to your lockfile-- your project should only
have version 1.3.3 installed, and so that's
what it'll install for Mark.
Now granted, if Mark-- being the irresponsible boy
he is who doesn't take the proper precautions--
goes out and runs pod update without telling you,
well then, yes, CocoaPods will go out and grab version 1.4.
But because that change is also reflected in the lockfile,
that will get merged in as well when you merge in Mark's code.
So at least you'll be aware that something's changed.
Oh, another nice feature of the lockfile
is that if you're tracking it in source control,
you've got a very nice snapshot of every library
you've installed at any given time.
So if things suddenly break, you can use it to jump back in time
and recreate the exact environment you had when
you checked in the log file.
SUZIE: That does seem useful.
Say, as long as we're talking about source control,
do you think that I should put my pod directory inside
of my source repository of my project?
TODD: Well, there's two schools of thought on that.
One school of thought essentially
looks at your pod directory as derived data.
As long as you have both your Podfile and your lockfile
checked into your project-- and you should-- then
anybody could, in theory, recreate that environment
at any time just by running pod install.
SUZIE: Sure, but what if you don't have CocoaPods installed?
TODD: Well, that's where the other school of thought
comes in.
They believe that because your pods directory contains
essential files needed to run your project,
you should absolutely check it in.
That way, anybody could download your entire repository
and run it, no other steps required.
SUZIE: Yeah, although that seems like it might cause
your repository to get bloated.
TODD: Well that's probably true, but hard drive space
is cheap these days.
Maybe a bigger concern might be if you end up
with merge conflicts in your pod directory,
I could see that being troublesome to fix.
SUZIE: So what should I do?
TODD: Well, that's really up to you.
The CocoaPods folks generally recommend
checking in your pods directory, but as long
as you and the rest of your team agree on the same practice,
you should be OK.
SUZIE: No, no, Dad.
I meant what should I do about The Wallabies concert?
I still don't know who to go with.
TODD: Oh, that's easy.
Go with the more popular one, duh.
SUZIE: Dad, you're so stuck in the '50s.