🐢 Привет! Мы — команда iOS-разработчиков, и этот канал — наш совместный дайджест о мобильной разработке.

У нас четверо авторов, и чтобы не запутаться, мы решили вдохновиться черепашками-ниндзя 🍕

😊 Леонардо (L) — про AI, процессы, менеджмент и инфраструктуру
🤔 Рафаэль (R) — про UI, дизайн-системы, SwiftUI и UIKit
😳 Донателло (D) — про культуру разработки, технические глубины и инфраструктуру
😁 Микеланджело (M) — про архитектуру, Swift и кодогенерацию

🎯 Здесь будут:
— дайджесты статей и новостей iOS-разработки
— кейсы из нашей практики
— разборы инструментов и подходов
— немного философии о командной работе и разработке

Подписывайтесь, впереди много интересного. 🚀

#iOS #Swift #MobileDev #TeamWork

👏

😁 Хай от Леонардо 👋
Пришло время первого поста от нашей команды 🙈
Заинтересовала статья по построению open-source инструмента для генерации Swift-кода на основе DSL используя AI.
Автор статьи показывает крутой подход: он не пытается в тупую использовать ИИ в один шаг, а изолированно использует AI-инструменты под конкретные цели — например, Cursor для пошаговой генерации компонентов, Claude Code — для масштабных архитектурных решений.
В основе API — DSL-подход с resultBuilder’ами, что делает код генерации похожим на “SwiftUI” только для codegen-а.
Также AI при этом активно задействован в генерации тестов.
Решение выглядит очень зрелым: сочетание продуманного API + AI как помощника, а не как замена.
Верю, что у такого подхода — будущее в инструментах разработки, особенно если сохранять контроль качества.
🔗 Читать статью

#L #AI #iOS #resultBuilder #DSL #SyntaxKit

👏

😊 🍕 Всем привет и хорошего вечера от Leo:
Наткнулся на резюме по свежему отчёту DORA. Натолкнуло на размышления. Хочу поделиться:

Вывод из статьи: искусственный интеллект уже не эксперимент — 90% разработчиков используют AI в работе, и большинство (80%+) отмечают рост продуктивности.
Но вместе с тем возникает “trust paradox”: около 30% респондентов доверяют сгенерированному AI-коду “слабо” или “совсем не доверяют”.

Ключевой акцент в отчёте — не просто “использует ли компания AI”, а готова ли она обеспечить необходимую инфраструктуру и процессы.

Отчёт выделяет семь практик (capabilities), которые отличают успешные команды в использовании AI (я бы поделил их на три группы):

Работа с AI инфраструктурой:
- Clear and communicated AI stance — четкая позиция по применению AI и её прозрачность для команды.
- Healthy data ecosystems — зрелая работа с данными, их качество, полнота и доступность;
- AI-accessible internal data — создание условий, при которых данные можно использовать для AI-инструментов без барьеров;

Практики доставки ценности до пользователя:
- Strong version control practices — зрелые практики контроля версий, обеспечивающие прозрачность и управляемость изменений;
- Working in small batches — культура частых и небольших изменений;
- User-centric focus — ориентация на конечного пользователя и его опыт;

Развитие Platform Engineering:
- Quality internal platforms — Платформенная инженерия / наличие и качество внутренних платформенных команд.

🎯 Ну ложится же на реальность, правда?
Главное — что AI воспринимается как усилитель, а не замена: если процессы слабые, AI просто ускоряет “болезнь”.
Но когда компания нацелена на стратегическое развитие AI, создаются внутренние платформы и налажена культура процессов и доставки — AI даёт реальные плюсы.

🙈 Не постесняюсь дать call to action: возможно, вам как команде, с данной фактурой получится показать бизнесу (если он еще этого не осознал), что сфокусировавшись на этих world-wide best-практиках при построении процессов, компания может завладеть конкурентным преимуществом.

🔗 Читать статью

#L #AI #DORA #TeamWork #PlatformTeam

👏

😅 Всем привет, на связи Микеланджело.

В этом канале я рассказываю про архитектуру, Swift и кодогенерацию ⚙️

Мне на глаза попалась статья от CEO Tuist «Why Large Swift Projects Hit a Wall». Поскольку наша команда очень широко использует этот инструмент - пройти мимо было сложно, тут есть о чем поговорить!

