😏 🧠 Xcode Cache и новое будущее сборки в Xcode 26

Tuist представил обзор новой возможности Xcode Cache, построенной на концепциях CAS (Content-Addressable Storage) и hermetic builds.
Это огромный шаг к тому, чтобы сборки в Xcode стали детерминированными, воспроизводимыми и кэшируемыми на уровне артефактов, а не просто DerivedData.

🔹 Что это значит:
Раньше Xcode кэшировал результаты компиляции в DerivedData, но кэш был хрупким — зависел от путей, флагов, конфигураций, окружения. Любое отличие — и пересборка.
Теперь Xcode 26 использует CAS: каждый артефакт (объектный файл, ресурс, модуль) имеет хэш и сохраняется в едином хранилище.

Это даёт:
- более стабильное повторное использование кэша между сборками;
- меньше конфликтов и пересборок;
- основу для дистрибутивного и общего кэша в CI и между машинами.

🔹 Hermeticity:
Xcode движется к «герметичным» сборкам — когда результат зависит только от входных данных (исходников и флагов), а не от состояния системы. Это делает кэш полностью воспроизводимым.

🔹 Разница с Tuist Cache:
- Tuist уже давно реализует бинарный кэш модулей. Но подход Xcode более низкоуровневый:
- Xcode Cache работает на уровне компиляции и артефактов.
- Tuist Cache — на уровне модулей и фреймворков (binary cache).
Вместе они могут дать максимальный эффект: Tuist управляет сборкой и модуляризацией, Xcode — хранением и повторным использованием артефактов.

🔹 Что дальше:
Apple фактически закладывает фундамент новой архитектуры сборки. В перспективе DerivedData может превратиться в просто тонкий слой над CAS-хранилищем.

🧩 Мы тоже следим за этой эволюцией. В наших проектах Tuist активно используется, и появление Xcode Cache — отличная новость.
Это шаг к тому, чтобы CI стал быстрее, сборки стабильнее, а локальная разработка — отзывчивее.

📎 Tuist Blog

#L #Tuist #Xcode26 #BuildCache #XcodeCache

👏

🤫 🚀 "Smart before fast" Tuist
Статья о масштбировании команды разработки и распространенные, принимаемые решения.

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

#L #Tuist #BuildCache #ImpactAnalysis

👏

🫠 Пока отдыхал, постил мало, но читать не переставал.
Поэтому буду по-тихоньку "доставать из загашника".

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

Он берёт iOS-сборку и насильно приводит её к детерминированному виду:
1. генерирует umbrella SPM-пакет как единый build graph
2. приводит DerivedData к стабильным абсолютным путям
3. поверх этого строит свой slot-based кеш.

После этого артефакты сборки «вдруг» становится переносимым: их можно zip-нуть и перекинуть между CI-раннерами, потому что внутри больше нет отличий в путях и случайных хешей.

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

С инженерной точки зрения — решение тяжёлое и хрупкое.

Это не то, что хочется тащить в прод.

Зато как упражнение для насмотренности — отличное, имхо, конечно.
Статья очень наглядно показывает, проблемы о которых мы уже общались ранее в разрезе tuist-а, из-за чего сложно сделать норм-кэш из коробки в iOS.
P.S.: Напоминание. Xcode 26 compilation cache делает лучше, но не идеально. Все еще ждем "красоты" из коробки.

#L #BuildCache #iOS #Tuist #xcode

👏