😏 🧠 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

👏

🤔 Combine vs AsyncStream — что выбрать в 2025?

Наткнулся на обзор базовых функций AsyncStream
, где автор сравнивает Combine и AsyncStream — и делает вывод: для сложных кейсов (debounce, merge, combineLatest) пока async/await в чистом виде проигрывает.

😳 Но!

🧩 Swift Async Algorithms
- Apple выпустила пакет Swift Async Algorithms, который добавляет к AsyncSequence знакомые реактивные операторы: debounce, throttle, combineLatest, merge, zip и другие.
- Это значит, что с помощью Async Algorithms можно “достроить” AsyncStream почти до уровня Combine — реактивное программирование доступно и в мире async/await.
👉 swift-async-algorithms

🍎 Что со SwiftUI?
Раньше реактивная связка данных (@Published, ObservableObject, @State, .onReceive()) полностью зависела от Combine.
С iOS 17 / Swift 5.9 появился новый Observation framework с макросом @Observable, который заменяет Combine.

Теперь можно писать так 👇

import Observation
@Observable 
final class ViewModel {
    private(set) var count = 0
    func increment() { count += 1 }
}

И во View просто использовать:

let model = ViewModel()

SwiftUI автоматически перерисует интерфейс при изменении count.

⚙️ Новый Observation не использует Combine — он реализует надежную, типобезопасную и производительную реализацию шаблона проектирования «Observer» (строится на keyPath-ах).
👉 infinum.com

Для iOS 13+ можно использовать библиотеку Perception — backport Observation без Combine.

⚡️ Производительность:
- async/await и AsyncSequence компиляторно оптимизированы и имеют меньший оверхед, чем цепочки Combine с AnyCancellable.
- При линейной обработке событий async-подход быстрее и проще.
- Но при многоступенчатых реактивных пайплайнах (switchMap, flatMap, retry) Combine остаётся удобнее и гибче.

📌 Вывод:
- Если вы создаёте новый проект или модуль — берите async/await + Async Algorithms + Observation. Код проще, быстрее и ближе к будущему Swift.
- Если у вас уже большая система на Combine — не спешите с миграцией, но точно стоит начать экспериментировать 👀
- Swift всё увереннее движется к миру async/await — и это уже не тренд, а курс платформы.

#L #AsyncStream #AsyncSequence #asyncawait #Combine #Observation #Perception

👏

🤔 🧠 Осознанное создание легаси для самих себя.

Недавно мы обсуждали, стоит ли менять инструмент мокирования в юнит-тестах.

У нас есть два решения:
🧩 SHInstantMock (построен на базе InstantMock) — динамический, мощный, с магией под капотом.
Работает в рантайме, позволяет многое, но требует аккуратности: MockUsable, runtime проверки, не всегда типобезопасно.
Мы написали свои макросы для него, чтобы сократить бойлерплейт — и это реально улучшило DX.
⚡️ Spyable — простой, макросный, статически типизированный.
Меньше магии, проще дебажить, порог входа ниже.

Хочется постепенно переписать «легаси» с InstantMock на Spyable.
Возможно, даже попробовать AI-помощника для автоматического переписывания моков и тестов.

И вот главный вопрос, который у нас возник 👇

🎯 Насколько вообще целесообразно обновлять стек инструментов, если старый ещё справляется?

Зачем это делать?
💡 DX — меньше бойлерплейта, быстрее писать и читать тесты.
👥 Найм — проще входить новым инженерам, особенно если инструмент ближе к современным подходам (Swift Macros, compile-time generation).
🧱 Поддержка — статическая типизация уменьшает хрупкость кода и неожиданные падения.
🤖 Эволюция — шаг в сторону будущего Swift, где runtime-инъекции постепенно уступают compile-time инструментам.

Но есть и обратная сторона:
📉 Цена миграции (особенно если у вас сотни тестов).
🔄 Риск поломать то, что и так работает.
⏳ Возможно, это просто "движение ради движения".

