Ускорение сборки Xcode: локальный MacBook против выделенного облачного M4

Зачем вообще такое сравнение?

В iOS-сообществе «долгая сборка» — почти общее место. Семантический анализ Swift-фронтенда, построение графа зависимостей модулей, линковка крупного бинарника — каждый шаг жрёт CPU и память. У соло-разработчиков чаще всего MacBook Air: лёгкий, с хорошей автономностью, но 8 ГБ памяти и пассивное охлаждение при полной сборке в Xcode часто не вытягивают.

Аренда Mac в облаке — не новинка, но у многих провайдеров это виртуализация или shared-хостинг: заявленные цифры и реальный опыт сборки расходятся. ZilCloud отдаёт физический Mac mini M4 без соседей — без гипервизора, без overselling, спецификация как у Apple: 10-ядерный CPU (4 performance + 6 efficiency), 16 ГБ унифицированной памяти, 256 ГБ NVMe SSD, выделенный публичный канал 1 Гбит/с.

Конкретный вопрос теста: если не менять локальный ноутбук, а перенести сборку на облачный M4, насколько быстрее? Станет ли ежедневный цикл разработки комфортнее? Окупается ли это по деньгам и по ощущениям? Все цифры ниже — с одной тестовой машины, одного скрипта и одной версии Xcode; воспроизводимо.

Тестовый проект и методология

Объект — реальное коммерческое SwiftUI-приложение (далее RetailApp) такого масштаба:

около 186 Swift-модулей (3 локальных Swift Package и 2 зависимости CocoaPods), более 1 240 исходников, линкованный Release-артефакт ~84 МБ. Включены строгие проверки Swift 6 concurrency, build-фазы SwiftLint и SwiftFormat. Для indie-разработчика это уже «средне-крупный» проект; на 8 ГБ холодная сборка регулярно давит память.

Единая команда сборки

Чтобы исключить разницу GUI, все замеры — через xcodebuild в CLI с /usr/bin/time -l для wall-clock и пиковой памяти:

# Clean build folder first
xcodebuild -project RetailApp.xcodeproj \
  -scheme RetailApp \
  -configuration Release \
  -destination 'generic/platform=iOS' \
  clean build \
  CODE_SIGNING_ALLOWED=NO \
  | tee /tmp/xcodebuild.log

# Wall-clock timing wrapper
/usr/bin/time -l xcodebuild -project RetailApp.xcodeproj \
  -scheme RetailApp \
  -configuration Release \
  -destination 'generic/platform=iOS' \
  build CODE_SIGNING_ALLOWED=NO

Перед тестом на каждой машине — sudo purge для сброса файлового кэша; 3 холодные сборки, берём медиану. Инкрементальная: правка одного View-файла (~120 строк SwiftUI), затем build без clean — тоже 3 прогона, медиана. Spotlight и лишние фоновые приложения отключены; на Air — Low Power Mode выкл, кривая вентилятора через powermetrics.

Удалённый workflow сборки

На облачном узле код через git clone (репозиторий ~380 МБ), зависимости — pod install и swift package resolve на сервере, чтобы окружения совпадали. Локально можно по SSH гонять xcodebuild на облаке или редактировать в VS Code Remote SSH с MacBook, а компиляцию оставить на удалённой машине — ноутбук только пишет код и смотрит логи.

Холодная сборка (Clean Build): цифры

Холодная сборка лучше всего раздвигает разрыв: нет Derived Data, полностью работают Swift-фронтенд, Clang-бэкенд и линкер. Ниже медианы трёх конфигураций (плюс контроль — MacBook Pro M3 Pro 18 ГБ коллеги как ориентир «апгрейда локальной машины»):

