🐢 Привет! Мы — команда 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

👏

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

В этом канале я рассказываю про архитектуру, 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

👏

😁 Всем привет 👋
Хочу рассказать про крутой инструмент - 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

👏

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

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

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

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

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

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

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

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

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

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

👏

😄Почему мы стараемся минимизировать сторонние зависимости?

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

😖Основной недостаток на наш взгляд - это зависимость от maintainers библиотеки (vendor lock), из-за чего зачастую следуют:

🔺 Новые неожиданные баги с обновлениями версии Xcode или версии языка
🔺 Неопределенность с поддержкой - библиотеку запросто могут забросить и вы останетесь 1 на 1 с ней, формируя техдолг

Помимо обозначенных рисков есть еще и другие неудобства:

🔺 Сложности с "выпиливанием" библиотеки (опыт Dodo с Realm)
🔺 Увеличение размера бинарника
🔺 Ожидания стабильного релиза после очередных "подарков" от Apple
🔺 Конфликты с другими зависимостями
🔺 Сложность отладки - не видно stack trace в исходниках библиотеки

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

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

1️⃣ Необходимо владеть критическими частями кода, основной логикой, не отдавать флоу в "чужие руки"
2️⃣ Влияние зависимости на размер и скорость приложения должно быть контролируемым
3️⃣ Maintainers - надежные и проверенных сообществом, "живость" репозитория
4️⃣ Обращаем внимание на лицензию. Если зависимость критически важна и у нас недостаточно ресурса на разработку своего решения, то крайне желательно иметь возможность "форкнуть" и "причесать" под свои нужды в будущем в рамках техдолга

💎 Вместо итогов

Мне понравилась цитата из свежей статьи на Medium:

Если ты не контролируешь код, тогда код контролирует тебя

Имхо, со сторонними зависимостями это справедливо вдвойне, тк даже не вы написали этот код и зачастую вы его даже не видите в отладке

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

#iOS #SoftwareArchitecture #Dependencies #TechDebt

👏

😄ARC, что внутри?

Казалось бы, тема пройдена вдоль и поперек, однако на технических интервью я периодически встречаю недопонимание принципов работы ARC даже у опытных разработчиков

⚡️Самый важный момент:

ARC "живет" только при компиляции

Он не отслеживает объекты в рантайме, не решает, когда освобождать память. Его задача - вставить в скомпилированный код вызовы функций, которые при MRC в Objective-C разработчик расставляет самостоятельно:

👉 objc_retain(ptr) - увеличивает счетчик ссылок объекта
👉 objc_release(ptr) - уменьшает счетчик
👉 objc_autorelease(ptr) - отложенное уменьшение счетчика, сегодня редкий кейс, об этом чуть ниже

Роль рантайма же - слепое исполнение инструкций. Если счётчик достигает нуля, объект немедленно деаллоцируется: вызывается deinit, освобождаются stored-свойства, память возвращается в кучу.

Что до счётчика ссылок - он хранится в заголовке объекта в куче и создаётся при аллокации объекта. Из Swift-кода доступа туда не получить

🤔 Что по autorelease?

Используется редко, но стоит упомянуть в контексте autoreleasepool. ARC вставляет autorelease только тогда, когда на этапе компиляции не может точно определить момент окончания владения объектом:

👉 Границы Swift ↔ Objective-C
👉 Объекты с атрибутом

@autorelease

Важный момент: autorelease не откладывает деаллокацию. Он откладывает выполнение release в конце блока autoreleasepool, итерации runloop'а или при завершении потока

Именно поэтому autoreleasepool внутри циклов так важен для управления памятью. Без него множество больших объектов будут накапливаться в пуле до конца итерации runloop'а, вызывая скачок потребления памяти

Итоговая модель выглядит так:

1️⃣ Swift-код
2️⃣ ARC на этапе компиляции вставляет вызовы retain/release/autorelease
3️⃣ Рантайм аллоцирует объект с заголовком
4️⃣ Retain → увеличивает счётчик. Autorelease → добавляет объект в пул (счётчик не меняется)
5️⃣ Пул завешается → выполняются release для всех объектов в пуле
6️⃣ Если счётчик == 0 → немедленная деаллокация.

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