🛠️В силу особенностей iOS платформы часто «узким горлышком» становится инструментарий. Есть проблемы, с которыми сталкиваются крупные компании:

Модуляризация

 - С ростом кодовой базы вы неизбежно придете к концепции разделения границ между компонентами и их повторного использования, а стандартный инструментарий Xcode очень беден и неудобен для ее внедрения. Часто люди ограничиваются внедрением SPM-пакетов, что не решает проблему 🥶

Время сборки

 - С ростом проекта время сборки проекта как на рабочих машинках и на CI стремительно увеличивается, добавляя инфраструктуры расходы, а темпы роста проекта кратно превышают темпы роста производительности новых чипов. Проблема с временем сборки тесно переплетается с модуляризацией и ей будет посвящена масса материала на канале 📚

Время тестирования

 - Чем больше тестов у вас написано, тем больше времени занимает их прогон на CI. Если инфраструктура не предоставляет возможности распараллеливания среды (например, шардинг тестов), то время сборок на CI будет стремительно увеличиваться 📈

Аналитика

 - Бизнес очень любит оценивать и принимать решения на основе какой-нибудь метрики. Потому, если недостаточно собирать аналитику вашей инфраструктуры и проблем с ней, то бизнесу будет непонятно зачем на это уделять человеко-часы и зачем тратить бюджет на улучшение инфраструктуры 😐

Derived Data

 - Эта надоедливая директория допускает неявный импорт зависимостей, оставшихся после предыдущей сборки. Справедливости ради Apple знает о проблеме и использует CAS (Content Addressable Store), что, тем не менее, не исключает проблему в модульном проекте 😤

Как итог: проблем масштабирования iOS проекта предостаточно и пускать их на самотек чревато огромными неприятностями как для разработчиков, так и для бизнеса. В цикле статей от 🟠 Микеланджело 🟠 мы будем разбирать такие проблемы и улучшать инженерную культуру 🤝

Думайте критически, подходите к проекту осознанно и не отпускайте все на автопилот 💫

📎 Читать статью

#M #Tuist #CI #iOS #TeamWork #PlatformTea

👏

🌃 🤔 Мысли на ночь:

«Иногда ваш лучший мобильный разработчик — тот, кто делает задачи медленно».
Да, звучит странно, но “быстро” часто — это пропущенные детали, технический долг, архитектурный хаос и множество багов на этапе доработок.

Вниманию менеджеров: важны не просто дедлайны, а стабильность, качество и мышление на перспективу.
Разработчик, который тратит время на дизайн, тесты и надёжную архитектуру, — в долгой игре приносит больше, даже если сейчас “выглядит как медлительный”.

В зрелом процессе, метрики должны смотреть не только на скорость тикетов, а на средне- и долгосрочные показатели:
• поддерживаемость кода
• масштабируемость
• сложность
• время на модификации
• частота переписываний / рефакторинга

Пусть метрики “закрытых тикетов” не затмевают метрики качества кода в долгую.

Это простая мысль — но не всем очевидная. 🧠
Спасибо за внимание, ваш Лео. 😏

📎 Читать статью

#L #Management #TeamWork

👏

👋😁 Привет!

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

И что-то захотелсоь вспомнить и освежить работу: opaque types, existential types, type erasure, generics.
- как они соотносятся между собой;
- и где какую абстракцию применять.

Нагуглил, кажется, не плохую статью — Swift Type Abstraction: Generics, Opaque Types, Any, and Type Erasure Explained.

Интересно в ней то, что автор не просто описывает синтаксис, а объясняет, когда и зачем использовать каждый механизм:
- Generics — максимально производительный вариант (всё известно на этапе компиляции, вызывается напрямую, без динамики).
- Opaque types (some) — позволяют скрывать конкретный тип, но при этом сохраняет статическую диспетчеризацию и производительность.
- Existential types (any) — гибче, чем opaque, дают возможность работать с разными типами через единый интерфейс (в том числе на коллекциях), но требуют динамической диспетчеризации (runtime cost).
- Type erasure — паттерн, когда мы сами явно создаём обёртку, скрывающую конкретный тип за протоколом, чтобы преодолеть ограничения с associatedtype и использовать протокол как тип.

