CocoaPods Errors on Project Build

I'm unable to build a project that uses CocoaPods. I get the following errors:

diff: /../Podfile.lock: No such file or directory
diff: Manifest.lock: No such file or directory error: 
The sandbox is not in sync with the Podfile.lock. Run 'pod install' or update your CocoaPods installation.`

$ pod install seems to work fine and adds a Pods Project to my Workspace. I've tried $ pod update but this doesn't help.

It seems that PODS_ROOT is not being set.

Podfile:

platform :ios, '6.0'

workspace 'Example.xcworkspace'
xcodeproj 'example/Example.xcodeproj' 

pod 'TestFlightSDK', '~> 1.3.0-beta.5'
pod 'TestFlightLogger', '~> 0.0.2'
pod 'CocoaLumberjack', '~> 1.6.2'
pod 'Reachability', '~> 3.1.0'
pod 'SBJson', '~> 3.2'
pod 'MKMapViewZoom', '~> 1.0.0'

I had a similar problem when I did major changes to my Podfile. My solution was to remove the workspace file and run pod install again:

rm -rf MyProject.xcworkspace
pod install

TLDR: This is most likely a bug with Xcode and closing and reopening the project is usually the simplest fix. Assuming everything else is configured properly.

I occasionally get the same error when deleting the Pods directory and then running pod install.

Everything appears correct in the project info:

However, when I go to the target's User-Defined Build Settings, the PODS_ROOT entry is either entirely missing or is empty for one or more configurations. Which causes the following error on build:

The simplest fix is to close the project in Xcode and reopen it.

If you go to the target's Build Settings and filter on All, you will now see the PODS_ROOT entry with no errors:

It should now build with no errors.

Note: Even Cocoa Pods' official AFNetworking iOS Example has this problem, which leads me to believe that it is a bug with Xcode.

An alternative fix is to manually change the configuration to None, then back to its original value:

Go to the target's Build Settings and make sure the value of PODS_ROOT equals ${SRCROOT}/Pods in "User-Defined" section.

update: a podfile.lock is necessary and should not be ignored by version control, it keeps track of the versions of libraries installed at a certain pod install. (It's similar to gemfile.lock and composer.lock for rails and php dependency management, respectively). To learn more please read the docs. Credit goes to cbowns.

In my case, what I did was that I was doing some house cleaning for my project (ie branching out the integration tests as a git submodule.. removing duplicate files etc).. and pushed the final result to a git remote repo.. all the clients who cloned my repo suffered from the above error. Inspired by Hlung's comment above, I realized that there were some dangling pod scripts that were attempting to run against some non-existent files. So I went to my target build phase, and deleted all the remaining phases that had anything to do with cocoa pods (and Hlung's comment he suggests deleting Copy Pods Manifest.lock and copy pod resources.. mine were named different maybe b/c I'm using Xcode 5.. the point being is to delete those dangling build phases)..