🤫 Debug-only SDK в iOS

Частая задача — подключить SDK только в Debug, но не тянуть его в Release:
дебажные тулзы вроде Flex, sandbox-SDK и прочее.
И вот как разные инструменты с этим справляются 👇

🍫 CocoaPods — старичок, который решает задачу идеально:

pod 'SomeSDK', :configurations => ['Debug']

И всё — магия происходит автоматически.

CocoaPods:
• генерирует разные .xcconfig под Debug и Release
• добавляет OTHER_LDFLAGS, FRAMEWORK_SEARCH_PATHS только в Debug
Это правильное поведение на уровне линковки.
И работает уже лет 10. Пруфы со времён 0.34.

🧰 Tuist — “сделай сам”:
Tuist ближе к Xcode, но отдельной поддержки Debug-only зависимостей нет. Официальный issue.
Что приходится делать:
• вручную писать xcconfig или BuildSettings и менять OTHER_LDFLAGS по конфигурации
или
• использовать ENV-ы при tuist generate
и
• создавать отдельные targets под Debug/Release
То есть руками воспроизводить то, что CocoaPods делает автоматически.

📦 Swift Package Manager — примерно как Tuist:
Можно исключать код через макросы #if DEBUG.
Вижу что можно колдовать с LinkerSetting-ами руками и использовать unsafeFlags с condition.
Но, что-то исследование через гугление, не дает статей по использованию.
Интересно почему? Все еще так мало адептов?
Сами мы spm в enterprise не используем, только периодически присматриваемся, и постоянно что-то отталкивает.
Поэтому буду рад, если скорректируете.

#L #Cocoapods #Tuist #SPM

👏

😏 Полезные SwiftUI-компоненты.
На медиуме довольно много статей про «скрытые SwiftUI компоненты». Я как раз прочитал несколько, где автор рассказывает про полезные компоненты, о которых многие не знают.

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

⏱️ TimelineView – обновления по расписанию
Этот компонент автоматически перерисовывает View каждую секунду, минуту или по вашему интервалу.

Где нужен:
- часы
- таймеры и обратные отсчёты
- виджеты
- данные, которые должны обновляться «в фоне»

Почему лучше старых решений:
❌ Timer → утечки, ручной поток, лишняя логика
❌ Combine.Timer → громоздко
✔️ TimelineView → нативно, оптимизировано, просто

Плюс еще одно важное преимущество:
В режиме .animation TimelineView ведёт себя похоже на CADisplayLink: обновления идут в такт рендеринга, но без ручного управления runloop’ом и без риска забыть invalidate().
А в режиме .periodic система сама оптимизирует частоту, что экономит энергию.

Пример:

TimelineView(.periodic(from: .now, by: 1)) { context in
    Text(Date.now.formatted())
}

🎛 PhaseAnimator – сложные анимации без таймеров
PhaseAnimator позволяет задать список значений (фаз), а SwiftUI сам плавно будет бегать между ними.

Когда использовать:
- shimmer и skeleton
- пульсирующие элементы
- бесконечные анимации

Почему лучше старых подходов:
❌ раньше: onAppear + стейты + таймеры
✔️ сейчас: декларативно, чисто, предсказуемо

Пример:

PhaseAnimator([1, 1.3, 1]) { phase in
    Circle().scaleEffect(phase)
}

🎨 Canvas – когда нужен кастомный рендеринг
Если стандартные формы SwiftUI уже не помогают – Canvas позволяет рисовать что угодно, как в CoreGraphics, но нативно в SwiftUI.

Где полезно:
- графики
- диаграммы
- сложные анимации
- частицы
- декоративные фоны

Почему лучше старых решений:
❌ UIViewRepresentable + CoreGraphics → сложно, неудобно
✔️ Canvas → рисуешь прямо в SwiftUI

Пример:

Canvas { context, size in
    context.fill(
        Path(ellipseIn: CGRect(origin: .zero, size: size)),
        with: .color(.orange)
    )
}
.frame(width: 120, height: 120)

🍕 Итог:

Три компонента закрывают три разные задачи:

- TimelineView – всё, что зависит от времени
- PhaseAnimator – анимации с логикой фаз
- Canvas – кастомная графика без UIView

Это инструменты, которые позволяют писать SwiftUI-код быстрее и чище – и избавляют от костылей, к которым мы привыкли.

#R #SwiftUI

👏

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

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

#L #Tuist #BuildCache #ImpactAnalysis

👏