💡 От себя добавлю: именно any и type erasure помогают обойти ограничения протоколов с associatedtype — дают возможность использовать такие протоколы в коллекциях, возвращаемых значениях или свойствах (работать с такими протоколами как типами, а не с констрейнтами).

💡 Важно помнить: дженерики действительно быстры на рантайме, но за счёт компиляции под каждый конкретный тип увеличивают размер бинаря (потому что компилятор специализирует код под каждый тип). Поэтому баланс между производительностью и универсальностью здесь — ключевой.

P.S.: Думаю, стоит продолжить начитку в этом направлении — темы, которые логично пойдут следом:
- Как компилятор специализирует generics — Monomorphization.
- Как устроены witness tables и как происходит dispatch через них.
- Разные паттерны type erasure в Swift и в Foundation.
- Что такое primary associated types, как они работают и как влияют на абстракции.

#L #Swift #ExistentialTypes #Generics #TypeErasure

👏

🤔 🧭 Метрики — компас зрелого проекта

Наткнулся на статью от Bitrise, где описываются базовые метрики мобильного CI/CD: время сборки, стабильность пайплайнов, покрытие тестами и прочие технические сигналы.

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

Важно делать продукт производительным и масштабируемым — чтобы он прожил не один релизный цикл, а годы.
А чтобы корректно ставить цели, отслеживать прогресс и переосмыслять приоритеты, нужны не только UI/UX и продуктовые метрики.
Для больших команд и проектов любые OKR и техдолговые инициативы должны базироваться на измеримых инженерных данных.

📊 Метрики, на которые стоит обратить внимание:

- CI / Pipeline: build success rate, flaky tests, среднее время сборки, время прогона тестов, время ожидания пайплайнов в очереди, утилизация агентов.
- Репозиторий: размер проекта, количество модулей, зависимостей, скорость клонов/чекаутов, количество технического долга.
- DX: скорость компиляции, скорость прогрева кеша, время индексации Xcode, время работы кодгена и линтинга.
- Качество: crash-free rate, test coverage, impact analysis.
- Перфоманс: app size, startup time.

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

Команда, которая видит данные — начинает видеть направление.

P.S.: Отдельно еще стоит уделять внимание производственным метрикам и также перекладывать их на технические об этом по-рефлексируем в будущих постах.

📎 Читать статью

#L #TeamWork #Metrics #DX #CI

👏

🤔 Just Talk To It — the no-bs Way of Agentic Engineering от Питера Стайнбергера.
Автор делится опытом, как уже почти весь код — от Chrome-расширений до мобильных приложений — пишет через агентов.
Не как эксперимент, а как рабочий инструмент инженерного DX. ⚙️

Основной инструмент — Codex CLI.
При необходимости запускается несколько терминалов, каждый агент работает в своей зоне, делает atomic commits, и всё — в одном дереве проекта.
Описывает Agents.md — “вики” с инструкциями, шаблонами, предпочтениями по паттернам и туллингу, чтобы AI понимал контекст проекта. 📘

🎯 Ключевые принципы, о которых он пишет:
- Blast radius — перед изменением всегда прикидывает, сколько файлов заденет; если задача “растёт”, — можно остановиться и переосмыслить. 💣
- Work tree — экспериментировал с worktrees и ветками, но отказался — управление несколькими dev-серверами оказалось дороже, чем польза. 🌳
- Multiple agents / subagents — большая задача может делиться на агентов, но он предпочитает просто “открывать больше окон”, чтобы всё видеть и контролировать. 🔍
- RAG vs “just talk to it” — критикует RAG-подход как “charade”: он добавляет инфраструктурный шум и мало что реально дает при современных LLM. 🧩
- Критика MCP — “маркетинговые фичи” и “налог на контекст”. Предпочитает простые CLI — меньше слоёв, меньше токенов, больше фокуса. 💬

👍 Особенно круто — как он использует агентов для рефакторинга React-кода:
- 🧹 удаление дубликатов (jscpd),
- 🪓 чистка мёртвого кода (knip),
- 🧩 линтинг и плагины React Compiler,
- 🗂 реструктуризация файлов,
- ⚡️ переписывание медленных тестов.
И всё это — через агентов, а не вручную.


