iOS 27 Simulator Disk Full: Clean Up or Expand in 2026?

The same “disk full” symptom can occur at different points:

• A Runtime download fails because the platform image cannot fit.
• A build fails because DerivedData, dependency artifacts, or Archives have grown.
• A simulator refuses to boot because device data or the host volume is exhausted.
• An unattended build stops because logs or old archives consume the remaining free space.

Do not treat every folder under a Developer directory as disposable. Separate these categories before you delete anything.

Simulator Runtime

A Simulator Runtime is the operating-system image used by simulated devices. Multiple simulated devices can depend on the same Runtime. Removing one device does not necessarily remove the Runtime, and removing the Runtime can affect every device built on that platform.

Apple documents how to add and manage additional simulator components through Xcode. Use the official Components installation and removal guidance rather than deleting runtime bundles by hand.

Simulated device data

A simulated device contains app data, preferences, test databases, screenshots, and other runtime state. It can become large after repeated UI tests or local data generation.

Deleting an unused simulated device is narrower than uninstalling its Runtime. It normally preserves the platform image for a future device, but it removes the device-specific state that may be useful for reproducing a bug.

DerivedData

DerivedData contains generated build output, indexes, intermediate files, and other products associated with Xcode projects. It is normally rebuildable. That does not mean deletion is free: the next build must regenerate indexes and products, and a remote build may spend time restoring dependencies and compiling again.

DerivedData is not your source code. It is also not a substitute for Archives, signing files, or a reproducible dependency setup.

Archives and distribution artifacts

Archives are release or distribution inputs. They may be needed for TestFlight submissions, customer support, rollback investigation, or App Store review responses. Apple’s archiving issue guidance explains why a valid archive depends on the build environment and signing conditions.

Do not remove every old Archive just because Finder reports a large folder. Define a retention rule first. Keep the artifacts required for active releases, then move older material to an approved storage location if your process allows it.

Dependency caches and logs

Package Manager checkouts, CocoaPods or other dependency caches, test recordings, crash logs, and CI logs can grow outside the most obvious simulator folders. Their recovery behavior differs by project.

A cache that can be restored from a lockfile is a different cleanup candidate from a locally stored signing asset. If you cannot explain how a file will be recreated, do not classify it as disposable yet.

Use macOS storage information for a broad view, then inspect the relevant project and simulator directories with a disk-usage command. Replace placeholders such as <PROJECT_PATH> and <USER> before running commands:

du -sh "<PROJECT_PATH>/DerivedData" 2>/dev/null
xcrun simctl list devices
xcode-select -p

The first command measures a project path. The second lists simulator devices. The third shows the active developer directory. These commands inspect state; they do not clean anything. Avoid recursive deletion commands until you have confirmed the target path and stopped active builds.

Your correct action depends on what you need to test next, not only on what is largest today.

Single-app developers

If you maintain one app and support a narrow version range, use the smallest environment that still covers your release and regression work:

• Keep the platform support required by the active Xcode installation.
• Keep the Runtime used by current local tests.
• Keep only the simulated devices needed for repeatable test cases.
• Remove stale device data after confirming that it is not part of a bug reproduction.
• Keep required Archives and signing material outside the cleanup target.

Prefer Xcode’s Components interface for unused Runtimes. This makes the removal intent visible and reduces the chance of confusing a platform image with a device record.

DerivedData can be cleared when it is clearly the source of the growth. Expect the next build to regenerate indexes and intermediates. Do not interpret a successful cleanup as proof that the project is healthy. Build the real project afterward.

Compatibility testers

A compatibility tester should define a matrix before deleting anything. Record:

• The minimum iOS version your app supports.
• The main user version or versions you actively prioritize.
• The iOS 27 adaptation path.
• Device families that need UI, performance, or behavioral coverage.
• The next scheduled regression pass.

Then classify each Runtime as required, useful, or disposable. A Runtime is required when the next test cycle explicitly depends on it. A Runtime is useful when it covers a likely regression path but can be restored before the next planned run. A Runtime is disposable when no current test, build script, or support investigation needs it.

Deleting a simulated device is suitable when the platform must remain installed but the device state is stale. Removing a complete Runtime is a broader action. It can force later reinstallation and can disrupt scripts that select a specific platform.

Apple’s simulator management documentation explains the supported model for adding simulator platforms and devices. Follow that model when you need a reversible change.

Developers running stable and beta Xcode

A stable Xcode installation and Xcode 27 beta may not use an identical set of platforms or command-line tools. Before cleanup, record the active developer directory:

xcode-select -p

Use Apple’s xcode-select settings documentation to understand how the active command-line developer directory is selected.

Do not mix these actions:

• Switching the active developer directory.
• Deleting an old Xcode application.
• Removing a Simulator Runtime.
• Erasing simulated device data.
• Clearing DerivedData.

They solve different problems. A beta test environment can often be rebuilt, but your production release path must remain recoverable. Before removing a stable Xcode application or its related assets, verify that your release scripts, signing setup, Archive process, and fallback toolchain still work.

As of August 21, 2026, Apple lists Xcode 27 Beta 4 among its current testing toolchain information, and iOS 27 Simulator remains a test environment. Beta menus, system requirements, and component behavior can change. Treat the current Xcode 27 release notes as the authority for your installed build, not an older forum post.

Continuous builders and remote Mac maintainers

A remote Mac used as an iOS build host needs a storage policy that works without someone watching Finder. Start with four controls:

• A disk watermark that triggers inspection before builds fail.
• Archive retention tied to active releases.
• Log rotation with a known recovery location.
• Dependency cache rules that preserve lockfiles and permit a clean restore.

