How to Remove CocoaPods From an Xcode Project (Keep One .xcodeproj)

Why this happens

CocoaPods has no single “uninstall” switch in the core gem. When you run pod install, it edits your .xcodeproj in several places at once: it attaches Pods-<Target>.debug.xcconfig and Pods-<Target>.release.xcconfig as the base configurations, links libPods-<Target>.a (or Pods_<Target>.framework when the Podfile uses use_frameworks!), and adds three build phases — [CP] Check Pods Manifest.lock, [CP] Embed Pods Frameworks and [CP] Copy Pods Resources. It also generates a .xcworkspace that wraps your project together with Pods.xcodeproj.

That is why deleting the Pods folder and the workspace is not enough. The project file still points at a missing xcconfig and a missing library, so the next build fails with something like ld: library not found for -lPods-<Target> or error: Build input file cannot be found. The workspace is a generated artifact; the real edits live inside the .xcodeproj.

The integration is fully reversible. You can either let a plugin reverse the edits for you, or do the same edits by hand.

How to fix it

1. Use pod deintegrate (fastest and safest)

cocoapods-deintegrate is a plugin written by a member of the CocoaPods core team that undoes the project edits. Commit or stash your work first, close Xcode, then run everything from the folder that contains the .xcodeproj:

sudo gem install cocoapods-deintegrate cocoapods-clean

cd /path/to/YourProject
pod deintegrate
pod cache clean --all

rm -rf Pods
rm -f Podfile Podfile.lock
rm -rf YourProject.xcworkspace

pod deintegrate only reverses the changes to the Xcode project. It leaves Podfile, Podfile.lock and the Pods/ directory in place, which is why you delete them yourself in the same pass. If the folder holds more than one project, point the command at the right one explicitly:

pod deintegrate YourProject.xcodeproj

Afterwards open YourProject.xcodeproj — not the workspace — and build.

2. Verify nothing is left behind

A deintegrate that half-worked shows up as a linker error later. Check three places in the project:

• Build Settings — search for Pods. Framework Search Paths, Header Search Paths, Library Search Paths and Other Linker Flags should contain no Pods paths.
• Build Phases — no [CP] phases, and no libPods or Pods_ entry under Link Binary With Libraries.
• Project navigator — no Pods group and no Pods.xcconfig reference.

A quick text check on the project file is faster than clicking around:

grep -n "Pods" YourProject.xcodeproj/project.pbxproj

No output means the project file is clean. Then remove the imports that came from the pods — #import <SomePod/SomePod.h> in Objective-C, import SomePod in Swift, and the matching lines in your bridging header. If stale errors survive a clean build, clear DerivedData:

rm -rf ~/Library/Developer/Xcode/DerivedData

3. Do it manually if the plugin will not install

If gem install fails because of a locked-down system Ruby or a corporate proxy, the same edits can be made by hand. Commit first — a wrong click here can damage the project file.

1. Delete Podfile, Podfile.lock, the Pods/ directory and the generated .xcworkspace.
2. Open the .xcodeproj and remove the Pods group and the Pods.xcconfig file reference from the navigator.
3. Select the project, open Info ▸ Configurations, and set the base configuration back to None for both Debug and Release. This is where the Pods-<Target> xcconfig files were attached.
4. In Build Phases, delete [CP] Check Pods Manifest.lock, [CP] Embed Pods Frameworks and [CP] Copy Pods Resources. In older CocoaPods releases the same phases appear without the [CP] prefix.
5. Under Link Binary With Libraries, remove libPods-<Target>.a or Pods_<Target>.framework.
6. Bring the third-party code in some other way, or delete the code that referenced it.

Step 3 is the one people skip. Leaving a base configuration pointing at a deleted xcconfig produces confusing warnings about missing files long after the Pods folder is gone.

4. If you only need to get rid of the workspace

If the actual constraint is “one .xcodeproj, no .xcworkspace“, you do not have to remove CocoaPods at all. pod install --no-integrate generates Pods.xcodeproj without creating a workspace; you then add that project as a subproject of your own and link the products yourself. The trade-off is that you lose the automatic xcconfig wiring, so header search paths and linker flags become your responsibility. For most projects that is more work than switching the dependency to Swift Package Manager.

5. Replace the dependency

Removing CocoaPods removes the pod source code with it. Before you delete Pods/, decide where each library goes: a Swift package added through File ▸ Add Package Dependencies, a prebuilt XCFramework, or vendored source checked into the repo. Your code will not compile until the imports resolve again.

How to prevent it

• Commit or branch before running pod deintegrate or editing the project file by hand, so a bad edit is one git checkout away.
• Never delete Pods/ on its own while the project still references it — deintegrate first, delete second.
• Keep Podfile.lock in source control for as long as you use CocoaPods, so a re-install reproduces the same versions.
• Build both Debug and Release after removal; the base configuration is set per configuration, so one can be clean while the other still points at Pods.
• If a client forbids workspaces, pick Swift Package Manager before the first pod is added rather than migrating later.

FAQ

Does pod deintegrate delete my Podfile and Pods folder?

No. It only reverses the changes made to the .xcodeproj. Podfile, Podfile.lock, Pods/ and the .xcworkspace are yours to delete afterwards.

Can I undo the removal?

Yes, as long as you still have the Podfile (or can restore it from git). Run pod install again and the xcconfig, library link and build phases are recreated.

Will my project still compile after removing CocoaPods?

Only once every pod import is gone or replaced. Removing the integration does not remove the import SomePod lines in your source, so expect No such module errors until each dependency is provided another way.