Облачный M4 быстрее MacBook Air M2 примерно в 2,18 раза и даже опережает MacBook Pro M3 Pro 18 ГБ примерно на 20%. Дело не только в поколении чипа: на Air 8 ГБ в пике сборки ушло в 4,2 ГБ swap, powermetrics показал снижение performance-ядер с ~3,4 ГГц до ~2,6 ГГц к 6-й минуте из-за температурного лимита; Mac mini M4 в стойке держит высокие частоты, 10 ядер загружены почти полностью, 16 ГБ памяти — без swap.

По ощущениям: на Air при холодной сборке вентилятор за 2 минуты на максимум, клавиатура горячая, писать код неудобно; сборка в облаке идёт удалённо — ноутбук тихий и прохладный, можно читать документацию или сидеть на видеозвонке.

Инкрементальная сборка и ежедневный цикл

В работе инкрементальная сборка встречается чаще холодной. Правка одного SwiftUI View и повторный build — показатель «насколько цикл разработки течёт гладко»:

Разрыв в инкрементальной сборке меньше, чем в холодной, но M4 в облаке везде впереди. Особенно заметна правка Bridging Header: на Air почти 13 минут — хватит заварить кофе; в облаке 5 мин 19 с — ценно для legacy-проектов с Objective-C мостом.

Нагрев, шум и стабильность

Сборка — не только «на сколько секунд быстрее», но и может ли машина долго держать темп. За 2 часа гоняли холодную сборку каждые 15 минут (8 раундов):

MacBook Air под длительной нагрузкой показывает явную термальную деградацию: 8-й раунд на 21% медленнее первого, swap вырос с 4,2 до 6,1 ГБ. Mac mini M4 в облаке колеблется в пределах 2% — в духе заявленного ZilCloud SLA 99,9%. Для длинного CI или пакетного Archive стабильность сама по себе — продуктивность.

Симулятор и Archive

Кроме обычного build проверили два частых сценария:

Запуск iOS Simulator + установка: на облачном M4 iPhone 16 Pro Simulator и установка RetailApp Release — от xcrun simctl boot до первого кадра UI ~38 с; на Air M2 ~52 с, плюс симулятор ещё сильнее забивает память. Через браузерный VNC видно экран симулятора — удобно для быстрой приёмки UI; для анимаций лучше сторонний VNC-клиент.

Archive и экспорт IPA: xcodebuild archive + -exportArchive в облаке — 14 мин 22 с (с подписью); на Air M2 — 28 мин 51 с. Сертификат из Keychain экспортируете в .p12, импортируете на узел — как локально. IPA забираете через scp или грузите в TestFlight; с сингапурского узла до серверов Apple задержка ~180 мс, загрузка 84 МБ IPA ~3 минуты.

Стоимость и стратегии использования

Цифры производительности мало что решают, если по деньгам не сходится. ZilCloud считает по дням: стандартный Mac mini M4 — $20,9/день, помесячно $103,9/месяц, без долгосрочного контракта. Типичные схемы по итогам теста:

Стратегия A — узел только для сборки (по дням): арендуете в дни холодных build, релизных пакетов и интеграционных тестов — например 2 дня в неделю, ~$20,9 × 8 ≈ $167/месяц; каждая холодная сборка экономит 11+ минут, Air не занят компиляцией.

Стратегия B — постоянный CI-узел (помесячно): Webhook на Git, каждый push гоняет xcodebuild test в облаке — $103,9/месяц; GitHub Actions macOS runner ~$0,08/мин (20-минутная холодная сборка уже $1,6). Для активной команды окупается за неделю.

Стратегия C — короткий спринт (понедельно): $55,9/неделя перед релизом — миграция, крупный рефакторинг, TestFlight; после релиза узел отключаете, простоя нет.

Если локально уже M3 Pro+ и ≥18 ГБ RAM, выигрыш облака — в разгрузке ноутбука и параллельном CI, а не в абсолютной скорости; для MacBook Air на 8 / 16 ГБ облачный M4 — один из самых выгодных способов ускориться: новый M4 Mac mini от $599, плюс монитор и администрирование.

