plugin cocoapod installation is non-deterministic

Environment
TNS 5.3.1

Describe the bug
Modern package managers give us not just the ability to install dependencies, but more critically to install dependencies deterministically. That is to say: the exact same dependencies, will be installed the exact same way, every time. No matter when the install happens.

The most common way they achieve this is by maintaining a "lock" file which contains a manifest of resolved dependencies for a given set of primary version constraints. Once checked into source control, all other environments can use the lock file to download and install the exact same set of dependencies every time. yarn, bundler, cargo, npm all have lockfiles because this is so important.

This critical dependency management feature is also available with Cocoapods. It has a lockfile called Podfile.lock. However, because of the way that pod plugins work, it appears is not captured in source control (instead it's plopped into platforms/ios which is git ignored), and so cannot be used to reliably re-create a build from source.

Some of the consequences of this:

• non-deterministic builds.
  • you might get a a different version of a cocoapod for production than you had when you ran your tests.
  • subtle bugs that are only reproducible in unique environments as developers install their dependencies at different times and end up with slightly differing versions of a cocoapod.
• difficulty in automation: In your CI environment, you always end up caching a set of dependencies that are fetched over the network, so that it will be faster, and also function in the absence of the repository service. To do that, you need a unique key, against which to store your cache. For package managers, this is the lock file. See Yarn caching on circleCI for an example. This is impossible without Podfile.lock

Expected behavior

Building a nativescript application from source always pulls the same set of dependencies, both from NPM and also from CocoaPods.

It seems to me that the simplest solution would be to maintain the Podfile somewhere in the project structure. Either in App_Resources/iOS or a version controlled platforms/ios

When a pod plugin is installed, it is ok, if it updates the Podfile to include its dependency, but then both the Podfile and the resulting Podfile.lock should be store in source control so that every developer, every CI environment, and ultimately every user, gets the same set of cocoapods every single time for a give version of the app in git.

No files, tests, or entry points are named. Start by tracing plugin installation and the iOS build path, then determine where the Podfile and Podfile.lock should live; done means a source checkout reproducibly installs the same CocoaPods dependencies across local and CI builds.