Недостаток места на диске у симулятора iOS 27: очистить или расширить в 2026 году?

Вы поддерживаете одно iOS-приложение и хотите оставить минимальный набор симуляторов без риска сломать сборку.

Или вы проверяете несколько версий iOS, параллельно используете стабильный и Beta-инструментарий, а удаление Runtime может сорвать ближайшую регрессию.

Третий сценарий — небольшая команда, которая держит Mac как постоянный узел сборки и тестирования. Здесь важна не разовая прибавка свободного места, а предсказуемое восстановление после очистки и перезапуска.

Важно: iOS 27 Simulator относится к тестовой среде. По состоянию на 21 августа 2026 года Apple указывает Xcode 27 Beta 4 как актуальную тестовую цепочку. Интерфейс Beta-компонентов и требования могут измениться, поэтому перед удалением сверяйте системные требования Xcode и заметки к выпуску Xcode 27.

Фраза «iOS 27 Simulator съел весь диск» часто объединяет несколько разных объектов. У них различный риск удаления и различный способ восстановления.

Simulator Runtime

Runtime — это установленная программная среда конкретной версии iOS для запуска виртуального устройства. Она нужна, чтобы создать или запустить устройство с соответствующей версией системы.

Удаление Runtime освобождает больше места, чем удаление одного виртуального устройства, но одновременно убирает возможность запускать все устройства, завязанные на этот Runtime. При следующем тесте компонент придётся установить снова. Способ управления компонентами описан в официальной инструкции Apple по дополнительным компонентам Xcode.

Не считайте любой каталог внутри ~/Library/Developer временным. В нём могут находиться компоненты, данные устройств, кэши и служебные файлы разных инструментов.

Данные симулированных устройств

Созданное устройство хранит приложения, настройки, логи, состояние базы данных и тестовые файлы. Оно связано с Runtime, но не равно ему.

Удаление одного устройства не удаляет сам Runtime. Поэтому этот вариант подходит, если у вас накопились старые копии iPhone или iPad, а соответствующая версия iOS всё ещё нужна. Для регрессионных тестов сначала сохраните сценарии, тестовые данные и способ повторного создания устройства.

DerivedData

DerivedData содержит промежуточные результаты сборки: индекс, продукты компиляции, метаданные и данные, которые Xcode может создать заново. Очистка обычно приводит к повторной индексации и полной или частичной пересборке проекта.

Это не удаление исходного кода. Но если проект зависит от локально подготовленных артефактов, нестандартных скриптов или незафиксированных настроек, после очистки ошибка может проявиться впервые. Поэтому перед удалением проверьте, что зависимости восстанавливаются из репозитория и менеджера пакетов.

Archives и зависимости

Archives нужны для последующей загрузки, повторной подписи, проверки символов и выпуска сборки. Удалять их как обычный кэш нельзя. Для условий, при которых архивирование может завершиться проблемой, используйте техническую заметку Apple об ошибках Archive.

Отдельно растут кэши Swift Package Manager, CocoaPods, Flutter, React Native и собственных инструментов. Их восстановление требует доступа к репозиториям, рабочей конфигурации и иногда секретам. Быстрая очистка может превратить проблему с диском в долгую остановку сборочного узла.

Сначала определите момент сбоя. Это влияет на решение.

• Если место заканчивается во время загрузки компонента, проверьте свободное пространство до начала установки и наличие старого Runtime.
• Если сборка падает после компиляции, смотрите DerivedData, архивы и кэши зависимостей.
• Если симулятор не запускается, проверьте данные устройств, состояние Runtime и права доступа.
• Если удалённый Mac снова заполняется без участия пользователя, ищите повторяющиеся сборки, логи, архивы и кэши, а не только Simulator Runtime.

В macOS откройте сведения о хранилище и зафиксируйте категории, которые система считает крупными. Затем в Xcode откройте раздел управления компонентами. Названия пунктов могут отличаться в Beta-версии, поэтому ориентируйтесь на актуальную документацию, а не на инструкцию для старого интерфейса.

Для дополнительной проверки используйте терминал:

df -h /
du -sh "$HOME/Library/Developer/"*
du -sh "$HOME/Library/Developer/CoreSimulator/"*
du -sh "$HOME/Library/Developer/Xcode/DerivedData/"*
du -sh "$HOME/Library/Developer/Xcode/Archives/"*

df -h / показывает свободное место в файловой системе. Команды du оценивают размер отдельных каталогов. Они не удаляют данные. Если каталог недоступен из-за прав, не меняйте владельца и не отключайте SIP ради одной проверки.

Имена пользователя и проекта здесь заменены переменной $HOME. Не вставляйте в команды путь из чужого руководства. Сначала убедитесь, что он относится к вашей учётной записи.

Удаление симулированного устройства освобождает его данные, но оставляет установленную версию iOS. Удаление Runtime убирает саму платформу и делает недоступными все устройства, которые от неё зависят.

iOS 27 Simulator Runtime можно удалять, но не вслепую

Безопасный критерий — Runtime не входит в активную тестовую матрицу, не нужен для текущего проекта и может быть повторно установлен из поддерживаемого источника.