GitHub Actions и свой CI

Многие команды уже на macos-latest в GitHub Actions. Тот же проект ушёл в приватный репозиторий со стандартным workflow:

jobs:
  build:
    runs-on: macos-14
    steps:
      - uses: actions/checkout@v4
      - name: Install deps
        run: pod install --repo-update
      - name: Build
        run: xcodebuild ... clean build

Холодная сборка в Actions — 34 мин 20 с суммарно (очередь ~8 мин, pod install ~6 мин, сама компиляция ~20 мин). На ZilCloud Derived Data и кэш CocoaPods живут на локальном диске узла — со второго прогона пайплайн укладывается в 12 минут, без очереди.

Actions силён в интеграции с GitHub и нулевом ops; слаб в нестабильности shared runner, долгом cold start, ограниченном кэше и очередях в пик. Не взаимоисключающие варианты: lint и unit-тесты в Actions, Release Archive — на выделенном узле ZilCloud.

Удалённая разработка: опыт и подводные камни

Перенос сборки в облако меняет привычный workflow. Кратко по итогам теста:

SSH + сборка в облаке (рекомендуем): VS Code / Cursor через Remote SSH, LSP на удалённой машине, после сохранения — xcodebuild в терминале. Задержка на ввод почти незаметна (сингапурский узел из Москвы ping ~110 мс, из Европы ~160–200 мс); для крупных бинарников в git — git-lfs.

Браузерный VNC: из консоли ZilCloud — когда нужен GUI Xcode или симулятор. Для статичного UI хватает; анимации — RealVNC или аналог.

Камень 1 — Keychain и сертификаты: первый раз импортируйте .p12 и provisioning profile; в Keychain разрешите codesign доступ к приватному ключу, иначе errSecInternalComponent.

Камень 2 — путь Command Line Tools: на свежем узле иногда нужно sudo xcode-select -s /Applications/Xcode.app, иначе xcodebuild смотрит на CLT и не находит SDK.

Камень 3 — часовой пояс в логах: по умолчанию UTC; для CI-логов команды — sudo systemsetup -settimezone Asia/Singapore или ваш регион.

Хватает ли MacBook — или всё же нужен облачный узел?

После цифр логичный вопрос: может, проще апгрейдить железо или оптимизировать проект?

С бюджетом на MacBook Pro M4 Pro 36 ГБ память и охлаждение действительно перестают быть узким местом — но от ~$2 499, и при полной сборке машина всё равно занята: Figma, Slack и Zoom одновременно некомфортно. Для соло или маленькой команды это тяжёлый разовый чек.

Вспоминают AWS EC2 Mac: официальное железо Apple, но от ~$1,083/час и минимум 24 часа (~$26/день) — дороже $20,9/день у ZilCloud, без гибкой посуточной остановки и без кластера Thunderbolt 5. Плюс квоты и онбординг EC2 Mac тяжелее, чем 1–5 минут автоматической активации ZilCloud после оплаты.

GitHub Actions, Bitrise и прочий shared CI хороши для стандартных пайплайнов, но холодная сборка, постоянный кэш и работа с симулятором на shared runner менее предсказуемы; в пик очередь 10–20 минут — реальная цена в день релиза.

Роль облачного Mac mini M4 проста: не меняя локальный Mac, получить всегда «полный газ» на отдельной машине для сборки. 10 ядер CPU без соседей, 16 ГБ памяти, выделенный канал 1 Гбит/с, пять узлов (Сингапур / Токио / Сеул / Гонконг / восток США), от $20,9/день, без overselling. Арендуете на спринт — или держите постоянно — гибкости, которой нет у покупки нового Mac или долгого облачного контракта.

MacBook Air вполне тянет iOS-разработку, пока проект не вырос. Когда он вырос — сборку на облачный M4, тишину и автономность — локальному ноутбуку часто оказывается самым выгодным разделением труда.