Do not schedule a blind deletion job that removes every simulator, Archive, or cache directory. That may free space while making the next build unreproducible.

If you are evaluating a hosted environment for this workload, CALMVPS remote Mac access can be checked alongside your existing host rather than treated as an immediate replacement. Validate the storage and recovery behavior with the same project before changing the build path.

Check persistence before changing the host:

• Does the assigned disk survive a reboot?
• Does the remote Mac retain installed Runtimes and Xcode components?
• Can your account access Xcode, the simulator service, SSH, and the build directory?
• Can you reinstall a removed component without manual intervention?
• Are signing assets stored separately from disposable build output?

For an unattended pipeline, the important test is recovery. Reboot the host, restore dependencies, boot the required simulator, build the app, create an Archive, and confirm the output. Apple’s distribution workflow documentation describes the relationship between Archives and distribution tasks.

If the host repeatedly reaches the disk watermark even after removing recoverable items, stop optimizing individual folders. You have a capacity mismatch. Split simulator testing from continuous builds, increase the assigned capacity, or move the workload to a remote Mac with enough persistent storage for the required toolchain.

Use this decision tool after classification.

Safe cleanup sequence

1. Record the current state.
   Save the active Xcode path, installed Runtime names, required simulated devices, recent Archives, and current free-space reading. This gives you a rollback reference.

2. Identify the failure stage.
   Reproduce the problem carefully. Note whether the failure occurs during Runtime download, project compilation, simulator boot, test execution, or Archive creation. Each stage points to a different storage category.

3. Inspect Xcode Components.
   Review installed platforms and optional components. Remove only items outside the documented test matrix. Use Apple’s supported Components workflow, not manual deletion of protected system directories.

4. Prune device state selectively.
   List simulated devices. Delete devices that are obsolete or corrupted only after checking whether their data is needed for a reproducible test. Keep the Runtime if another device still uses it.

5. Clear rebuildable output.
   Stop active Xcode and CI jobs. Remove the confirmed DerivedData target or use Xcode’s own cleanup controls. Preserve source, lockfiles, Archives, certificates, provisioning profiles, and release notes.

6. Apply retention rules.
   Keep Archives needed for active releases and support cases. Rotate logs. Remove dependency caches only when the project can restore them from a verified lockfile and network path.

7. Run a real acceptance build.
   Open the project, restore dependencies, boot the required simulator, run tests, create an Archive, and verify that signing and export still work. A larger Finder free-space figure is not enough.

8. Set the next action.
   If the same categories grow again and the required environment still fits, automate conservative cleanup. If the required environment does not fit, expand. If the host cannot preserve or restore it, migrate.

Apple’s documentation on running apps on simulated or physical devices also matters here: a simulator can validate many workflows, but it does not replace every physical-device or release check.

Use this checklist after cleanup or a capacity change:

• [ ] The active Xcode installation is the intended one.
• [ ] The required iOS 27 Simulator Runtime is present.
• [ ] The next supported iOS version in the test matrix is still available.
• [ ] Required simulated devices boot without rebuilding the entire environment.
• [ ] Dependencies restore from the project lockfile.
• [ ] The real app compiles from a clean or controlled state.
• [ ] Automated tests can launch the intended simulator.
• [ ] An Archive completes successfully.
• [ ] Signing and export still use the intended credentials.
• [ ] Archive retention and log rotation rules are documented.
• [ ] The remote Mac preserves the environment after reboot.
• [ ] Disk monitoring can warn before the next build interruption.

A cleanup is successful only when these checks pass. Space recovered without a working build environment is a temporary cosmetic result.

The following questions cover the most common decisions around iOS 27 Simulator disk usage.

Can an iOS 27 Simulator Runtime be removed safely?

Yes, when it is outside your active test matrix and no script depends on it. Remove it through Xcode Components. Do not assume a beta Runtime behaves exactly like a stable one. Confirm that the required platform can be restored before deleting it, especially on a remote Mac where downloads, permissions, or persistence may differ.

How does deleting a simulated device differ from removing its Runtime?

A simulated device is one virtual hardware and data state. Its Runtime is the operating-system platform behind one or more devices. Deleting the device removes its app data and settings while usually leaving the platform available. Removing the Runtime is broader and can invalidate every device and test target using that platform.

Does clearing DerivedData affect the project?

It should not remove source files or signing materials when you target the correct DerivedData location. It does remove generated indexes and build intermediates, so the next build must recreate them. Check the path before removal, stop active jobs, and run a clean project build afterward. Keep dependency lockfiles and Archives outside the cleanup target.

What should you do when a remote Mac keeps filling with simulator data?

Separate Runtime storage, device data, DerivedData, Archives, logs, and dependency caches. Set retention rules for each category, then test reboot persistence and full build recovery. If required Runtimes and unattended builds still consume the available capacity, expand the host or split testing from build work instead of deleting essential components repeatedly.

A local Mac gives you direct physical access, predictable peripherals, and no network hop. It also leaves you responsible for the full purchase, storage planning, macOS and Xcode maintenance, power availability, backups, and keeping the machine online for continuous builds. A Windows or Linux workstation avoids buying another local computer, but it cannot provide the native macOS toolchain required for Xcode and App Store distribution.

For a workload that needs iOS 27 Runtime files, persistent Archives, recurring builds, and remote access, CALMVPS can be a more flexible test environment than repeatedly clearing a constrained local disk. Review the available Mac rental plans, select a period that matches your actual build cycle, and validate persistence, permissions, component installation, and recovery with a real project before committing to a longer arrangement. If your work needs constant heavy usage, specialized physical peripherals, or offline access, owning a local Mac may still be the better choice.