Скорость сборки Xcode: локальный MacBook vs выделенный Mac mini M4 в облаке

Почему медленные сборки обычно не вина Xcode

«Xcode снова тормозит» — одна из самых частых жалоб разработчиков. Но тот же проект на разных машинах может собираться в два-три раза дольше или быстрее — узкое место чаще всего в аппаратных ресурсах и термике, а не в сломанном компиляторе. Типичные случаи: MacBook Air на 8 ГБ уходит в swap при чистой сборке, удваивая время линковки; старый MacBook Pro на Intel троттлит, когда вентиляторы на максимуме; или вы архивируете с открытым Simulator, двадцатью вкладками Chrome, Slack и AI-инструментом для кода — конкуренция за память не даёт параллельной компиляции Swift задействовать все ядра.

Облачный Mac не ускоряет Xcode волшебством. Его ценность — вынести компиляцию с повседневного ноутбука: выделенное железо, фиксированная среда и отсутствие прерванных задач из-за закрытия крышки или энергосбережения. Это сравнение сфокусировано на полных сборках — Release Archive после rm -rf DerivedData каждый раз — потому что именно здесь различия между машинами видны наиболее чётко, и именно здесь важны лимиты памяти и охлаждения.

Методология: как сохранить честное сравнение

Бенчмарки проваливаются, когда каждая машина в разном состоянии. Мы зафиксировали эти переменные, чтобы цифры отражали железо, а не удачу:

1. 01
   Один коммит Git, одна ветка

   Все три машины выполнили git checkout v2.4.0-buildbench с зафиксированным Package.resolved, чтобы исключить дрейф версий SPM. Облачный узел клонировал приватный репозиторий по SSH с Deploy Key только для чтения.

2. 02
   Настоящая чистая сборка

   Перед каждым прогоном: rm -rf ~/Library/Developer/Xcode/DerivedData и xcodebuild clean. Без инкрементального кэша — имитация полной CI-сборки перед релизом.

3. 03
   Логировать реальное время и пик памяти через /usr/bin/time -l

   Обёртка вокруг xcodebuild фиксировала real/user/sys и максимальный resident set size. На ноутбуках дополнительно отслеживали swap и температуру CPU в «Мониторинге системы» (сэмплирование через powermetrics).

4. 04
   Без лишней нагрузки на ноутбуки

   Во время тестов не запускали Simulator, браузер и мессенджеры. В реальной жизни так бывает редко — поэтому сценарии повседневной разработки обсуждаем отдельно ниже.

Реальное время полного Archive: медианы трёх прогонов

Таблица ниже — медианы трёх чистых Archive на каждой машине. Облачный M4 и M3 Pro близки по скорости, но M4 был стабильнее на фазе линковки — всего ±4 секунды за три прогона; у M3 Pro один прогон был на 22 секунды медленнее из-за кратковременного троттлинга. MacBook Air M2 8 ГБ — другая история: сильный swap в середине компиляции, загрузка CPU на линковке застряла ниже 40 %.

Несколько цифр, на которые стоит обратить внимание: M4 был примерно на 10 % быстрее M3 Pro — в основном потому, что параллельная компиляция Swift могла удерживать все 10 performance-ядер, а у Mac mini больше термозапаса, чем у 14" ноутбука под длительной нагрузкой. Air M2 не медленный в однопотоке — 8 ГБ RAM в 2026 году просто недостаточно для средних проектов. Добавьте зависимости SPM — компилятор, линкер и системный кэш легко превышают физическую память.

Инкрементальные сборки: сокращается ли разрыв?

Полные чистые сборки — стресс-тест; в повседневной работе — инкрементальная компиляция после небольших правок. Мы также измерили сценарий «изменить один файл SwiftUI View, затем Debug build» (DerivedData сохранён):

Для инкрементальной работы локальный M3 Pro часто обгоняет удалённый M4 — нет сетевого round-trip, локовая файловая система NVMe. Облачный Mac выигрывает в изоляции нагрузки, а не в скорости отклика на каждую строку: выносите полные Archive, ночные пакетные тесты и многосхемную упаковку; оставляйте Simulator и IDE плавными на ноутбуке. На Air 8 ГБ инкрементальные сборки с открытым Simulator нестабильны — разделение нагрузок окупается ещё сильнее.

Нагрев, вентиляторы и работа во время сборки

Реальное время — только половина истории. Мы логировали температуру корпуса и обороты вентиляторов во время каждой сборки (у Air нет вентилятора — вместо этого температура ядра и троттлинг):

MacBook Air M2: через ~2 минуты CPU превышал 95 °C с заметным троттлингом; клавиатура слишком горячая для комфортного набора. Остаточный нагрев после трёх прогонов замедлял следующие инкрементальные сборки на 8–12 % по сравнению с холодным стартом.