По сути — мы осознанно создаём новое легаси для самих себя, надеясь, что новое решение будет более «здоровым» и предсказуемым.

❓ А вы как считаете — стоит ли обновлять инструменты, если текущие работают, или лучше выжимать максимум из старых решений?

#L #Swift #Testing #Mock #Macros #DX #AI #EngineeringPhilosophy

👏

😏 🔍 Наблюдаемость на мобилке — больше, чем логи.
Kodeco выпустили свежий туториал по observability в iOS.

Ребята показали, как использовать OpenTelemetry на мобильных устройствах:
🏆собирать performance-транзакции,
🏆писать логи и события,
🏆анализировать краши и аномалии через MetricKit.

Инструмент мощный — в умелых руках можно построить полную картину поведения приложения, почти как на сервере.

⚙️ При этом схожий результат можно получить и проще — например, настроив Sentry: там тоже есть трассировки, логи, краши и удобная интеграция с приложением и CI/CD.

DX, конечно, в Senty гораздо выше, и продукт мощнее, но за это надо платить.

У инструментов разные акценты:
👉 OpenTelemetry — открытый стандарт, гибкость, но больше ручной настройки.
👉 Sentry — готовая экосистема, но с ограничениями по лицензии и стоимости.

И в итоге вопрос не в “что выбрать”, а зачем вообще наблюдаемость нужна.

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

📈 Наблюдаемость — ключ к зрелой мобильной разработке.
Это то, что помогает не просто чинить баги, а понимать продукт изнутри.

#L #iOS #observability #OpenTelemetry #Sentry #MetricKit #performance #mobileengineering

👏

🤔 🧠 AI против кроссплатформы: где теперь настоящая эффективность

Вышла новёхонькая статья, Livsy Code поднимается интересная мысль:
Которую к слову уже не первый раз поднимают (вот пример от iOS Makes Me Hate):
ИИ постепенно нивелирует преимущества кроссплатформенных решений.

Раньше их сила была в том, чтобы “писать меньше кода” и “разрабатывать быстрее”.
Теперь же, похожие задачи — устранение бойлерплейта, ускорение разработки, автогенерация типовых экранов и API — решаются за счёт AI-агентов и инструментов, встроенных в IDE.
Фактически, AI делает нативную разработку почти такой же быстрой, но без ограничений фреймворков вроде Flutter или React Native.

Контр-пример: в новостной повестке — Apple выпустила SwiftSDK for Android, позволяющий собирать Swift-пакеты под Android и вызывать их через JNI.
Интересный шаг: Swift постепенно перестаёт быть “только про iOS”.

Но всё же, на практике — пока что это больше технологическое любопытство, чем реальный продакшн-тул. Имхо, конечно.

📌 Вывод:
AI съедает ценность кроссплатформы.
Будущее — не в “один код на всё”, а в умном нативе, где рутинную часть берут на себя агенты и генераторы.
Кроссплатформа теперь — это не про экономию, а про компромиссы.

#L #AI #CrossPlatform #SwiftSDKforAndroid

👏

😳 🧠 Agentic AI и безопасность — кто контролирует твои данные?

Наткнулся на интересную статью в блоге Мартина Фаулера — Agentic AI Security.
Она разбирает безопасность в работе LLM и объясняет, почему использование агентов — это не просто “умные помощники”, а ещё и новые векторы уязвимостей.

Заглавный вопрос статьи: LLM не различает данные и инструкции.

Когда агент объединяет несколько итераций текста и вызовов инструментов (MCP, внешние API, CLI и т.п.) в один большой контекст, он может “съесть” вредоносную инструкцию прямо из данных.

💉 Так появляется prompt injection — когда данные превращаются в команды.

Korny Sietsma, автор статьи, приводит ссылки на смежные материалы и называет это "смертельной триадой" угроз:

- Sensitive Data is the core thing most attackers want - this can include things like browser cookies that open up access to other data.
- Неочевидность границ контекста — модель не знает, что безопасно, а что нет.

