fix(ios): ignore Podfile.lock

[devinshoemaker]

It seems appropriate to ignore ios/App/Podfile.lock. Podfile.lock is generated when npx cap update ios is executed, and the file is updated based on the host system (cocoapods version).

[jcesarmobile]

Looks good to me, it's deleted and regenerated on every npx cap update so can be safely gitignored

[laurentgoudet]

Sorry if it's a dumb question, but I'm a bit confused by that as the CocoaPods docs explicitly state that:

Whether or not you check in the Pods directory, the Podfile and Podfile.lock should always be kept under version control.
https://guides.cocoapods.org/using/using-cocoapods.html

If the lock file is indeed deleted and regenerated on every npx cap update, what guarantees the reproducibility of the builds?

Thanks!

[jcesarmobile]

Capacitor and capacitor plugins are really installed from npm, so the reproducibility should be guaranteed from package-lock.json instead. CocoaPods sees them as local packages.
As far as I remember, the removal of the Podfile.lock was because of some problems on pod install with this local packages. Might be fixed by now.

But if the plugins have CocoaPods dependencies, then there isn’t guaranteed reproducibility, in that case it would be better if plugins pin a specific version.
We recently added the —deployment flag that doesn’t delete Podfile.lock for such cases

#2222

[barry-jones]

Is this true for child dependencies. E.g. I use capacitor-admob which has a dependency on Google-Mobile-Ads-Sdk. Its pod spec does not specify a value for the dependency, but the podfile.lock in the ios directory does. When using npx cap sync ios it gets the incorrect version. Only when the pod spec defines the version does it get the correct one.

Is this expected behaviour.

p.s. I know that plugin is outdated, but it is one I have had a problem with.

[jcesarmobile]

You can use the —deployment flag and then don’t ignore the Podfile.lock if you want to keep fixed dependencies of dependencies.