🤫 📢 Новый взгляд на обмен данными в Swift — протокол Transferable

Как сделать ваши кастомные типы пригодными для обмена и передачи между приложениями или компонентами системы?
Если тип соответствует Transferable и описывает, как его сериализовать/десериализовать — его можно «таскать» через drag-and-drop, copy/paste, использовать с ShareLink, PasteButton и др.

#L #Swift #Transferable

👏

😜 Сахар VS динамика
…или почему DynamicMemberLookup плавится под взглядом objc_msgSend

Может показаться, что Swift стремится быть «тоже динамичным».
Добавили @dynamicMemberLookup, добавил @dynamicCallable — ну, почти Python! Почти ObjC! Почти магия!

Но потом на сцену выходит Objective-C, закатывает рукава и тихо шепчет:

«Малыш, это не динамика. Это лишь синтаксический сахар.»

Потому что где Swift подменяет свойства через субскрипты,
Objective-C через objc_msgSend прогуливается прямо по таблицам методов, меняет реализации на лету, отлавливает несуществующие селекторы, форвардит вызовы куда захочет и в целом живёт по принципу:

«Если я хочу сделать это — я сделаю.»

В Swift ты получаешь аккуратную коробочку с инструкциями.
В Objective-C — набор динамита и спички.

И да, об этом всём я хочу написать в длинном посте на будущей неделе:
- про рантайм
- про isa
- про swizzling
- про Mirror
- про Swift runtime metadata
и почему у одного языка динамика настоящая, а у другого — сладкая.

Кстати, вопрос: какого формата посты больше нравятся? короткие-новостные? или детальные разборы?
Как в целом используете тг-каналы? Следить за новостями не погружаясь? Или каждо-дневное чтиво?
Буду рад, если дадите ОС.

Всем хороших выходных и отличного вечера пятницы. 😁

#L #objc #runtime #swift #dynamicMemberLookup #dynamicCallable

👏

🤫 📚 GraphRAG - как LLM + графовая БД = осмысленный интеллект

🔎 Что такое GraphRAG

GraphRAG - это RAG-подход, но с графовой базой знаний под капотом: вместо простого текст-поиска (векторов) мы храним сущности и их связи в графе, так, чтобы отношения между данными были явно выражены.

Это полезно, когда важно не просто найти похожие куски текста, а правильно обрабатывать взаимосвязи: например, «какие врачи делали какие процедуры пациентам в каких клиниках». Такие много-звенные запросы редко нормально обрабатываются через обычный RAG.

🚀 Как это работает - на примере из статьи

1. Пользователь задаёт вопрос (естественным языком)
2. LLM анализирует вопрос, «понимает», какие сущности и связи нужны - что именно ищем (фильтр, категории, сущности).
В демо LLM разбирает, кого/что спрашивают (фильм, актёр, жанр и т.п.).
3. По результатам анализа LLM, backend формирует запрос к графовой БД, подставляя отношения/сущности/фильтры.
4. GraphDB возвращает строго структурированные данные - сущности + связи, удовлетворяющие запросу.
5. Затем LLM дополняет исходный запрос найденной информацией, и генерирует ответ на естественном языке, опираясь на факты из графа.

Связность и точность:
GraphRAG хранит не просто куски текста, а связи между сущностями - это даёт возможность отвечать на сложные вопросы, включающие отношения, фильтры, и многозвенные зависимости.

Меньше галлюцинаций:
Так как контекст - это не распылённые текстовые фрагменты, а проверенные факты и связи; LLM привязан к структуре, не «вымысливает» из воздуха.

Масштабируемость и гибкость:
Можно совмещать граф + векторную бд.
GraphRAG не обязательно заменяет RAG, но дополняет его, давая лучший grounding при необходимости сложных запросов.

#L #LLM #RAG #GraphRAG

👏

😃 Tuist снова завозит магию.

Вышла статья: “Teaching AI to read Xcode builds” - и ребята опенсорсят fork Swift Build Service под названием argus.

Это команднй интерфейс для AI-агентов, который позволяет разбирать, понимать и оптимизировать Xcode-сборки.

Как всегда, Tuist невероятно понятно объясняет как работает pipeline сборки в Xcode.

Инструменты которые освещаются в статье:
- сам xcodebuild
- swift-build
- украшатель логов xcbeautify
- xcsift позволяющий получить лог в удобном формате для AI-анализа
- и TOON - оптимизированный JSON
- XCBLoggingBuildService — надстройка над XCBBuildService для перехвата событий
- и испольщуемой эплом MessagePack - еще один вариант оптимизировать JSON
- xclogparser

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

