CocoaPods
.gitignore
iOS development
version control
Xcode

What goes into your .gitignore if you're using CocoaPods?

Interview Questions practice on Codemia

Over 8,000 real interview questions from top companies, searchable by company and role.

Browse interview questions

Introduction

A CocoaPods project generates files that are essential for reproducible builds and files that are pure local cache noise. A good .gitignore keeps your repository stable while avoiding unnecessary churn from user-specific or machine-specific artifacts. The key decision is whether your team commits the Pods directory or installs dependencies on every clone.

Keep These CocoaPods Files Under Version Control

For almost every team, you should commit Podfile and Podfile.lock. Podfile declares dependency intent, while Podfile.lock pins resolved versions. Together they prevent team members and CI from drifting to different pod versions.

For Xcode integration, commit the generated workspace file because CocoaPods wiring depends on it.

gitignore
1# Do NOT ignore these
2# Podfile
3# Podfile.lock
4# *.xcworkspace

If these files are not tracked, reproducibility suffers and onboarding becomes fragile.

Decide Whether to Commit Pods Directory

There are two valid strategies.

Strategy one is to commit Pods/. This can improve reliability for offline builds and strict release reproducibility, at the cost of larger repository size and noisier diffs.

Strategy two is to ignore Pods/ and run pod install in setup and CI. This keeps the repository lighter, but requires reliable network and deterministic pod source availability.

A common choice for app repositories is committing Pods/ when reliability is critical. For many libraries and smaller apps, teams ignore it.

gitignore
# Option A: ignore installed dependencies
Pods/

Pick one strategy and document it in README so contributors do not mix practices.

Baseline iOS and Xcode Ignore Rules

Regardless of CocoaPods strategy, ignore local build products and user settings.

gitignore
1# Xcode build artifacts
2build/
3DerivedData/
4
5# User data
6*.xcuserstate
7xcuserdata/
8
9# Swift Package Manager local data if present
10.swiftpm/
11
12# macOS noise
13.DS_Store

These files create noisy diffs and should not be reviewed as source changes.

Example Complete .gitignore for CocoaPods

This sample assumes you do not commit Pods/.

gitignore
1# CocoaPods
2Pods/
3
4# Keep dependency declarations tracked
5!Podfile
6!Podfile.lock
7
8# Xcode
9build/
10DerivedData/
11*.pbxuser
12!default.pbxuser
13*.mode1v3
14!default.mode1v3
15*.mode2v3
16!default.mode2v3
17*.perspectivev3
18!default.perspectivev3
19xcuserdata/
20*.xcuserstate
21
22# macOS
23.DS_Store

If your policy is to commit Pods/, remove that ignore line.

Team Workflow Recommendations

Align local development and CI. If Pods/ is ignored, CI must run pod install --repo-update or your preferred locked workflow before build. If Pods/ is committed, define when pod updates are allowed and require lockfile review in pull requests.

It is also useful to gate dependency changes with a checklist. Reviewers should verify pod version upgrades, license impact, and binary size changes during update PRs.

Migrating an Existing Repository Policy

If your repository already tracks Pods/ and you decide to ignore it, coordinate a one-time cleanup in a dedicated pull request. Remove tracked pod files from the index, update CI setup to run pod install, and confirm lockfile consistency on a clean clone. If you move the other direction and start committing Pods/, make that explicit in contributor docs so developers stop deleting the directory during routine changes.

Common Pitfalls

The most damaging mistake is ignoring Podfile.lock. Without it, every clone can resolve different versions and produce unpredictable failures. Another common issue is committing DerivedData or user workspace settings, which creates merge conflicts unrelated to actual code. Teams also accidentally mix policies, where some developers commit Pods/ and others delete it, causing constant churn. Finally, after changing .gitignore, remember that already tracked files remain tracked until removed from Git index.

Summary

  • Always track Podfile and Podfile.lock for reproducible dependencies.
  • Choose one team policy for Pods/ and document it clearly.
  • Ignore local Xcode build artifacts and user-specific settings.
  • Keep CI workflow consistent with your chosen Pods/ strategy.
  • Clean tracked noise files from Git index when updating ignore rules.

Related reading
Free course
Beginner
7 lessons
2 hours
Tackling System Design Interview Problems

A short course that equips you with the skills to approach system design interviews methodically.

Start the free course
Track what you have practised

A free account saves your progress, solutions and study plan across every problem on Codemia.

Interview Questions practice on Codemia

Over 8,000 real interview questions from top companies, searchable by company and role.

Browse interview questions

All Rights Reserved.