👋😁 Привет!

Наткнулся на пост в канале 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

👏

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

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

У нас есть два решения:
🧩 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

👏