iOS Build Server Low Disk? 2026 Xcode 27: Clean or Expand

A remote Archive suddenly fails with a disk-space error even though the source code and developer account are fine.

Fastest fix: do not wipe the server. First separate reproducible build data, Simulator components, dependency caches, and release evidence; clean only the safe layer, then expand or add another Mac if the same pressure returns.

Who this guide is for

This guide is for an independent developer with one remote Mac and repeated storage alerts during iOS builds. It gives you a safe cleanup order instead of a blind deletion script.

It also helps teams that must retain Xcode 27, several Simulator runtimes, historical Archives, or automated publishing jobs. You can use the scenario decisions below to choose between single-machine governance, storage expansion, and a separate build host.

Start with the storage layer, not the delete command

An iOS build server low on disk is not automatically an expansion problem. Xcode can create DerivedData, build outputs, test results, archives, and other intermediate files during different workflows. The build system determines how these products are generated and reused, so inspect the actual host before choosing a cleanup target. See Apple’s Xcode Build System documentation for the relationship between build actions and products.

The first inspection should answer five questions:

• Is a Build, Test, Archive, export, or upload task still running?
• Which user and project own the largest directories?
• Are multiple Xcode versions installed for a real compatibility reason?
• Are Simulator runtimes required by the current test matrix?
• Do release files have a verified alternative copy?

Use measurement commands before removal. For example:

