Latest FBAudienceNetwork podspec is excluding the arm64 arch for simulators about facebook-ios-sdk

[andrewdmontgomery]

We had reverted to 6.12.0 to mitigate this. In our case, we were seeing flapping on various PR's:

1. One person would run pod install on our repo and it would add arm64
2. Someone else would do the same, but it would remove it
3. etc

I've finally had a chance to dig into this, though, and I noticed something interesting about the public podspec repo – it looks like the FBAudienceNetwork.podspec.json for 6.14.0 had more than one commit:

https://github.com/CocoaPods/Specs/commits/master/Specs/2/1/5/FBAudienceNetwork/6.14.0/FBAudienceNetwork.podspec.json

The first commit had the exclusions as you are seeing. Then the podspec was removed and re-added... with the arm64 exclusion removed.

After going back through our git blame, I figured out that the flapping was always the same people adding, and always the same people removing. That feels like a problem that is local to the workstation. So I tracked down one of the adders, and we started debugging.

Sure enough, the people whose PR's were adding arm64 had the old version of the 6.14.0 podspec.

Try removing the locally cached podspecs in the trunk repo:

rm -rf ~/.cocoapods/repos/trunk
pod install

After that, you can confirm that your local FBAudienceNetwork.podspec.json is now correct:

# Get the path to the podspec
pod spec which FBAudienceNetwork

We're going to communicate to our developers to delete their local trunk directory and run pod install. Then we'll likely update to 6.14.0 again.

[andrewdmontgomery]

A bit surprisingly, at least to me, updating the repos doesn't fix this:

pod repo update

Should it? At first, the CocoaPods guide suggests that this kind of update to an existing podspec might be allowed:
https://guides.cocoapods.org/making/specs-and-specs-repo.html

In general this means that:

• A specification cannot be deleted.
• Specifications can be updated only if they don't affect existing installations.
  • Broken specifications can be updated.
  • Subspecs can be added as they are included by the parent specification by default.
• Only authoritative versions are accepted.

"Broken specifications can be updated", but with the caveat "only if they don't affect existing installations". But in this case, that caveat is the problem. Existing installations are broken.

Should this have been a new version? Or does CocoaPods need to be smarter about updating the trunk repo?

[andrewdmontgomery]

Given that CocoaPods' implementation (version 1.14.2) doesn't seem to support updating an existing locally cached podspecs when there is a new commit on the same version of the spec, I think the right solution here is to bump the version in the podspec: 6.14.1

Edit: it may be a bug with CocoaPods' ability to detect updated resources in the trunk. CocoaPods uses etags to track which trunk resources are out of date and need to be synced locally. So in theory, at least, I would expect it to be able to update locally cached Specs that have changed, even if an existing Spec is updated. But since pod repo update wasn't working for those on my team that were affected, something is amiss.