🧠 IMHO:
- Использование ИИ — это не “взять модель и ждать магии”, а создать среду, правила и ограничения, чтобы агенты не ломали систему.
- Документ Agents.md — по сути “инструкция жизни” для ИИ, как для нового разработчика в проекте.
- Отказ от RAG и MCP логичен: если модель уже понимает контекст, то лишние прослойки только мешают.
- Рефакторинг через агентов — не игрушка, а реальный способ поддерживать кодовую базу в живом, чистом состоянии.


💡 Финальная мысль
Развитие в использовании ИИ — это не про теорию и промтхакинг.
Это про практику, наблюдение и итерации.
Мудрость приходит с опытом — через ошибки и эксперименты.
🧭 Насмотренность и системное мышление позволяют принимать осознанные решения,
а не слепо гнаться за трендами. 🚀

#L #AI #MCP #RAG

👏

😊 Едва успели потрогать новый XCode или уже давно подготовились к грядущим изменениям?

Любимый проект непрерывно модуляризируется, количество обособленных модулей перевалило за 60 и это позволяет обновлять кодовую базу итерационно. Большинство модулей поддерживает Swift 5.9, но кто-то уже успел потрогать Swift 6.0 и нервно улыбнуться, предвкушая часы переписывания кода.

Коммьюнити разделилось на 2 лагеря:
- тех, кто бросился в омут исправления ярких красных ошибок;
- тех, кто решил с этим не торопиться.

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

Для многих разработчиков одной из самых долгожданных фичей XCode 26 и Swift 6.2 стала возможность включения Default Actor Isolation.

Эти размышления навеяны статьей Mastering Swift 6.2 Concurrency: A Complete Tutorial, в которой автор автор обозревает основы Swift Concurrency и фокусируется на изменениях в Swift 6.2. Сухая теория разбавлена насущными проблемами и практическими рекоммендациями. Есть над чем подумать вне зависимости от того, на какой стадии принятия вы сейчас находитесь.

Вот ключевые моменты, которые стоит держать в голове:

- default actor isolation = MainActor по умолчанию: типы/методы изолируются на main, что снижает гонки данных.

- async/await = точки приостановки: await — место, где выполнение может переключиться; без переключающих API код может остаться в том же потоке.

- sending = эволюция @Sendable: новые правила отправки/захвата для безопасного передачи данных между задачами.

- @concurrent = точка входа в многопоточку: явно помечает методы, которые могут выполняться параллельно (параллелизм — по требованию).

Практика:
Держите лёгкий UI-код на main; тяжёлые CPU/IO задачи явно отправляйте в фон (например, Task.detached, фоновые очереди).

Осторожность:
Не злоупотребляйте @unchecked Sendable и распараллеливайте только когда нужно.

Итог:
Swift 6.2 делает concurrency безопаснее по-умолчанию — явные аннотации (sending, @concurrent) важны для намерений разработчика.

📎 Читать статью

#D #Swift #Concurrency #Async

👏

🤔 🔍 AI Agents Comparison from iOS Developer Perspective

Human brain is still the most amazing machine that ever existed - let's not forget that!

Автор делает честный бенчмарк разных AI-агентов (Copilot, Cursor, Claude Code и др.) для одной баг-ситуации в iOS-проекте.
Он оценивает скорость, аккуратность, регрессии и удобство работы в IDE или через CLI — и делает выводы, какой агент реально помогает, а какой нет.

💡 Итог: GitHub Copilot — худший результат, а лучший опыт показали Cursor / Claude Code / Gemini CLI.

Оценивая конкретно свою задачу, автор подчеркивает, что даже быстрые агенты иногда жертвуют качеством.
Но, и при этом, даже худший опыт с Copilot экономит время "указывая верный путь". 🛤️

#L #AI

👏

🤔 🧠 Прочитал статью «Первый шаг к кибернетическому тимлиду: автоматическое ревью кода на основе LLM» — прям в резонанс.
В духе того, что мы сейчас делаем.

Мы тоже строим своего AI-агента для код-ревью и модуль-ассессмента (анализа технического долга).
Пока наш путь только начинается, но уже видно:
🤖 агент реально помогает — находит изъяны в коде и документации, которые человек мог пропустить.