То есть они по сути берут весь «чёрный ящик» Xcode-сборки, вскрывают его, упаковывают в структурированные данные и дают агентам возможность понимать, что происходит во время билда.

С учётом того, что у Tuist уже есть Build Insights и Test Insights, которые сами по себе поднимают наблюдаемость на новый уровень — возможность интегрироваться прямо в процесс сборки + дать это агентам на анализ — выглядит как next level.

Мое почтение. 🤓

#L #Tuist #AI

👏

🤔 Вспомнился ещё полезный материал:
«Code Optimization for Swift and Objective-C»

Он помогает чётко разделить роли инструментов:
Компиляторы: swiftc, clang — превращают код в машинный.
Билд-системы: xcodebuild и swift build — это оркестраторы, которые решают что, в каком порядке и с какими флагами компилировать.

#L #swiftc #clang #xcodebuild #swiftbuild

👏

🤫 Секреты на клиенте: как снизить вероятность утечки с нуля до почти нуля

Мобильное приложение всегда оказывается на устройстве пользователя — а значит, потенциально доступ к нему может быть и у злоумышленника. Это значительно повышает требования к безопасности выпускаемых продуктов, поскольку в коде приложений неизбежно содержатся конфиденциальные данные, которые используются разработчиками. Соответственно, обязательным условием становится защита секретов на клиенте от утечек.

В статье, постарались рассказать:
🔘где эти секреты хранятся;
🔘как находятся;
🔘почему их важно скрывать;
🔘как выстроить надежную защиту с учетом потенциальных угроз.

Материал подготовлен по мотивам доклада на Podlodka iOS Crew, посмотреть можно здесь

#L #CS #encryption #obfuscation

👏

🤓 📣 Meta переманила главного дизайнера Apple!

Alan Dye - человек, представивший Liquid Glass на WWDC 2025 — уходит из Apple и переходит к Марку Цукербергу.
В Meta он займётся дизайном ИИ-гаджетов.
В Apple его заменит ветеран компании Steve Lemay.

#L #News

👏

😄 Долгий путь Concurrency в Swift: Structured, Strict, Approachable

🔹Swift 4.0
В 2017 году был опубликован Swift Concurrency Manifesto. Это фундаментальный документ от Chris Lattner, в котором описано видение и архитектура будущей конкурентности в Swift. Именно в нем заложена база для всего, что мы сегодня называем Swift Concurrency, включая actors, async/await, structured concurrency, Sendable и strict concurrency.

🔹Swift 5.5
В 2021 году были добавлены ключевые строительные блоки — async/await, Task/TaskGroup, actor и базовые правила про Sendable/изоляцию. Эти элементы создали основу структурированного параллелизма, на которую позднее были надстроены более жёсткие проверки безопасности конкурентности. Apple Developer