MacBook Pro M3 Pro: вентиляторы выходили на 4500–5200 об/мин за 30 секунд — достаточно громко, чтобы прервать видеозвонок. На питании производительность стабильна; пик ~88 °C без сильного троттлинга.

Mac mini M4 ZovCloud: температура в дата-центре стабильна; вентиляторы всё время в низком диапазоне (~1800–2200 об/мин). Запуск по SSH — ноль локального шума и ноль нагрева. Для разработчиков, у которых ноутбук — единственная машина, это часто важнее, чем сэкономить 30 секунд.

Удалённый workflow: запуск по SSH и получение артефактов

После бенчмарков — практика. Облачный M4 был на узле Сингапур; round-trip SSH с домашнего оптоволокна западного побережья США ~38 мс. Мы не открывали GUI Xcode в облаке (VNC доступен для отладки, не для ежедневной работы) — сборки запускались скриптом:

ssh zovcloud@node 'cd ~/RetailApp && git pull && ./scripts/ci-archive.sh'

ci-archive.sh вызывает xcodebuild archive, затем забирает .xcarchive или экспортированный .ipa через scp или загружает в объектное хранилище команды. Сквозное реальное время (pull + чистый archive + scp артефакта 180 МБ) около 5 мин 10 с — всё ещё быстрее локальных сборок на Air M2, близко к локальному M3 Pro.

С GitHub Actions или Fastlane зарегистрируйте облачный Mac как self-hosted Runner (см. наше практическое руководство по Mac в облаке для Xcode CI/CD) — push запускает сборки на M4 без влияния на локальную машину. Для команд, которым полные сборки нужны только в дни релиза, аренда по дням с освобождением после релиза выгоднее, чем держать ноутбук круглогодичной compile-машиной.

Сравнение затрат: когда выделенная build-машина оправдана

Чтобы превратить производительность в решение, нужны частота и бюджет. Допустим, восемь полных Archive в месяц (релизы + хотфиксы), остальное время — инкрементальная разработка:

Если у вас уже M3 Pro, облачный M4 добавляет лишь ~10 % скорости компиляции — реальная ценность в изоляции нагрузки и стабильности CI. Если вы ведёте средний проект на Air 8 ГБ, облачные сборки дают мгновенно заметный апгрейд — одна сборка сокращается с почти 10 минут до менее 4, а ноутбук может продолжать крутить Simulator для проверки UI.

Перенос тяжёлых компиляций в облако: практический путь

Многие слышали об облачных Mac, но застревают на двух вопросах: удалённая машина будет медленнее локальной? Месячная аренда — пустая трата? Этот бенчмарк отвечает достаточно ясно: для полного Release Archive выделенный M4 ZovCloud сопоставим с топовым MacBook Pro и сильно обгоняет 8-гигабайтные ноутбуки начального уровня; инкрементальный Debug оставляйте локально; чистые сборки, Archive и ночные batch-задачи — в облако.

ZovCloud предлагает выделенные физические Mac mini M4 (10-ядерный CPU, 16 ГБ унифицированной памяти, 256 ГБ NVMe, выделенная полоса 1 Gbps) — без виртуализации и перепродажи ресурсов. Развёртывание за 1–5 минут после оплаты; пять регионов — Сингапур, Япония (Токио), Корея (Сеул), Гонконг, восток США. От $19.8/день, без долгосрочного контракта; включите на неделю релиза, освободите в спокойный период — проще, чем покупать второй Mac mini для домашних сборок.

Три способа доступа: VNC в браузере (разовая отладка), SSH (сборки скриптом — рекомендуется), или подключение как Runner GitHub Actions / Jenkins (командный CI). Для параллельных Archive нескольких приложений добавьте связь Thunderbolt 5 (см. наш бенчмарк кластера TB5).

1. 01
   Определите узкое место

   Swap на 8 ГБ → сначала перенесите полные сборки; M3 Pro, но CI забивает машину → ночные batch; очередь → подключите Runner.

2. 02
   Выберите регион и разверните узел

   Пользователи APAC → Сингапур; приложения для японского рынка → Токио. SSH-учётные данные выдаются автоматически после заказа — см. Центр помощи.

3. 03
   Синхронизируйте проект и подпись

   Клонируйте репозиторий, импортируйте Distribution-сертификат, пройдите первый Archive. Закоммитьте скрипты в репозиторий — дальше одна локальная команда запускает облачные сборки.

Серебряной пули для скорости компиляции нет: облако не ускорит Debug-инкременты в 10 раз, и флагманский ноутбук не станет тихим только потому, что обновился Xcode. Рациональное разделение — интерактивная разработка локально, ресурсоёмкие сборки на выделенном железе — а M4 по дням от ZovCloud заполняет промежуток между «купить второй Mac» и «превратить ноутбук в обогреватель».