- Untrusted Content can include commands that the LLM might follow.
- Инъекция инструкций — злоумышленник подмешивает вредоносные команды в текст.

- External Communication allows the LLM application to send information back to the attacker.
- Автоматизация действий без контроля — агент сам выполняет то, что “кажется логичным”.

📊 В статье есть отличные диаграммы, показывающие, как LLM взаимодействует с внешним миром, инструментами и данными. Всё складывается в единую картину:
Агент — это цепочка промтов и tool-вызовов, которые не имеют встроенной защиты.

💬 Отдельно поднимается вопрос этики и порядочности поставщиков инструментов и MCP-серверов.
И рекомендуют применять все обычные проверки безопасности.

Публикация официального реестра MCP — это шаг вперёд.
Но он пока никак не администрируется на предмет безопасности или уязвимостей.

⚙️ Что можно сделать, чтобы уменьшить риски?
🔜 Контейнеризировать окружения агентов (Docker или Apple Containers)
🔜 Изолировать задачи и инструменты
🔜 Делать итерации с подтверждением человеком
🔜 Защищать/скрывать доступы и токены
🔜 Использовать безопасные dev-контейнеры (Claude Dev Containers)

🧩 Вся экосистема движется к тому, чтобы LLM могла действовать самостоятельно.
Но важно понять, что пока человек остаётся самым надёжным “firewall” между ИИ и злоумышленником.
А применение подходов описанных в статье снимает львиную долю человеческого фактора.

P.S.:💡 Отдельный инсайт для меня — это Apple Containers: Linux контейнеры в macOS от Apple.
Надо будет посмотреть.

#L #AgenticAI #Security #LLM #PromptInjection #MCP #Containers #Claude #Apple #AI

👏

🤔🧵 Xcode 26 + Swift 6.3 — апдейт, который может реально ускорить разработку

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

💨 Сборка
В Swift 6.3 улучшили оптимизацию компилятора: кеширование, генерацию кода, специализацию дженериков.
По данным из бенчмарков, многомодульные проекты собираются быстрее — местами прирост достигает 2–3x при холодной сборке.
Apple в релиз-нотах Swift 6.3 тоже указывает на улучшения в оптимизации и снижении времени сборки.

⚙️ Async/await и рантайм
В статьях и тестах отмечают, что async/await стал работать ощутимо быстрее — оптимизировали actor-изоляцию и планировщик задач.
Те же бенчмарки показывают до 30–40% улучшения производительности и меньший расход памяти в асинхронных сценариях.
Похоже, Swift 6.3 действительно подчищает шероховатости concurrency.

🧠 Instruments и профилирование
Xcode 26 принёс апдейты и для диагностики:
🔗 WWDC 2025: Optimize CPU performance with Instruments
🔗 WWDC 2025: Optimize SwiftUI performance with Instruments

⚡️ Всё это — не революция, но важный шаг к тому, чтобы Swift и Xcode ощущались быстрее, надёжнее и понятнее (в том числе при работе с многопоточностью).

Пока сам не мерил, но судя по статьям и отзывам — апдейт действительно стоящий.

Ссылки:
🔗 Swift 6.3 Release Notes
🔗 Xcode 26 Release Notes
🔗 Swift 6.3 Performance Benchmarks (Medium)
🔗 Performance profiling в Swift 6.3

#L #Xcode26 #Swift #Instruments #asyncawait

👏

☺️🧪 Code Coverage — чтобы тесты реально помогали

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

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

Инструменты:
🖥 xctestplan — позволяют централизованно управлять конфигурациями и включать сбор покрытия без десятков схем.
🧑‍💻 xcrun xcov — базовый CLI-инструмент Apple для выгрузки покрытия (можно парсить .xccovreport и агрегировать по модулям).
👃 Slather — визуализирует отчёты via html, позволяет собрать cobertura.xml и интегрировать его с CI (для визуализации покрытия в том числе на MR-ах).