Перед удалением проверьте:

• минимальную версию iOS в настройках проекта;
• основные версии, которыми пользуются ваши пользователи;
• задачи текущего релиза и ближайшей регрессии;
• установленный стабильный и Beta-Xcode;
• сценарии UI-тестов, привязанные к конкретной версии системы;
• доступность повторной установки компонента после удаления.

В Xcode используйте Components для удаления ненужного Runtime. Это предпочтительнее ручного удаления защищённых или служебных каталогов. Apple отдельно описывает добавление и управление Simulator Runtime в документации по дополнительным симуляторам.

Для одной небольшой программы обычно разумно оставить только Runtime, который нужен для текущей разработки, и версии, которые явно включены в ближайшую проверку. Но не превращайте это правило в универсальный приказ: приложение с несколькими минимальными версиями iOS требует другой матрицы.

DerivedData можно очищать после проверки восстановления

Перед очисткой зафиксируйте:

• чистый статус репозитория;
• версию Xcode;
• используемый SDK;
• команды установки зависимостей;
• переменные окружения;
• сертификаты и профили подписи;
• способ запуска тестов и архивирования.

После очистки Xcode пересоздаст производные данные, но это может занять заметное время и потребовать повторной индексации. На рабочем ноутбуке это неприятно. На постоянном сборочном Mac это ещё и риск очереди: несколько задач одновременно начнут заново скачивать или компилировать одни и те же зависимости.

Не удаляйте сертификаты, ключи и provisioning profiles под видом кэша. Они относятся к подписи, а не к временным результатам компиляции. Проверку распространения приложения после восстановления выполняйте по официальному процессу Archive и распространения.

Если ваша задача — только запустить приложение на iOS 27, очистка лишних старых устройств может быть достаточной. Если вы поддерживаете несколько поколений iOS, сначала создайте матрицу, а затем освобождайте место.

Разделите версии на три класса:

1. минимально поддерживаемая версия;
2. основная версия, на которой проходит ежедневная разработка;
3. iOS 27, необходимая для адаптации и проверки новых ограничений.

К каждому классу привяжите реальные сценарии: запуск, авторизация, покупка, push-уведомления, миграция данных и UI-тесты. Если старый Runtime нужен только для редкой ручной проверки, его можно удалить и устанавливать перед релизным циклом. Если он используется в CI ежедневно, повторная загрузка будет не экономией, а дополнительной точкой отказа.

Удаляйте отдельное устройство, когда проблема заключается в накопившихся данных. Удаляйте полный Runtime, когда сама платформа больше не входит в матрицу. Не смешивайте эти действия: после удаления устройства версия iOS остаётся доступной, после удаления Runtime — нет.

Сохраняйте описание устройств и тестовые фикстуры отдельно от локального состояния симулятора. Тогда переустановка Runtime не будет означать потерю воспроизводимости тестов.

Два Xcode могут использовать разные наборы компонентов и разные активные пути разработчика. Простое переключение xcode-select не удаляет старые Runtime и не очищает данные симуляторов.

Проверьте активную цепочку:

xcode-select -p
xcodebuild -version
xcrun simctl list runtimes

Первая команда показывает активный каталог разработчика. Вторая помогает увидеть выбранную версию Xcode. Третья перечисляет доступные Runtime. Команды только читают состояние, но список всё равно проверяйте перед удалением.

Для временного выбора инструментария используйте полный путь к конкретному Xcode:

sudo xcode-select --switch "/Applications/<Xcode-Version>.app/Contents/Developer"

Замените <Xcode-Version> на имя установленного приложения. Команда требует административных прав и меняет активный путь для последующих инструментов. Она не должна использоваться как способ «почистить» диск. О назначении xcode-select и настройках Command Line Tools читайте в документации Apple.

Стабильный Xcode оставляйте как путь возврата для производственной подписи и публикации. Beta можно переустановить, если она нужна только для проверки iOS 27, но перед удалением убедитесь, что рабочие сертификаты, скрипты и архивирование не привязаны к её окружению.

На узле непрерывной сборки очистка должна быть автоматизируемой и обратимой. Иначе вы освободите место сегодня, но получите неработающий pipeline после следующей ночной задачи.

Проверьте следующие точки:

• где хранятся Archives;
• сколько успешных архивов нужно оставить для отката;
• куда пишутся логи сборки и тестов;
• какие зависимости кэшируются;
• восстанавливаются ли кэши после перезапуска;
• сохраняются ли данные диска после остановки удалённого Mac;
• есть ли права на установку Runtime;
• может ли оператор подключиться через SSH или консоль при сбое;
• можно ли повторить подпись без ручного доступа к личному компьютеру.

Архивы удаляйте по политике хранения, а не по принципу «самые большие файлы». Например, оставляйте версии, которые реально нужны для отката текущего релиза, а промежуточные неуспешные результаты отправляйте в отдельное хранилище только при наличии такого процесса.

Логи должны иметь ограничение по сроку или размеру. Кэш зависимостей можно удалять только после проверки, что сборка умеет его восстановить. Удаление Simulator Runtime на сборочном узле допустимо лишь тогда, когда следующий запуск способен снова установить компонент без интерактивного подтверждения.

