😒 ⏳Как ускорить сборку в Xcode и перестать ждать часами

🔗 Статья: How to speed up Xcode build time

Основные идеи:

1️⃣ ИМХО, самая важная - использовать Build Time Summary (и его ассистента/визуализатора) — мощный встроенный способ увидеть узкие места на сборке, для того чтобы принимать решения не вслепую.
Для детализации на CI: попробуйте xclogparser или xcode-build-times.
Как уже не раз говорил, наблюдаемость и инспекция - наше все и то с чего всегда стоит начинать.

2️⃣ Проверить флаги сборки, оптимизации и параллельные билды.

3️⃣ Правильно чистить DerivedData — мы недавно подробно писали об этом тут.

4️⃣ Компилировать только, то что нужно для текущего запуска:
Автор предлагает проверить конфигурацию схемы.
А я бы предложил в том числе, смотреть на уровне исходников и анализа компиляции, например: исключать моки из сборок для Debug-а, если вы их модуляризуете.

5️⃣ Тоже имба в случае верной настройки:
input/output files в кастомных скриптах/фазах сборки (например, для SwiftLint: настройте фазу и используйте параметры --use-script-input-file-lists и --cache-path) — чтобы Xcode не перезапускал всё подряд, на каждом прогоне.

💡 От себя также добавлю:

1️⃣ Bitcode — мёртв. Apple официально отключила его поддержку с iOS 16 (см. release notes), поэтому можно смело его выкидывать из головы.

2️⃣ Оптимизация графа зависимостей: через API/Impl, Dependency Inversion и контроль build critical path — мощнейший рычаг (я писал об этом здесь).

3️⃣ Build cache (локальный или remote) — просто имбовый импакт на многомодульном проекте.

🔥 В сумме это всё может дать десятки процентов прироста при правильном использовании.

#L #Xcode #CompileTime

👏

☺️ 💻 Ваш MacBook vs время сборки: что реально влияет?

Занимаемся сейчас апдейтами процесса анализа время сборки на компьютерах разработчиков и на CI.
Да и вчерашний пост, про время компиляции хотелось бы развить.
Поэтому чуть мыслей еще своих:

Недавно сравнивал время сборки на двух маках, и заодно посмотрел, что говорят бенчмарки.

💡 Существует интересный бенчмарк компиляции синтезированного, но около, реального проекта:

💻MacBook Pro 14" (2023, M2 Pro, 10-core, 16 ГБ RAM)
— средний результат по XcodeBenchmark ~119 сек.

💻MacBook Pro 16" (2023, M3 Pro, 12-core, 36 ГБ RAM) ~134 сек
В идеальных услвоиях прирост небольшой, но реальная разница может ощущаться в реальных условиях. Так, в моем кейсе проблемы были из-за памяти.

❓ Что подтверждают бенчмарки (цифры осознанно усреднены):
- переход с M1 → M2 даёт ~10–15% прироста;
- M2 → M3 — ещё +10–20% в зависимости от конфигурации и RAM.
При одинаковом объёме оперативной памяти отрыв между поколениями минимален.
Решает не только CPU, но и стабильность под нагрузкой, на что может влиять: RAM, тех процесс (на M3 - 3нм), sustained performance per watt.

🧠 Про память:
Если Xcode, Slack, Zoom, браузер и антивирус живут одновременно — 16 ГБ быстро заканчиваются, macOS уходит в swap и сборка резко замедляется.
Не раз читал, что при unified memory (в M-чипах работает как общая шина между CPU/GPU), нехватка RAM мгновенно сказывается на производительности.
📎 Apple Silicon memory architecture

❗️ Вывод
Количество ядер, тех процесс, количество RAM - каждый из параметров важен.
Нельзя создавать узких горлышек нагружая свою рабочую машину.
Так при исчерпывании RAM можно, как в моему случае столкнуться с проблемами и тратить время на анализ. 👍 
Следите за процессами, которые могут отъедать память, если хотите предсказуемое время сборки и комфортный DX.

P.S.: Отдельно можно говорить про скорость SSD и другие параметры, может сталкивались с другими проблемами и есть решения?

#L #Macbook #UnifiedMemory #Benchmark #CompileTime

👏