📎 Что почитать?

Постарше
Посвежее
Очень старая дока по ObjC, но многое актуально и для Swift

#iOS #Swift #ARC #MemoryManagement #Performance

👏

🍕 Хочется потихоньку выходить из новогоднего вайба и начинать набирать тонус и жизненный и рабочий.
И начать год хочется с первой статьи — и снова про AI-кодинг.
Похоже, ничего не предвещает, что темой года станет что-то другое.

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

Пару мыслей, о которых мы уже не раз писали, но которые за этот год только усилились:

Модели стали слишком умными, чтобы жить по старым правилам.
Куча документации, отдельный промт-инжиниринг — всё это постепенно уходит.
В большинстве случаев ты просто просишь сделать то, что нужно, и модель делает.
Единственный нюанс: в новых проектах всё по-прежнему сильно выигрывает, если правильно дать старт архитектуре и сразу же вместе с AI сформулировать Agents.md.

Инструментов становится всё больше, и выбор должен идти от задачи.
Но если честно — OpenAI и Codex сейчас топ из топов.
Почти все исследования сходятся в одном: GPT-5.2 — имба.

Использование топовых LLM вместо локальной инфры неимоверно бустит качество.
Да, возможно, со временем баланс сместится.
Но точно не в этом году. Имхо.

P.S. Моё текущее комбо для кодинга:
xcodebuild MCP + Agents.md + Codex + VS Code — лучшее, что сейчас есть для написания кода.
Ограничения контекста, к сожалению, всё ещё боль для Codex - нет поддержки .ignore файла аля .claudeignore.
Думаю, все таки, в этом году мы должный прийти к единому .aiignore.
Очень жду, что в 2026 Codex подтянут именно эту часть.

#L #AI #MCP #iOS

👏

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

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

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

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

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

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

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

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

#L #BuildCache #iOS #Tuist #xcode

👏

🤖 🔐 Нативный способ борьбы с фродом на iOS: DeviceCheck (App Attest)

В iOS есть два системных механизма от Apple, которые реально помогают с анти-фродом — DeviceCheck и App Attest.

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

📱 DeviceCheck
Позволяет понять, что запрос пришёл с реального устройства и пользователь не пытается подделать свою активность.
- Выпускаем ключ для приложения на developer.apple.com
- Клиент в рантайме получает deviceToken через DeviceCheck API
- Сервер валидирует его через Apple и может читать/писать два бита состояния, которые Apple хранит для пары устройство + приложение (подписывая с помощью jwt).

Типичные кейсы:
- «один бонус на устройство»
- пометить девайс как подозрительный
- soft-ban без аккаунта

🔐 App Attest
Решает другую задачу (аналогичную deprecated ручке v1/validate_device_token) — подтверждает, что запрос идёт от оригинального приложения, а не от модифицированного.
- Добавляется новый капабилити
- Получается ключ (создаётся внутри Secure Enclave, наружу не экспортируется) для генерации nonсe с бекенда
- Генерируется обьект attestation на основе приватного ключа и nonce и отправляется на бекенд для дальнейших проверок
- Далее с помощью приватного ключа и nonсe генерируются assertion для отправки на сервер и верификации приложения

Application даёт сигнал, Apple — источник доверия, Backend принимает бизнес-решение.

P.S.: Ну и как всегда в разрезе security - оговорки. Jailbreak - все сломает (улучшайте jailbreak-detection), SSL-pinning поможет повысить защиту, скрывайте секреты, используйте обфускацию и шифрование.

#L #Security #AntiFraud #DeviceCheck #iOS

👏

🍟 Легкое и познавательное чтение перед выходными
——————

🤫 Особенности построения и развития дизайн-системы в мобильном приложении СберЗдоровья

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

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