Для удалённого Mac полезно разделить задачи. Один узел может выполнять архивирование и подпись. Другой — содержать несколько Runtime и запускать UI-тесты. Это уменьшает конкуренцию за диск, но повышает требования к синхронизации исходников, секретов и результатов тестов.

Если ваша команда ещё выбирает конфигурацию постоянного узла, сначала сопоставьте рабочую матрицу с вариантами аренды Mac в CALMVPS. Не переносите среду до проверки политики сохранения диска и процедуры повторной установки компонентов.

Ниже — рабочая карта выбора. Она учитывает не размер одной папки, а повторяемость нагрузки.

Выбирайте очистку, если разрослись восстановимые данные и после удаления среда остаётся полной для текущих задач. Выбирайте расширение, если тестовая матрица обоснована, а удаление Runtime будет повторяться каждую неделю.

Выбирайте перенос, если локальный Mac регулярно прерывает сборки, не выдерживает одновременный Xcode и симулятор или должен оставаться свободным для другой работы. Но удалённая среда не заменяет физическое устройство для всех видов проверки: камера, Bluetooth, push-поведение и энергопотребление требуют отдельной стратегии.

Шаг 1. Зафиксируйте рабочее состояние

Сделайте чистый коммит или сохраните текущие изменения. Запишите активный Xcode, используемые Runtime, схему сборки и команду запуска тестов.

Шаг 2. Снимите карту диска

Проверьте системное хранилище и выполните команды df и du из раздела выше. Отдельно запишите размеры Runtime, устройств, DerivedData, Archives и зависимостей.

Шаг 3. Составьте тестовую матрицу

Для каждой версии iOS укажите причину сохранения. Если причины нет, Runtime-кандидат на удаление. Не удаляйте платформу только потому, что она самая старая или самая большая.

Шаг 4. Удалите устройства через штатные инструменты

Удалите неиспользуемые симулированные устройства и их данные. Сначала экспортируйте необходимые тестовые фикстуры. Не начинайте с ручного удаления системных каталогов.

Шаг 5. Удалите ненужный Runtime через Components

Проверьте, что он не нужен стабильному Xcode, Beta-сценарию и ближайшей регрессии. Удаляйте компонент штатным способом, описанным Apple.

Шаг 6. Очистите DerivedData

После очистки сразу выполните восстановление зависимостей и чистую сборку. Не удаляйте Archives и материалы подписи в рамках этой операции.

Шаг 7. Введите обслуживание сборочного узла

Настройте правило для архивов, логов и кэшей. Оно должно иметь понятный срок хранения и не затрагивать последний рабочий результат без резервного плана.

Шаг 8. Проверьте реальным проектом

Запустите установку зависимостей, сборку, тесты на нужном Runtime, Archive и проверку результата. Затем перезапустите Xcode или удалённый Mac и повторите критическую часть сценария.

Успех — это не только выросшее число свободных гигабайт. Среда должна снова создать приложение, открыть симулятор, выполнить тесты и сформировать архив без ручного восстановления неизвестных файлов.

Сначала определите, что именно возвращается. Если растёт DerivedData, ищите слишком частые чистые сборки и параллельные рабочие каталоги. Если растут Archives, введите хранение только успешных и необходимых для отката результатов. Если увеличиваются данные устройств, удаляйте неактивные устройства по расписанию.

Проверьте персистентность диска после перезапуска. В некоторых удалённых средах остановка, пересоздание и переустановка — разные операции с разными последствиями. Перед миграцией запишите, какие каталоги сохраняются, кто имеет права на установку компонентов и как восстанавливаются секреты подписи.

Для постоянной iOS-сборки полезно держать отдельный журнал:

• свободное место до запуска;
• проект и ветка;
• выбранный Xcode;
• Runtime;
• размер Archive;
• результат тестов;
• свободное место после завершения;
• причина последней очистки.

Так вы увидите повторяющийся источник роста, а не будете удалять данные наугад.

Если вы поддерживаете одно приложение, оставьте минимальный Runtime, удалите старые устройства и очистите восстановимые кэши. Если вы тестируете совместимость, сначала защитите матрицу и удаляйте только то, что не влияет на ближайшую регрессию. Если вы обслуживаете постоянный удалённый Mac, автоматизируйте контроль архивов, логов и кэшей, а затем решите, достаточно ли очистки для повторяющейся нагрузки.

Текущая схема с локальным Mac часто проигрывает не только из-за объёма диска. Она занимает рабочую машину, прерывается во время больших сборок, требует ручного обслуживания и плохо подходит для команды, которой нужен постоянно доступный узел. Постоянное удаление Runtime тоже не является решением: оно добавляет повторные загрузки и задерживает тестирование.

После диагностики сравните частоту очистки с реальной нагрузкой. Если необходимые iOS 27 Runtime, архивы и зависимости не могут стабильно сосуществовать, разумнее краткосрочно проверить рабочий процесс на удалённом Mac через доступные варианты CALMVPS, а затем решить, нужен ли постоянный перенос или только временная ёмкость для релизного цикла.