df -h
du -sh ~/Library/Developer/Xcode/* 2>/dev/null
du -sh ~/Library/Developer/CoreSimulator/* 2>/dev/null

These commands show filesystem and top-level category usage. They do not prove that a directory is safe to delete. For a project-specific build location, inspect the path configured by the scheme or build settings rather than assuming every project uses the same location. Apple documents derivedDataPath usage in its xcodebuild documentation.

This week’s recommended action: record the active jobs, storage categories, Xcode version, and recovery copies before removing anything.

A useful distinction is:

The table is a decision tool, not permission to remove every row marked as cleanable. Ownership, job state, and recovery evidence decide the action.

Archive-only servers have a wider cleanup margin

A server used only for Release Archive jobs has different storage priorities from a Mac used for daily development. If the machine does not run SwiftUI Previews, interactive debugging, or a broad UI test matrix, it may not need to retain every piece of local development state. That does not mean you should delete the complete developer directory.

For an Archive-only workflow, inspect these layers separately:

• Project-specific DerivedData.
• Temporary build directories created by the CI job.
• Old exported products that already exist in an approved release store.
• Dependency caches that can be restored from their declared sources.
• Archives and symbol files that remain part of release recovery.

DerivedData can usually be regenerated, but regeneration has an operational cost. The next build may need to resolve packages, compile everything from a cold state, and recreate indexes. If the server is already close to full, that cold rebuild can fail again before producing an Archive.

Before removing it, confirm that no process is using the path:

ps aux | grep -E 'xcodebuild|Xcode|swift|clang' | grep -v grep

This is only a process check. Your CI queue, remote console, or job system remains the authoritative source for whether a release task is active.

If the job is stopped, remove a narrowly scoped DerivedData path rather than the entire user directory. The -derivedDataPath build setting can make this ownership explicit for future jobs. Apple’s Build Settings Reference explains how build settings influence output locations and behavior.

Do not clean a server while an Archive, export, upload, or test process is running. A partial output can look disposable while another step still depends on it.

After cleanup, do not rely on a successful command exit alone. Run the same scheme with the same signing context, create a new Archive, and confirm that the resulting evidence is usable. If the replacement Archive fails, stop further cleanup and restore the previous state or move the job to a verified host.

Simulator storage needs a test-matrix decision

Simulator storage is often misdiagnosed because several different objects appear under the same broad area. A Simulator runtime is an operating-system image. A created simulated device contains device state and application data. Test results and screenshots are evidence produced by a test run. These objects have different retention reasons.

A remote Mac that performs only Archive and upload jobs may not need a complete Simulator fleet. A team running UI tests across selected operating-system versions does. The correct question is not “Can I delete Simulator files?” but “Which supported test combinations must this host execute?”

Keep a runtime when:

• A current CI job targets it.
• A release gate requires a regression run on that operating-system version.
• Recreating it would interrupt a scheduled test window.
• The team has no verified alternative runner.

Consider removing a runtime only after the test matrix has been reviewed and the component is no longer required. Apple documents how additional Xcode components are managed in its component installation guide.

Created devices and application data can be more disposable than runtimes, but only when they are not being used to reproduce a failure. Preserve test results and screenshots while an investigation is open. Apple’s testing and result interpretation documentation describes why test-result bundles are part of the diagnostic record.

A Simulator also cannot replace physical-device validation. Apple explicitly distinguishes simulated and physical devices in its device testing documentation. Removing a runtime to recover space does not change that boundary; it only changes which automated checks the server can perform.

Multiple projects require cache ownership

A multi-project server is where “delete all caches” becomes dangerous. One App may use Swift Package Manager, another may use CocoaPods, and a third may depend on a private package source. Different Xcode versions may also be intentional because released Apps do not all move to a new toolchain at once.

Create a simple ownership map before cleanup:

• Project or repository.
• Xcode version and selected toolchain.
• Package source and lockfile.
• DerivedData location.
• Archive and symbol destination.
• CI job that can recreate the output.
• Person responsible for approving deletion.

For Swift Package Manager, record the project’s declared dependencies and lockfile before removing downloaded data. For CocoaPods or private dependencies, confirm that the source is reachable and credentials are available. A cache is only safely disposable when the dependency can be restored and the restored version is controlled.

Use this recovery chain after a dependency cleanup:

• Resolve the dependencies again.
• Confirm the expected versions.
• Perform a cold build.
• Run the required tests.
• Create and validate an Archive.
• Confirm that symbols and release metadata are stored.

If the cold build fails, the cleanup did not merely reclaim space; it exposed a reproducibility problem. Restore the previous cache if it is available, fix dependency access, and delay further deletion. Do not remove another project’s cache to solve the first project’s failure.

Release files need an evidence policy

The most costly cleanup mistake is treating every output as a cache. An xcarchive can be required for re-export, later distribution, or crash investigation. An IPA may be the exact package submitted for a release. A dSYM is needed to symbolicate crashes when it matches the shipped binary. An xcresult bundle can contain the evidence needed to understand a failed test.

Before deleting a release object, answer these questions:

• Is the same file stored in a verified external location?
• Can you retrieve it without relying on the disk you are cleaning?
• Does it match the released build and signing context?
• Is crash symbolication still required?
• Could the team need to re-export or explain this release later?

Apple explains the role of debugging information in its debug-symbol documentation. Apple also provides guidance for Archive export and app-size-related distribution work. These references do not define your retention policy; they help you identify why a release artifact may matter after the build has finished.

A minimal recovery acceptance test should prove at least one of these paths:

• The source, signing material, and dependency inputs can produce a new valid Archive.
• The existing Archive can be retrieved and exported.
• The matching IPA and dSYM are available from a verified alternative location.
• The affected test result can be opened or reviewed from preserved evidence.

Signing assets require separate treatment. Certificates, provisioning profiles, private keys, and Keychain entries are not build cache. Never solve a disk alert by deleting the Keychain or every installed profile. That can turn a storage issue into a signing outage.

Choose cleanup, expansion, or a second Mac

Use the following decision conditions after the first inspection:

• If most usage is reproducible DerivedData or obsolete temporary output, and no job is active, choose scoped cleanup. Preserve logs, remove only the project-owned path, then run a cold build and Archive.
• If usage is an unused Simulator runtime, choose component cleanup only after reviewing the test matrix. Keep the runtimes required by current UI tests and release gates.
• If usage is dependency cache shared by several projects, choose cache governance first. Assign ownership and prove restoration before deletion.
• If usage is historical Archives, IPA files, dSYM files, or xcresult bundles with no verified copy, choose preservation or external archiving. Do not recover space by destroying the only release evidence.
• If cleanup repeatedly restores the machine only briefly, choose expansion. A recurring full-disk incident indicates that legitimate workload demand exceeds the current storage boundary.
• If the pressure is caused by a temporary release peak or competing workloads, choose a separate remote Mac. Keep the stable production machine unchanged and use the additional environment for version validation, temporary builds, or parallel testing.
• If one host must retain several Xcode versions, run multiple App pipelines, and execute continuous UI tests, choose host separation. A single machine may be cheaper to operate, but it creates a larger failure domain.
• If the project is low-frequency and uses one stable toolchain, choose scheduled inspection and scoped cleanup before expansion. Do not buy or rent more capacity until measured usage shows that the current policy cannot keep the host reliable.

If the additional environment is temporary, compare the available VPSMAC remote Mac configurations by the workload you need rather than by nominal hardware alone. A second host is useful when it gives you a reversible place to test Xcode 27, rebuild dependencies, or handle a release surge without modifying the only production server.

For teams comparing locations, the VPSMAC M4 node options can be reviewed alongside network access, credential policy, test requirements, and the time window in which the environment is needed. Storage alone does not solve a signing, bandwidth, or recovery problem.

Final recommendation for a remote build setup

A self-managed iOS build server gives you control, but it also leaves you responsible for cache ownership, Simulator component drift, Archive retention, signing recovery, and storage alerts. A single Mac becomes especially risky when development, UI testing, and automated publishing compete for the same disk.

For a low-frequency single-App workflow, disciplined cleanup is usually the first move. For multiple projects or repeated full-disk failures, expansion is more defensible. For a short release peak or a separate Xcode 27 validation track, adding an independent remote Mac is easier to reverse than aggressively cleaning the only production host.

If you need a temporary build environment, a second release lane, or a safe place to validate the toolchain before changing production, renting a Mac through VPSMAC can be more practical than buying hardware for a short-lived demand spike. You can keep the existing server intact, test the recovery path separately, and retire the additional environment when the workload returns to normal.