Наш братик и по совместительству Android‑разработчик из СЗ, в статье рассказывает, как строили мобильную дизайн‑систему на iOS и Android проекте на SUI и Compose, соответственно, и оптимизировали интерфейсы

#L #DesignSystem #iOS #Android

👏

☝️ В модульных iOS-приложениях важно понимать как именно линкуются модули.

Существует 3 типа линковки:
• Static
• Dynamic
• Mergeable

Почему это важно? Тип линковки напрямую влияет на:
• модульность и управляемость архитектуры,
• размер приложения,
• скорость запуска.

Хороший разбор с примерами — тут.

Отдельно отмечу mergeable libraries. Tuist прямо говорит о cost of convenience,
и я с этим полностью согласен:
➡️ mergeable почти всегда сложнее организовать,
➡️ сложнее явно контролировать и дебажить, чем осознанная и прозрачная логика линковки.

Подход который использую я, и который сквозь время доказал свою пригодность и масштабируемость (под бинарные кеши всякие т.д. не страдая качеством):
• staticForDeploy — все библиотеки статические, кроме тех, что шарятся с экстеншонами
• dynamicForDev — всё динамика для комфортной разработки

Вся логика механизма зашита в Tuist.ProjectDescriptionHelpers, дополняется оверрайдами в CocoaPods и SPM.

Итог: быстрее старт приложения в проде, удобство разработки и контролируемая архитектура без магии.
P.S.: Если интересно, чуть больше года назад рассказывал об этом подробнее.

#L #Linkage #iOS

👏

☝️ 📦 Размер приложения — это не просто цифра в App Store

Размер приложения напрямую влияет на:
- конверсию в установку (особенно в регионах с мобильным трафиком),
- время загрузки и first launch,
- обновляемость (пользователь чаще откладывает “тяжёлый” апдейт),
- хранение на устройстве.

Исторически порог в ~200 МБ считался психологическим и сетевым барьером — при крупных загрузках.
App Store, например предлагает переходить на Wi-Fi.
Даже несмотря на изменения лимитов, сам эффект остаётся: чем тяжелее билд, тем выше friction.

Недавно я интегрировал в нативное iOS-приложение Flutter-модуль. И это автоматически поднимает целый пласт инженерных вопросов:

🧩 Flutter inside native: что пришлось анализировать

1️⃣ Dependency resolution
- transitive зависимости (резолв общих нативных SDK)
- влияние flutter-плагинов на iOS/Android-проект
- корректную сборку в release profile

2️⃣ Оптимизацию release-сборки
- оптимизации Flutter.framework и App.framework (термины flutter)
- в том числе удаление неиспользуемой функциональности

3️⃣ Бинаризацию Flutter-модуля
- сборка в xcframework
- кэширование артефактов
- минимизация пересборки нативного проекта
- влияние на CI и локальный DX

Отдельная боль — время сборки. Flutter внутри iOS может существенно увеличить clean и incremental build, если не выстроить правильную стратегию доставки и кэширования.

В целом по тех стеку для оптмизаций flutter проекта, можно тут почитать.

🏗 Но оптимизации — это не только Flutter. Мы давно системно работаем с нативным стеком:

🔹 On-Demand Resources (ODR)
- Подгружаем тяжёлые ассеты по требованию.

🔹 Модуляризация
- изоляция фич
- переиспользование кода
- контроль зависимостей

🔹 Работа с ресурсами
- поиск дубликатов и больших ассетов
- анализ неиспользуемых ассетов
- контроль веса .xcassets
- внутренняя аналитика через скрипты и graphana

🔹 App Thinning
- понимание slicing
- корректная работа с architectures
- оптимизация universal vs device-specific бинарей

🔹 App Store Connect аналитика позволяет контролировать:
- размер IPA
- размер установленного приложения
- вариативность по устройствам

📊 По факту размер — это не разовая оптимизация, а процесс:
- инструменты анализа
- прозрачные метрики
- контроль на CI
- ответственность на уровне архитектуры.

Flutter, натив, ресурсы, сборка — всё это части одной системы.

#L #iOS #AppSize #Flutter

👏