Неожиданный плюс — растёт качество документации.
Когда стараешься “объяснить модели” структуру проекта, правила, контракты —
документация становится понятной любому члену команды, шире и продуктивнее.

🧩 Технически мы тоже используем Ollama,
но не через n8n — а через свой микросервис и бота.
Так у нас больше гибкости: контроль промптов, истории, интеграции в CI/CD — всё под нас.

⚡️ Повторю вывод предыдущей статьи, применимо к текущей: агент — не замена человеку.
Он становится осознанным помощником, который усиливает команду, улучшает код и культуру документации.

🔗 Читать статью

#L #AI #CodeReview #ModuleAssessment

👏

😳 ⚠️ Когда не стоит делегировать LLM/агентам кодовые задачи

Прочитал статью When Not to Delegate to LLM — хорошая напоминалка, что AI не универсален.

Автор пытался рефакторить Storyboard (XML-файлы проекта iOS) через модель, но получил столько ошибок с путями/ссылками/конфигурациями Xcode, что сделать задачу оказалось быстрее и проще вручную.

🧐Автор выделяет три случая, где LLM часто ошибается:
- tight file formats — файлы с внешними зависимостями и “невидимыми” связями (Storyboard / Xcode project)
- toolchain nuance — нюансы сборки/конфигураций CI/Xcode, которые модель не знает
- tiny chores — мелкие задачи, которые быстрее сделать вручную, чем вести цикл «prompt → правка → проверка → баг»

✅ Автор предлагает чек-лист перед делегированием:
1. Зависит ли задача от скрытых правил / конфигурации?
2. Могу ли я сделать это за < 10 минут сам?
3. Потрачу ли больше времени на правку вывода модели, чем сделаю вручную?
Если да — лучше не делегировать.

💡 Мысли вслух:
- Согласен с тем, что LLM хорош для boilerplate, генерации тестов, шаблонов — но не для всего. Особенно опасны задачи, у которых «много специфики».
- Часто человек знает нюансы CI / сборки / настройку Xcode, которые не очевидны модели — и правка её вывода может занять больше времени, чем ты потратишь сам.
- Соглашусь с чек-листом — кажется хорошей практикой для команды: перед тем как “дать агенту”, подумать: “Это мелочь? Слишком специфично? Мой откат дороже, чем ручной фикс?”
- Но есть нюанс: если правильно прокачать инфраструктуру — например: документировать правила (как в недавнем посте), покрывать примерами, иметь тесты/валидаторы после действий агента — риск уменьшается и автоматизация становится надёжнее.

🔗 Статья

#L #AI #LLM

👏

🤔 «How to Build AI Agents with Local LLMs and MCP Architectures» от Sujithra Kathiravan:

🧠 Что в статье:
Она даёт базовый минимум терминологии для тех, кто хочет строить агентов:
- Local LLMs — зачем запускать модели локально (privacy, latency и кастомизация) 
- MCP-архитектуры (Multiple Context Programming) как способ управлять контекстом разных “задач” / “сценариев” внутри агента
Также упоминаются:
- использование инструментов
- функций (tool use / function calling)
- decision-making framework внутри агента
- управление состоянием (memory / context switching)

➕ Плюсы использования подходов:
- локальные LLM дают контроль над данными, снижение задержек, приватность и гибкость.
- MCP даёт структуру контекста / памяти / модулей, полезную когда агент решает сложные задачи. 

🔍 Что можно применить — базовое применение каждого элемента
- Local LLM: запустить модель офлайн / внутри инфраструктуры компании, не зависеть от внешнего API
- MCP-архитектура: разбить агента на модули / контексты (например: код-ревью / тест-ассессмент / документация), переключаться между ними
- Tool calling / функции: агент может “вызывать” вспомогательные функции — запуск линтера, анализ метрик, генерация тестов и т.д.
- Decision-making framework: логика, по которой агент выбирает, какой модуль / функцию запустить при данной задаче (на основе контекста / приоритетов)

💡 Мои мысли:
Мне кажется, статья отлично задаёт отправную точку — термины + задачи, которые нужно знать до старта. Но жаль — нет глубокого разбора, как именно строить MCP-сервер, как оформить functions / tools, как организовать decision logic или memory management.