Как развивать подход:
- Формировать зоны по которым считается покрытие.
- Хранить и визуализировать динамику покрытия (Grafana / VictoriaMetrics / Prometheus).
- Следить за покрытием в MR — не допускать падения ниже порога.
- Разделять покрытие по фичам и модулям.
- Комбинировать метрики покрытия и сложности кода для приоритезации тестирования.

ИМХО: Coverage — это не про гонку за «100%»,
а про осознанный контроль качества и постоянную обратную связь для команды.

#L #metrics #coverage #xctestplan

👏

🎃 Полночь.
Пустой офис.
Монитор — единственный источник света.

💻 Xcode завис.
Слишком долго...

На экране появляется надпись:
Cleaning DerivedData…

Ты вздрагиваешь.
Кожа на затылке стынет.
Проект оживает — и будто сопротивляется тебе.

🌀 Indexing. Rebuilding. Re-indexing.
Симулятор падает.
Память исчезает быстрее, чем надежда.
8… 4… 2 ГБ…

Ты решаешь удалить DerivedData вручную.
Но закрываешь Finder — и она появляется снова.
Папка возрождается, как нечто живое.

🕯 Консоль мерцает:
“Preparing build environment…”
Шёпот за спиной.
Ты оборачиваешься — никого.

И тогда ты понимаешь:
в этом аду нет выхода.

В темноте офиса вспыхивает последнее сообщение:
🪦 Build failed.

#R

👏

💻 "жиза", это когда половина рабочих встреч со всей недели, сьехали на рабочую субботу. 😒

#L

👏

👍 🧠 “Specification-Driven Development” и размышления о будущем AI-разработки

Многие из нас, кто работает с AI-агентами, уже не раз задавались вопросами:

«Как структурировать свой knowledge base?»
«Как писать спецификацию и проектную документацию так, чтобы с ней мог работать ИИ?»

И вот отличная статья в блоге Martin Fowler, где разбирается подход Specification-Driven Development (SDD) — создание систем и агентов на основе детализированных спецификаций.
Автор показывает инструменты и практики, помогающие связать описания требований, память, итерации и код, формируя понятный процесс разработки с участием LLM.

Однако важно отметить — термин SDD пока не имеет строгого определения.
Он уже стал зонтичным, объединяя и RAG-сценарии, и агентную разработку, и AutoGen-подходы.
То есть комьюнити пока только нащупывает, что именно значит “разработка на основе спецификаций” и куда она эволюционирует.

Лично я считаю статью полезной прежде всего для расширения кругозора — особенно если вы размышляете над архитектурой ИИ-агентов, памятью и контекстом.
Но насколько далеко мы зайдём, и как будет выглядеть «SDD» через пару лет — пока вопрос открытый 🤷‍♂️

P.S. Особенно с учётом растущего интереса к самостоятельным и независимым AI-кодерам в корпоративных контурах.
На днях, накопал инструмент Continue.dev, который позволяет разворачивать полностью локального AI-кодера с собственной моделью — без зависимости от внешних API.
Пока просто на уровне изучения, может быть попробуем и получится поделиться опытом.

#L #AI #RAG #SDD

👏

👍 🧩 Про модуляризацию и границы между фичами
Чтение выходного дня натолкнуло на статью "Building Modular and Scalable iOS Apps".

Не сказать, что она очень подробная, но она поднимает важные темы:
- слоистость архитектуры,
- правила взаимодействия между модулями,
- DI и тестирование в контексте модульной структуры.

Я несколько лет назад писал цикл статей про модуляризацию — вот одна из них:
Там я подробнее разбирал вопросы, связанные с build critical path, графом зависимостей, подходом API/Impl, и тем, как всё это влияет на скорость сборки и масштабируемость архитектуры.

Интересно наблюдать, что тема модульной архитектуры всё ещё обсуждается (где-то даже очень базово).
И периодически появляются новые ракурсы размышлений (в комьюнити):
- развитие Tuist-а
- апдейты в Xcode
- интеграции с современными инструментами сборки и автоматизации.

#L #Arch #Modularity #apiimpl

👏

😒 ⏳Как ускорить сборку в 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-noscript-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

👏