The CocoaPods cache on a Mac is the folder ~/. It keeps a copy of every pod version CocoaPods has downloaded, so the next project that needs one can copy it instead of downloading it again. It's safe to delete: CocoaPods downloads what a project needs the next time its pods are installed.
Swift Package Manager and Carthage keep shared caches of the same kind, in ~/ and ~/. Both are safe to move to the Trash in Finder. Each one comes back as your projects need it, at the cost of downloads and slower first builds.
The folders inside your projects are a different matter. A project's Pods folder, its Carthage/Build folder and a Swift package's .build folder can all be made again, but the project doesn't build until they are. A Pods folder may also be in source control, or hold edits nobody saved anywhere else.
None of the three tools has an app of its own. Xcode's File › Packages menu handles Swift packages in Xcode projects, and everything else in this post can be done in Finder. This post goes through each folder, what's inside it, what each tool's own cleanup removes, and where the real space usually is.
Where CocoaPods, Swift packages and Carthage keep their files
Each tool keeps two kinds of thing: a shared cache in your own Library folder or a hidden folder in your home folder, used by every project, and a folder inside each project with that project's dependencies.
| What | Where it is | What it holds | Level |
|---|---|---|---|
| CocoaPods cache | ~/Library/Caches/CocoaPods | Downloaded pods and their podspecs | Safe |
| CocoaPods spec repos | ~/.cocoapods/repos | The index of public pods | Safe |
| Pods folders | Pods, next to each Podfile | A project's installed pods | Usually safe |
| Swift Package Manager cache | ~/Library/Caches/org.swift.swiftpm | Package repositories, manifests and binaries | Safe |
| Swift package build folders | .build, next to each Package.swift | Build products and dependency checkouts | Safe |
| Carthage cache | ~/Library/Caches/org.carthage.CarthageKit | Repositories, downloaded frameworks, build data | Safe |
| Carthage Build folders | Carthage/Build in each project | A project's built frameworks | Usually safe |
A pod is CocoaPods' word for a library, described by a file called a podspec. Swift Package Manager calls the same idea a package, and Carthage calls it a dependency. All three end up as code or frameworks that Xcode builds into your app.
Xcode adds one more place. When a project uses Swift packages, Xcode keeps that project's own copies of them in its DerivedData folder, separately from the shared cache. That turns out to matter for space, and a section below covers it.
How do you open these folders in Finder?
Your Library folder is hidden, and folders whose names start with a dot, such as ~/, are hidden too. You can still open any of them by name.
- In Finder, choose Go › Go to Folder.
- Type the path, such as
~/. The tilde stands for your home folder.Library/ Caches/ CocoaPods - Press Return.
To reach your Library folder from the menu instead, hold down the Option key and choose Go › Library. To see a folder's size, select it and choose File › Get Info. The steps are the same in macOS 27 Golden Gate and macOS 26 Tahoe.
Where do they show up in Storage settings?
Open System Settings › General › Storage. It has no category for CocoaPods, Swift Package Manager or Carthage, so their shared caches are counted in System Data, with everything else Storage settings can't name.
The folders inside your projects are ordinary files in your home folder, so they're counted with your other documents. Before macOS Ventura, the same view was in Apple menu › About This Mac, under Storage and then Manage.
How much space do they take?
The research behind the app's catalog puts these three tools' shared caches together at 1 to 15 GB on a Mac that uses them. The folders inside projects come on top, one set per project, and on a Mac with many projects they're often the larger part.
- One project's packages in DerivedData3,707 MB · Safe
- Shared cache: binary frameworks770 MB · Safe
- Shared cache: package repositories426 MB · Safe
- Shared cache: package manifests4 MB · Safe
Measured on one Mac in October 2026, with six packages cached, two of which download binary frameworks. The project's folder holds those frameworks unpacked, so it's larger than the downloads. Typical totals vary widely with the packages a project uses.
On that Mac, most of the shared cache was one crash-reporting SDK that ships its framework as binaries, in seven variants. The project's own copy, with the same frameworks unpacked, was three times the size of the whole shared cache.
The CocoaPods cache on a Mac
CocoaPods downloads each pod into ~/ before it installs it into a project. When another project, or the same one later, needs that pod version, CocoaPods copies it from the cache instead of downloading it again.
What's in the CocoaPods cache?
Look inside and you'll find a Pods folder and a file named search_index.json. The Pods folder is the download cache itself. CocoaPods' source code shows how it's laid out:
- Release holds pods published to a spec repo, one folder per pod and version.
- External holds pods that came from a Git repository or another source, one folder per checkout.
- Specs holds the podspec that describes each cached pod.
- VERSION is a small file recording which version of CocoaPods wrote the cache.
The search index is what CocoaPods' search uses to find pods by name. It's small, and CocoaPods makes it again when it needs it.
Is it safe to delete the CocoaPods cache?
Yes. Nothing in it is your own work. The next time a project installs its pods, CocoaPods downloads the ones it needs again, which takes longer and needs a network connection. Projects that already have their pods installed keep working, because their Pods folders are separate.
- Make sure no pod install or update is running, in Terminal or in a script.
- In Finder, choose Go › Go to Folder, type
~/and press Return.Library/ Caches - Move the CocoaPods folder to the Trash.
- Empty the Trash when you're sure you won't need it back.
Move only the CocoaPods folder, never the Caches folder itself, which every app on your Mac uses.
Why does the cache sometimes empty itself?
Because CocoaPods starts a fresh cache when its own version changes. If the VERSION file names a different version from the one running, CocoaPods removes its download cache and begins again.
So updating CocoaPods clears old downloads by itself, and the cache then grows again with the pods your projects install. Apart from that, CocoaPods' code doesn't remove old entries: a pod version you used once stays until the next update or until you clear it.
What does CocoaPods' cache command remove?
CocoaPods has a cache command with two parts, and its documentation describes each one. Neither has a button: they run in Terminal only.
| CocoaPods' cache command | What it does | What it leaves |
|---|---|---|
| List | Shows what's cached, pod by pod | Everything |
| Clean, with a pod's name | Removes that pod's cached versions, asking which if there are several | Every other pod |
| Clean, with the all option | Removes the whole download cache | The search index |
| Clean, with neither | Refuses, so the cache isn't cleared by mistake | Everything |
What the command removes is deleted at once, not moved to the Trash. Moving the folder to the Trash in Finder does the same job and lets you change your mind.
Can the CocoaPods cache live somewhere else?
Yes. CocoaPods reads a few settings from your shell's configuration. One moves the cache to another folder, one moves the whole ~/ folder, and one tells CocoaPods not to use its download cache at all. A settings file in ~/ can move the cache too.
If ~/ is missing or tiny on a Mac that installs pods every day, one of those settings is probably why. Continuous integration machines often set them.
CocoaPods spec repos in ~/.cocoapods
CocoaPods needs an index of every public pod and its versions to work out what to install. It keeps that index in ~/, in a folder for each source.
What is the trunk folder?
Since CocoaPods 1.8, the default source is a content delivery network, and the local folder for it is called trunk. CocoaPods fetches only the parts of the index your projects ask for, so trunk stays fairly small.
Before 1.8, CocoaPods cloned the entire public Specs repository into a folder called master, or sometimes cocoapods. CocoaPods' own announcement called that repository huge, and the catalog's research found it can take several gigabytes.
Is it safe to delete the master folder?
Usually, yes. CocoaPods' 1.8 announcement says the master specs repo may be deleted safely once your projects use the CDN, which they do by default unless a Podfile names the Git source explicitly.
- Check your projects' Podfiles for a source line naming the CocoaPods Specs repository on GitHub. If there is one, that project still uses master.
- If none do, choose Go › Go to Folder, type
~/and press Return..cocoapods/ repos - Move the master or cocoapods folder to the Trash.
CocoaPods' announcement removes it with its own repo command instead, which deletes it at once. Either way, a project that still needs it clones it again the next time it installs pods.
Can you delete the trunk folder?
Yes. It's Safe for the same reason: CocoaPods fetches the index again when a project needs it. The next pod install takes a little longer while it does.
What else is in ~/.cocoapods?
Private spec repos your team added, each in its own folder next to trunk. They hold your team's own index of pods, and the catalog doesn't count them as caches. Leave them, or remove one with CocoaPods' repo command when you no longer need it.
The folder can also hold a templates folder, used when CocoaPods creates a new Podfile, and a config.yaml settings file. Neither is large. Don't move ~/ as a whole to the Trash, because the private repos and settings go with it.
What changes when CocoaPods trunk goes read-only?
CocoaPods' maintainers plan to stop accepting new pods and versions on trunk on 2 December 2026, after a test run in early November. They say the dates aren't set in stone, and that existing builds keep working.
For disk space, it changes little at first. Projects keep installing the versions they already use, with the same cache and spec repo. Over time, as projects move their dependencies to Swift Package Manager, CocoaPods' folders stop growing, and the old ones become easy to clear.
Pods folders in your projects
When a project's pods are installed, CocoaPods puts their source code, and an Xcode project that builds them, in a Pods folder next to the Podfile. You then open the project's workspace rather than its Xcode project, so both build together.
Can you delete a project's Pods folder?
You can, but it's Usually safe, not safe without a thought. CocoaPods can recreate the folder from the versions recorded in Podfile.lock, but the project doesn't build until its pods are installed again.
Two things can be lost along the way. CocoaPods' guide recommends keeping the Pods folder in source control, so in some projects deleting it shows up as a change to every file in it. And anyone who edited a pod's files directly inside Pods loses those edits, because they're kept nowhere else.
Which Pods folders are worth removing?
The ones in projects you've finished with. A project you open every day needs its pods, and reinstalling them costs more time than the space is worth.
Old projects, a tutorial you followed once, or a client's app from years ago are the good candidates. If the project is in source control, check whether its Pods folder is committed first. If it is, the copy in the repository is your backup.
How do you find them?
Open the folder where you keep your projects, and choose View › as List. Each project with pods has a Pods folder next to its Podfile, and File › Get Info shows its size. For many projects at once, a disk map is quicker than opening each folder.
Does uninstalling CocoaPods from a project free space?
CocoaPods' deintegrate command removes every trace of CocoaPods from an Xcode project, and deletes its Pods folder as well, leaving only the workspace. It's meant for moving a project off CocoaPods, for example to Swift Package Manager. It runs in Terminal only, and what it deletes doesn't go to the Trash.
| Folder | Can you remove it in Finder? | What it costs |
|---|---|---|
~/Library/Caches/CocoaPods | Yes | Pods download again on the next install |
~/.cocoapods/repos/trunk | Yes | The index is fetched again |
~/.cocoapods/repos/master | Yes, once no Podfile names it | A full clone if a project still needs it |
| Private spec repos | Better with CocoaPods' repo command | Adding the repo again by hand |
A project's Pods | Yes, after checking source control | Installing the pods again; edits inside are lost |
The Swift Package Manager cache
Swift Package Manager keeps one shared cache for all your projects, whether you build them with Xcode or with Swift's own command-line tool. Apple added the shared cache in Xcode 12.5, describing it as a per-user cache that cuts network traffic and speeds up resolving packages.
What's in ~/Library/Caches/org.swift.swiftpm?
A handful of folders and databases. Their sizes depend entirely on which packages you use.
| Inside the cache | What it holds | What makes it large |
|---|---|---|
repositories | A copy of each package's Git repository | Packages with long histories |
artifacts | Downloaded binary frameworks, still zipped | SDKs shipped as binaries |
manifests | Results of reading each Package.swift | Rarely large |
registry | Packages downloaded from a package registry | Only if you use one |
| Package collection database | Package collections you've added | Rarely large |
A repository copy holds the package's whole history, not just the version you use. On the Mac measured above, one database library's copy took 231 MB, the largest of the six.
Is it safe to delete the Swift Package Manager cache?
Yes. Each project downloads its packages again the next time it resolves them, which takes longer and needs a network connection. Your package settings, such as mirrors, registries and package collections, are kept elsewhere and aren't affected.
- Quit Xcode, and stop any build running in Terminal.
- In Finder, choose Go › Go to Folder, type
~/and press Return.Library/ Caches - Move the org.swift.swiftpm folder to the Trash.
Projects you've already resolved keep working, because Xcode and the swift tool keep each project's own copies separately. The cache refills as those projects resolve again.
What are ~/.swiftpm and ~/Library/org.swift.swiftpm?
Two folders that look like caches and mostly aren't. ~/ is made of links: on a Mac, its cache entry points to the cache in your Library's Caches folder, so it takes no space of its own.
~/ holds your package configuration and a security folder with the fingerprints Swift Package Manager recorded for packages it has downloaded. It's small, and it isn't a cache. Leave it alone.
Does Xcode use the same cache?
Yes, for repositories and downloads. But Xcode also keeps a full set of packages for each project, in a SourcePackages folder inside that project's DerivedData folder: repository copies, the checked-out version of each package, and binary frameworks unpacked and ready to build.
That's why the project folder in the chart above was larger than the shared cache. The post on Xcode's DerivedData explains that folder in full.
What do Xcode's and Swift's package commands remove?
Each tool has its own way to clear package data, and each clears something different. Only Xcode's has a menu.
| Command | Where | What it removes |
|---|---|---|
| Reset Package Caches | Xcode, File › Packages | The project's package data, which Xcode then resolves again |
| Purge cache | Swift's package tool, in Terminal | Shared repository copies, manifests and registry downloads |
| Reset | Swift's package tool, in Terminal | The package's whole .build folder |
| Clean | Swift's package tool, in Terminal | Build products in .build, keeping checkouts and downloads |
Apple doesn't document exactly what Reset Package Caches clears. It sits in File › Packages with Resolve Package Versions and Update to Latest Package Versions, and it's the one to try first when a project's packages won't resolve.
When should you use Reset Package Caches instead of Finder?
When something is broken rather than when space is short. If Xcode reports a missing package product, or resolving seems stuck, Reset Package Caches makes Xcode fetch the project's packages afresh.
For space, Finder is more direct: moving the shared cache, or old projects' DerivedData folders, to the Trash frees exactly what you can see, and you can put it back.
Swift package .build folders and Xcode's package copies
The shared cache is only half the story. Every project that uses Swift packages keeps its own copies too, and on a Mac with many projects those copies add up.
Can you delete a .build folder?
Yes. When you build, test or run a package with Swift's command-line tool, Swift Package Manager puts compiled products, intermediate files and copies of the package's dependencies in a .build folder next to its Package.swift. It's Safe: the folder comes back with the next build.
What it costs is a full, slower build, and fetching the dependencies again. Tools you built and ran from inside .build are gone until you build them again.
Why is a .build folder so large?
It grows with each configuration and platform you build for. Debug and release builds are kept apart inside it, and so are builds for other platforms. Nothing is removed when you switch, so the .build folder of a package you work on only grows.
Swift's package tool can trim it in two ways, as the table above shows: clean removes build products but keeps downloaded dependencies, and reset removes the whole folder. Moving .build to the Trash in Finder has much the same effect as reset, and you can put it back.
Why does each copy of a project get its own packages?
Because Xcode names each DerivedData folder after the project and its location on disk. Open the same project from two different folders, such as two clones or two Git worktrees, and Xcode makes two DerivedData folders, each with its own SourcePackages.
On the Mac measured above, ten DerivedData folders had package folders of their own, several of them for copies of the same project. Removing the DerivedData folders of copies you no longer use frees their packages along with everything else Xcode built for them.
Where does Xcode keep the frameworks a package downloads?
Twice. The zipped download goes into the shared cache, in its artifacts folder. Each project then unpacks it into the artifacts folder of its own SourcePackages, ready to build.
So a package that ships large binaries costs its download size once, plus its unpacked size in every project and every copy of a project that uses it. That pattern explains most of the space in the chart above.
The Carthage cache and Carthage folders
Carthage works differently from the other two. It doesn't change your Xcode project: it builds or downloads each dependency as a framework, and you add the frameworks to your project yourself.
What's in the Carthage cache?
Carthage's source code names three folders inside ~/:
- dependencies, with a copy of each dependency's Git repository.
- binaries, with prebuilt frameworks Carthage downloaded instead of building them.
- DerivedData, with Carthage's own Xcode build data.
It's Safe. The next time Carthage fetches or builds dependencies, it downloads or builds them again, which takes longer and needs a network connection. The Carthage folders inside your projects aren't affected.
Does Carthage have a cleanup command?
No. Carthage has no command that clears its cache, and no app. Moving the folder to the Trash in Finder is the way to clear it: choose Go › Go to Folder, type ~/, and move org.carthage.CarthageKit to the Trash.
Carthage's most recent release, 0.40.0, came out in September 2024. If you stopped using Carthage when your projects moved to Swift packages, its cache may be several years old and safe to clear entirely.
Can you delete Carthage/Build?
It's Usually safe. Carthage/Build holds the frameworks your project links to, and Carthage can make them again from the versions in Cartfile.resolved. But the project doesn't build until it does, and building every dependency from source can take a while.
Carthage also keeps small hidden version files in that folder, which record what it built so it can skip rebuilding later. Its documentation says deleting them clears that record, so the next run rebuilds those dependencies.
What about Carthage/Checkouts?
Checkouts holds the source code of each dependency. Carthage's guide leaves it to you whether to commit it or ignore it, and with its submodules option each dependency becomes a Git submodule you can change and push.
That's why it's not a cache to clear without looking. If a project commits its Checkouts or uses submodules, removing the folder affects your repository. In a finished project that does neither, it goes with the rest of the project's Carthage folder.
Which to clear first: a decision table
On most Macs, the shared caches are the quick win and the project folders are the bigger one. The table puts each folder in the order worth trying.
| Step | What it frees | What it costs | Can you undo it? |
|---|---|---|---|
| Move old projects' DerivedData folders to the Trash | Their packages and build files | A full build if you open them again | Yes, until you empty the Trash |
| Move the Swift Package Manager cache to the Trash | Up to the size of the cache | Packages download again | Yes, until you empty the Trash |
| Move the CocoaPods cache to the Trash | The whole download cache | Pods download again | Yes, until you empty the Trash |
| Move an old master spec repo to the Trash | Often the largest CocoaPods folder | A clone if a project still uses it | Yes, until you empty the Trash |
| Move the Carthage cache to the Trash | Repositories, binaries, build data | Dependencies fetched or built again | Yes, until you empty the Trash |
| Remove Pods or Carthage/Build in finished projects | Each project's dependencies | Reinstalling before the next build | Yes, until you empty the Trash |
A worked example
The Mac measured above had no CocoaPods cache at all, and its spec repo folder was empty. The Swift Package Manager cache was 1.2 GB, and one project's package folder in DerivedData was 3.7 GB.
Clearing the shared cache would have freed 1.2 GB and cost a few minutes of downloads. Removing the DerivedData folders of old copies of the project would have freed more, because each held its own unpacked frameworks.
What that means for your Mac
If you moved from CocoaPods to Swift packages years ago, look for an old master spec repo first: it's often the single largest leftover. If you use Swift packages that ship binary frameworks, look at DerivedData before the shared cache, because the unpacked copies outweigh the downloads.
Mistakes to avoid
These folders look like ordinary folders in Finder, which makes it tempting to tidy them by hand. A few habits keep that safe.
Don't clear a cache while something is using it
Removing the CocoaPods cache during a pod install, or the Swift package cache while Xcode is resolving packages, can leave a project half-installed. Quit Xcode and let installs finish first, then clear the folder.
Don't move the Caches or Library folder itself
Every app on your Mac keeps files in ~/, and your Library folder holds settings and data you can't get back. Move only the tool's own folder inside it.
Don't delete package settings to fix a cache
~/ and the config.yaml file in ~/ hold settings, not downloads. Clearing them frees almost nothing and can change how your tools behave.
Don't remove Pods from a project you're working on
The project stops building until its pods are installed again, and edits made inside Pods are lost. Remove it only in projects you've finished with, after checking whether it's committed to source control.
Don't paste cleanup commands from a web page
All three tools' caches can be cleared in Finder, where the Trash lets you change your mind. A command copied from a web page can remove far more than it says, and what it removes doesn't go to the Trash.
Keep these caches from coming back too large
The shared caches come back with every project you set up, and that's expected: they exist to save downloads. What you can control is how many old copies pile up.
A routine that works
- Every few months, remove DerivedData folders for projects and copies you no longer open.
- When you stop using CocoaPods or Carthage, clear their caches and spec repos once.
- Remove Pods and Carthage/Build in projects you've archived, after checking source control.
- Let CocoaPods' updates clear its download cache; don't turn its cache off unless you have a reason.
Leave them out of Time Machine
These caches can be downloaded again, so they don't need backing up. In macOS 27 and macOS 26, choose Apple menu › System Settings, click General, then Time Machine. Click Options, click the Add button, choose the cache folders, then click Done.
The same applies to DerivedData. The guide to cleaning up Xcode covers its other folders, such as simulators and archives, and why Xcode takes up so much space goes through every one in detail.
For other folders worth leaving out, see the post on keeping developer folders out of Time Machine.
Where else developer files hide
Most of Xcode's own data is in ~/, next to but separate from these caches. The post on the Library Developer folder explains what each folder there does.
How the app does it
Wombit finds these folders, explains each one in plain language and shows its size, with hard links and APFS clones counted once. Select one on the map to see what it is, what removing it costs, and a Move to Trash or Clean Up button.
The CocoaPods cache and spec repos, the Swift Package Manager cache, .build folders and the Carthage cache are Safe: they start checked in Cleanup and go to the Trash, where Put Back returns them. Pods folders and Carthage/Build are Usually safe, so they wait for your choice.
~/
Library/ Caches/ CocoaPods Pods that CocoaPods has downloaded, kept so it doesn't download them again for every project.
Safe · Runs pod cache clean --all
~/
.cocoapods/ repos/ {trunk,master,cocoapods} Local copies of the public CocoaPods Specs index, which CocoaPods uses to look up pods and their versions.
Safe · Moves it to the Trash
~/
**/ Pods The pods a project installed with CocoaPods, kept in a Pods folder next to its Podfile.
Usually safe · Moves it to the Trash
~/
Library/ Caches/ org.swift.swiftpm Package repositories, manifests and binaries that Swift Package Manager keeps so packages aren't downloaded again for every project.
Safe · Moves it to the Trash
~/
**/ .build Build products and dependency checkouts that Swift Package Manager creates next to a package's Package.swift file.
Safe · Moves it to the Trash
~/
Library/ Caches/ org.carthage.CarthageKit Dependency repositories, downloaded frameworks and build data that Carthage keeps to reuse across projects.
Safe · Moves it to the Trash
~/
**/ Carthage/ Build Frameworks that Carthage built or downloaded for a project, kept in its Carthage/Build folder.
Usually safe · Moves it to the Trash
For the CocoaPods cache, the app runs CocoaPods' own command after the review sheet, instead of deleting files. What a command removes can't be put back, and the sheet says so. The small search index stays where it is.
What the app runs, after you review itPRO
- pod cache clean --all
- CocoaPods' download cache: every cached pod and its podspec
Seeing these folders and what's in them is free. Moving them to the Trash, and running CocoaPods' command, is PRO: one payment of $4.99 with lifetime access. Every Pro tool's review is free to open, so you see what would go and why before you buy.
Frequently asked questions
Where is the CocoaPods cache on a Mac?
In ~/Library/Caches/CocoaPods, unless a CocoaPods setting moves it. The downloaded pods are in its Pods folder. The index of public pods is kept separately, in ~/.cocoapods/repos.
Is it safe to delete ~/Library/Caches/CocoaPods?
Yes. It only holds downloads, and CocoaPods fetches whatever a project needs the next time its pods are installed. Projects that already have their pods installed keep working, because their Pods folders are separate.
Can I delete the ~/.cocoapods folder?
Not as a whole. Its trunk folder, and an old master folder from before CocoaPods 1.8, are indexes CocoaPods can fetch again. The same folder can also hold your team's private spec repos and a settings file, which aren't caches.
How do I clear the Swift Package Manager cache on a Mac?
Quit Xcode, choose Go › Go to Folder in Finder, type ~/Library/Caches and move the org.swift.swiftpm folder to the Trash. Projects download their packages again the next time they resolve them.
What does Reset Package Caches do in Xcode?
It makes Xcode drop the project's cached package data and resolve its packages again. It's in File › Packages, and it's the first thing to try when packages won't resolve. Apple doesn't document exactly which files it clears.
Should I delete the Pods folder in my project?
Only in projects you've finished with. The project won't build until its pods are installed again, edits made inside Pods are lost, and some teams keep the folder in source control. In a project you work on, the space isn't worth the reinstall.
Where does Carthage store its cache on a Mac?
In ~/Library/Caches/org.carthage.CarthageKit, with folders for dependency repositories, downloaded binaries and Carthage's own build data. Carthage has no command to clear it, so move the folder to the Trash in Finder.
Will clearing these caches make Xcode faster?
No. Clearing them frees space, and the next install or build is slower while the tools download and build again. They're caches precisely so that day-to-day work is quicker.
Sources
- Adding package dependencies to your app · Apple
- Xcode 12.5 Release Notes · Apple
- Command-line reference · CocoaPods
- CocoaPods 1.8 beta · CocoaPods
- CocoaPods Trunk Read-only Plan · CocoaPods
- Carthage · Carthage