Why ignore the DerivedData folder?

DerivedData holds Xcode build intermediates, indexes and module caches that are rebuilt from your source on every compile. It is large, machine-specific and should never be committed.

Should I commit the Pods/ folder?

It is a matter of team policy. Ignoring Pods/ keeps the repo small and forces a pod install, which some teams prefer; others commit it for reproducible builds without network access. The CocoaPods block ignores it by default.

Why ignore xcuserdata but keep the project file?

The xcuserdata directories store per-developer window layouts, breakpoints and scheme selections. Ignoring them avoids constant churn, while the shared .xcodeproj and .xcworkspace structure stays in version control.

What about Package.resolved for Swift Package Manager?

Apps usually commit Package.resolved to pin exact dependency versions, while libraries often ignore it. This builder includes it in the SPM block — remove that line if your project is a reusable package.

Is anything uploaded to a server?

No. The templates are built into the page and the file is assembled entirely in your browser, so nothing about your project is sent anywhere.

What is the .gitignore Builder for iOS / Xcode?

Build a .gitignore for iOS and macOS Xcode projects. Covers DerivedData, xcuserdata, Pods, Carthage, the SwiftPM .build directory and Fastlane output, then copy or download in your browser. It runs free in your browser on Gera Tools, with nothing uploaded.

.gitignore Builder for iOS / Xcode

Name: .gitignore Builder for iOS / Xcode
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

A .gitignore builder for iOS and macOS projects developed in Xcode. Pick your dependency manager and tooling, and the tool assembles the right ignore patterns for build artifacts, per-developer settings and CI output into one labelled file.

How it works

Each toggle adds a curated block of patterns under a # Header comment. The Xcode block ignores the DerivedData/ build cache, user state files like *.xcuserstate, and packaged *.ipa and *.dSYM artifacts. The dependency blocks handle the three common managers: Pods/ for CocoaPods, Carthage/Build/ for Carthage, and .build/ plus .swiftpm/ for Swift Package Manager. Workspace and Fastlane blocks cover per-developer settings and CI report output.

What each section covers

Xcode build artifacts

DerivedData/ is Xcode’s build cache — it stores intermediate build files, the index, module caches, and documentation. It is recreated entirely from source on a clean build, can grow to many gigabytes, and is machine-specific (paths inside it are absolute). Committing it has no benefit and causes constant noise in diffs. The build/ directory holds packaged *.ipa and *.dSYM files produced by the Archive step — ignore these and rebuild from source when you need a new release.

Per-developer Xcode state

Inside .xcodeproj/ and .xcworkspace/ there are xcuserdata directories that store per-developer settings: breakpoints, window layouts, custom run schemes, and the xcuserstate file that records which editor tabs are open. These change constantly during normal development and mean nothing to other team members. Ignoring them eliminates a category of noisy, pointless diffs. The shared xcschemes/ inside .xcodeproj/xcshareddata/ should be committed, since shared schemes define the build settings every team member uses.

CocoaPods — to ignore or not

The core question with CocoaPods is whether to commit the Pods/ directory:

Commit Pods/: reproducible builds without network access. No need to run pod install after clone. Preferred for teams on slow or restricted networks, or when you want guaranteed reproducibility.
Ignore Pods/: smaller repo, cleaner history. Requires pod install after clone and on every Podfile.lock change. Preferred for teams with reliable internet and smaller repos.

This builder ignores Pods/ by default. Whatever you choose, always commit Podfile.lock — it records the exact pod versions resolved and is essential for reproducible builds when Pods/ is ignored.

Swift Package Manager

The .build/ directory and .swiftpm/ configuration are machine-specific and should be ignored. Package.resolved — the lock file recording exact dependency versions — should typically be committed for apps but ignored for reusable packages (libraries). The builder includes it in the SPM section; remove that line if your project is a library.

Fastlane output

Fastlane generates test report files (report.xml, Preview.html) and screenshot output during automated builds. These are transient CI artefacts that do not belong in the repository and can safely be regenerated from a fresh Fastlane run.

Tips

Place the file at the root of your repository. Decide as a team whether to commit Pods/ — ignoring it keeps the repo lean but requires pod install after clone. For app targets, commit Package.resolved to pin SPM dependency versions; for reusable packages, ignore it. If a build file is already tracked, run git rm --cached <file> and commit so the ignore rule applies.