Мы могли бы в будущих постах поднять темы:
- как строить свой MCP-сервер
- как проектировать tools / functions внутри агента,
- как проектировать decision logic
- как управлять памятью / контекстом агента

📎 Статья

#L #LLM #AI #MCP

👏

😁 Всем привет 👋
Хочу рассказать про крутой инструмент - Reaper и поделиться опытом его интеграции 🚀

🤔 В чём проблема?

Большой проект может обрастать тоннами неиспользуемого кода: устаревшие фичи, классы после рефакторинга, забытые методы. Как итог:

🐌 Медленная сборка: компилятор тратит силы впустую
🥵 Сложный рефакторинг: страшно удалять, «а вдруг где-то используется?»
😵‍💫 Раздутый размер приложения

⚔️ Reaper vs. Статический анализ (Periphery)

Статические анализаторы вроде Periphery — это отлично, но есть нюансы:

🐢 Долгие прогоны на CI, которые сложно встроить в каждый PR
🫣 Слепые зоны: бессильны против кода, управляемого извне (например, Remote Config)

Reaper подходит к вопросу иначе - это runtime-анализ. Он видит, что реально используется в работе приложения 🕵️

🔍 Что под капотом Reaper?

Reaper работает на уровне Mach-O файлов и рантайма:

- Для Obj-C: отслеживает момент инициализации объекта в рантайме (бит RW_INITIALIZED)
- Для Swift: всё намного сложнее. Вкратце - анализирует секцию __swift5_types, проверяет kind объекта, отсутствие resilient superclass, отсутсвие generic и тд. Полную логику проверки мы рассмотрим отдельно в будущем 💫

🛠 Как внедрить?

Интеграция состоит из двух частей:

🖥️ Бекенд:

Есть референсный пример от разработчиков, от которого можно отталкиваться, а лучше написать полностью свое решение.

Базовый функционал:
- Ручка для агрегации известных типов 📋
- Ручка для отправки отчёта с устройств 📨
- Дашборд со статистикой 📊

📱 Мобилка:

1️⃣ Один раз на CI запускаете скрипт, который выцепляет все отслеживаемые объекты в вашем коде (делается на этапе сборки 1 раз на релиз, но можно придумать и иную политику)

2️⃣ Интегрируем Reaper SDK (есть в SPM/CocoaPods) и инициализируем при запуске приложения

3️⃣ При уходе приложения в background отправляем на ваш сервер «отчёт» со списком использованных сущностей за эту сессию

💎 Вывод

Reaper — это не замена статическому анализу, а мощное дополнение к нему. Он даёт данные с реальных устройств ваших пользователей, раскрывая слепые зоны статического анализа ✨

У инструмента есть потенциал, мы продолжим его обкатывать и поделимся результатом ⚙️

📎 Ссылки:
➡️ Репозиторий Reaper
➡️ Пример Backend
➡️ Репозиторий Periphery

#M #iOS #TeamWork #Reaper #Periphery

👏

😏 Всем привет! 🍕
Наконец-то решился на свой первый пост.
Буду писать от имени Рафаэля постараюсь без воды.

Прочитал статью про то, как правильно делить вьюшки в SwiftUI. Типа — делай красиво, переиспользуемо, модульно и тд.
Но по факту многие такие советы могут только навредить. Вот у тебя есть экран — как большой конструктор, но инструкции к нему нет. Я как-то пробовал собирать лего без инструкции, получилось так себе.

Основные тезисы из статьи:

✅ Делить по смыслу, а не по желанию.
Если кусок UI живёт сам по себе — вынеси. Если без контекста он бесполезен — лучше не трогать. Нам не нужны 15-строчные «компоненты ради компонентов».

🔥 ViewModifier — норм тема.
Оформил стиль — забыл. .cardStyle(), .primaryButton() — кайф, читается легко и понятно.

⚠️ Осторожно с магией.
.sectionHeader("Articles") выглядит круто, пока не тратишь полчаса, чтобы вспомнить, где это вообще определено. Красота — это не магия. Красота — это когда открыл код и сразу понял, что к чему.

🧠 Итог:
Статья норм — содержательно, с хорошими примерами.
Но как всегда, не всё, что на первый взгляд выглядит хорошо, реально удобно в проде.

🔗 Статья

#R #SwiftUI

👏

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

👏