🔹Swift 6.0
В 2024 году было оформлено само понятие и более строгое поведение Strict Concurrency (активная работа и переключение к более строгим проверкам в Swift 6 и связанных proposal'ах/обсуждениях). Apple даёт рекомендации по adopting strict concurrency для Swift 6 — то есть базу заложили в 5.5, а строгие проверки стали сопутствующей эволюцией в следующих версиях. Apple Developer

🔹Swift 6.2
В 2025 году смещается фокус на удобство и Approachable Concurrency. Это попытка сделать переход на async/await и строгую модель акторов более мягким и предсказуемым.

Подробнее про Approachable Concurrency

Approachable Concurrency это не просто концепт, это набор новых/изменённых языковых фич и флагов в Xcode/Swift, призванных сделать переход на async/await и строгую модель конкурентности менее болезненным.

Это про progressive disclosure: по умолчанию код остаётся ближе к однопоточному, а более строгие ограничения появляются только когда вы сознательно вводите параллельность.

Какие фичи включаются

В swiftSettings можно активировать новые поведения компилятора:

🔹DisableOutwardActorInference
Отключает «растекание» глобальных акторов наружу. Раньше Swift мог автоматически навязать, например, @MainActor всему типу из-за одного property wrapper. Теперь это нужно указывать явно. Меньше сюрпризов и скрытой изоляции.

🔹GlobalActorIsolatedTypesUsability
Упрощает взаимодействие с типами, изолированными глобальным актором. Компилятор становится менее строгим в местах, где раньше требовал лишних @Sendable или блокировал вызовы. Код становится чище, а изоляция более предсказуемой.

🔹InferIsolatedConformances
Позволяет Swift автоматически понимать, что реализация протокола тоже «изолирована» актором. Например, если ваш класс @MainActor, то его conformances больше не нужно вручную помечать актором и компилятор корректно справится сам.

🔹InferSendableFromCaptures
Компилятор начинает автоматически выводить @Sendable для функций и замыканий, если это безопасно. Меньше ручных пометок, меньше ошибок вида «closure is not Sendable», меньше boilerplate.

🔹NonisolatedNonsendingByDefault
Главное и потенциально ломающее изменение. Неизолированные async-функции больше не гарантируют выполнение на глобальном executor, они исполняются на акторе вызывающего. Если нужна реальная параллельность, функцию надо явно помечать @concurrent.

Почему это важно

Если просто включить всё в большом проекте, можно получить неожиданные изменения исполнения:

1. Функции могут начать работать на других акторах.
2. Появится больше варнингов.
3. Возможны скрытые гонки данных.

Как мигрировать безопасно

1. Включить настройки по одной, а не все сразу.
2. После каждого шага — тесты + Thread Sanitizer.
3. Проверить async-методы: если они должны быть параллельными, выставить @concurrent.
4. В Swift Package — обновить swift-tools-version до 6.2.

Что имеем в итоге

Approachable Concurrency делает Swift конкурентность понятнее и безопаснее, но требует аккуратной миграции. Это не просто новые аннотации. Это изменения в том, как Swift действительно будет выполняет код.

Включаем 6.2 в целом для таргетов и в том числе в пакетах.

📓 Approachable Concurrency in Swift 6.2: A Clear Guide
🎥 Swift 6.2: Finally - Concurrency Made Approachable

#D #Swift #Concurrency #Async

👏

🇷🇺 В России «отрубают» FaceTime. По данным Роскомнадзор, сервис «используется для организации терактов и мошенничества» (как и многие другие мессенджеры и VPN).
🛑 Вместе с этим продолжают совершенствовать ограничения к VPN.
🤔 Кто уже начал использовать Max?

#L #sanctions #FaceTime #VPN

👏

🤓 Когда ~10 лет назад я начинал в разработке на ASP.NET, на бэке мы много работали с БД и активно использовали Specification + Repository.

Это давало магическое ощущение:
типобезопасно, без строковых SQL-запросов, удобно фильтровать и получать данные.
Чтобы понять всю механику работы, я тогда потратил не один день на чтение документации и мучения ведущего разраба, но кайф от подхода был огромный.

Позже я пытался воспроизвести то же на Symfony + PHP, и почувствовал огромную разницу работы:
другие абстракции, ActiveRecord по всему проекту…
В итоге (менее типизированный) почти-голый SQL на PHP, как ни странно, работал кратно быстрее, чем ASP.NET со спецификациями.
На то было много причин, от местоположения арендованных серверов, до специфики работы паттернов и фильтрации, сейчас не об этом.

Когда я пришёл в мобилку, первый проект тоже был с БД, и я долго объяснял тимлиду, почему типобезопасный доступ к данным - топ.
На самом деле я просто хотел того же опыта, той же предсказуемости.

И вот теперь — появился #Predicate, который по сути является макросом над NSPredicate.
То есть всё те же плюсы типобезопасности + читабельности, но без существенного падения перформанса, по идее (посмотрим на практике).

В целом, макросы всё глубже прорастают в Swift-разработку — и, имхо, делают нашу жизнь сильно лучше.

#L #SwiftData #Predicate

👏

🔄 SwiftUI: удобная прокрутка с помощью ScrollTargetBehavior

Почитал хорошую статью на Medium про механизм прокрутки в SwiftUI – ScrollTargetBehavior.
Решил поделиться самой полезной выжимкой + реальными примерами.

🧲 Что вообще такое “snap”?
Snap-прокрутка – это когда после скролла список «прилипает» к ближайшему элементу.
Не останавливается где попало, не обрезает карточку наполовину, а аккуратно доезжает до нужной позиции.

Примеры из жизни:
- карусель App Store
- галереи фото
- карточки в музыкальных приложениях

Раньше приходилось собирать на UIScrollViewDelegate, offset-вычислениях и тд.
Теперь – один модификатор.

🍕 Что даёт ScrollTargetBehavior
В SwiftUI есть два поведения «из коробки»:
- .paging
Постраничная прокрутка. Один свайп = один экран/элемент.
- .viewAligned
Выравнивание по ближайшему элементу – подходит для карточек и горизонтальных списков.

И самое интересное: можно написать своё собственное поведение.
Учитывать скорость свайпа, размеры элементов, направление – и решать, куда именно «приклеится» список.

👩‍💻 Примеры
1. Карусель изображений с paging

ScrollView(.horizontal) {
    LazyHStack(spacing: 0) {
        ForEach(items) { item in
            CardView(item)
                .frame(width: UIScreen.main.bounds.width)
        }
    }
    .scrollTargetLayout()
}
.scrollTargetBehavior(.paging)
.scrollIndicators(.hidden)

Теперь листается как полноценная галерея – экран за экраном.

2. Вертикальный список, который «прилипает» к ближайшей карточке

ScrollView {
    LazyVStack(spacing: 16) {
        ForEach(cards) { card in
            CardView(card)
                .containerRelativeFrame(.vertical)
        }
    }
    .scrollTargetLayout()
}
.scrollTargetBehavior(.viewAligned)

После прокрутки список автоматически выравнивается по ближайшему элементу.

3. Кастомный snap: быстрый свайп пролистываем на 2 карточки

struct FastPaging: ScrollTargetBehavior {
    func updateTarget(_ target: inout ScrollTarget,
                      context: ScrollTargetBehaviorContext) {

        // если жест быстрый — пролистываем дальше
        if context.velocity.magnitude > 1500 {
            target.index += context.velocity.width > 0 ? 2 : -2
        } else {
            // стандартная логика
            target = context.target
        }
    }
}

Использование:

.scrollTargetBehavior(FastPaging())

🍕 Почему это лучше старых решений
До iOS 17 snap-прокрутку собирали через:
- вычисление scrollOffset
- DragGesture + кастомные вычисления позиции
- UIScrollViewDelegate через UIViewRepresentable

Теперь:
- поведение описано декларативно
- ScrollView сам учитывает инерцию и скорость жеста
- одинаково работает в LazyVStack / LazyHStack / обычном ScrollView
- можно расширять собственными правилами

🎯 Что получаем?
ScrollTargetBehavior – современный, нативный и гибкий способ управлять прокруткой в SwiftUI:
- аккуратный snap
- предсказуемое и понятное поведение
- возможность тонкой настройки
- минимум костылей, максимум стабильности

#R #SwiftUI

👏

😋 🎮 Наткнулся на статью про реверс игры для Nintendo 64.
Автор декомпилирует Snowboard Kids 2 в режиме matching decompilation - когда итоговый C-код после компиляции должен давать тот же бинарь, что и оригинальный ассемблер.

🧠 Для работы он построил флоу с Claude-агентом:
1. Использует decomp.me для исходной декомпиляции.
2. Сравнивает результат компиляции восстановленного кода с оригинальным бинарём.
3. Если совпадение неполное - подключает агентов, которые ищут расхождения и итеративно повторяют цикл декомпиляция → компиляция → сравнение.
4. В случае стагнации или деградации агент передаёт задачу человеку.

✅ Где агенты хороши:
— ловят повторяющиеся паттерны в машинном коде;
— предлагают варианты функций, которые вручную копать долго;
— ускоряют черновые этапы и снимают рутину.

❌ Где они проваливаются:
— иногда ошибаются в базовой арифметике;
— «забывают» окружение (вплоть до выбранного компилятора);
— ломают control flow в ветвистых кусках в духе goto.

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

#L #AI #ReverseEngineering #Decompilation

👏

🤓 💬 Рабочий кейс: правильная коммуникация в команде — половина успеха.

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

Мои правила, комммуникации в чатах:

1️⃣ Пиши всё в одном сообщении.
Приветствие, контекст, что нужно, сроки — одним четким блоком. Это экономит время и снижает шанс быть неправильно понятым.

2️⃣ Собирай обратную связь.
Уточняй, верно ли тебя поняли. Сам реагируй тоже одним сообщением и — если возможно — в треде. Подзывай всех участников, чтобы никто не выпал.

3️⃣ Фиксируй решение.
Одним финальным сообщением: контекст → решение → почему так. Это сильно снижает количество “а что в итоге решили?”.

💡 Самое важное — пункты 1 и 3.

И да, имхо, зачастую, “правильная коммуникация” — это 50–80% успеха задачи.
Наблюдение: люди с хорошими коммуникативными навыками растут в карьере быстрее. 😉

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

#L #Communication

👏