Of course in normal Xcode projects, Podfile.lock should always be checked in to version control. However, Flutter's iOS runner app isn't a "normal" Xcode project (in the sense that it's managed by Flutter and rarely touched by developers).
Flutter uses Cocoapods and our team noticed that the Podfile.lock contains references to full paths on the developer's machine. However, this doens't cause any direct issues since, apparently, the Podfile.lock is regenerated every time you build/run the Flutter app and the full paths are changed to whatever the path is on your machine. Also, deleting Podfile.lock doesn't cause any harm because it's automatically generated anyway.
The thing is that it causes annoying merge conflicts in git that have to be resolved every single time. Since it's automatically generated, I wonder if in this case it's really necessary to check it into version control or if it's safe to just ignore the file in .gitignore.
There is more debate about this on Github, however I can't seem to find a definitive answer there.
—edit— For clarification: I know what Podfile.lock is for, I’m just not sure if my assumption that Flutter overrides it is correct.
The reason for checking the Podfile.lock
in is so the app developer can exactly recreate and share a Pod configuration across a team. Without checking in the Podfile.lock
, developers on the same team will get different versions of pods depending upon when they do pod install
.
If flutter is overriding the Podfile.lock
functionality, there would be no reason to check it in.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With