YDC — Pizza Powered 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 👏

😄 Combine, Async/Await, Actors Еще одна статья про сравнение инструментов распараллеливания работы. Каждый инструмент решает свою задачу (последовательные операции, реактивные потоки, и защита общего состояния соответственно), как их сочетать и какие типичные ошибки нужно избегать при проектировании реального iOS-приложения. Combine Фреймворк для реактивных потоков: публикация значений во времени, операторы трансформации (map, filter, debounce, flatMap, merge и т.д.). Идеален для live-streams (поиск с debounce, данные с датчиков, пользовательский ввод, непрерывные обновления). Async/await Предназначен для последовательных, линейных асинхронных задач (одиночные сетевые запросы, цепочки запрос >> обработка >> рендер). Читабельный код, простой поток обработки ошибок и отмены задач через try/await и throws. Actors Механизм изоляции состояния: гарантирует последовательный доступ к свойствам актора, устраняя гонки данных и необходимость ручных блокировок. MainActor используется для UI-связанного состояния. Есть ли паттерн выбора решения? - Если это одна асинхронная операция, то используем async/await. - Если это поток событий, то используем Combine. - Если есть разделяемое изменяемое состояние, к которому обращаются несколько задач, то используем actors. - Часто правильный вариантом будет комбинация: actor для хранения/защиты состояния, async/await для одиночных операций, Combine для подписки на потоки и реактивной логики. Какие могут быть ошибки в использовании? - Бессистемное смешивание Combine и async/await. Их совместное использование возможно, но лишние преобразования Publisher-AsyncSequence увеличивают сложность кода и накладные расходы. - Использование actors повсюду. Акторы дают безопасность, но имеют затраты на изоляцию. Не нужно превращать в actor каждый класс, только те в которых есть общее изменяемое состояние. - Игнорирование структурированной конкуренции. Вместо самостоятельного управления потоками лучше пользоваться TaskGroup/withTaskGroup

😄Рубрика кликбейт или "потраченного времени жаль" Листал свой фид, искал вдохновение о чем бы написать в канал и нашелся, на первый взгляд, идеальный кандидат на первый пост в этом году от меня О чем: Swift заменил Objective-C не потому, что тот был стар, а потому, что developers were the bottleneck 🎯Какие тейки: • разработка была секретна  • в iOS 15.1 16 из 22 фиксов были связаны с управлением памятью = дорого для Apple (из-за регуляторных затрат) • в целом ошибки при работе с памятью стоили Apple $67 ярдов • последние фичи в Obj-C были как раз для совместимости с Swift 🚀В Swift Apple сняла значительную часть рисков с разработчиков (на самом деле с себя) и переложила на компилятор: • Снесла (почти) Message dispatch = меньше проверок в runtime • В целом система типов стала жестче • В Swift Concurrency отдали компилятору разгребать Data Races = убрали самый сложный тип багов • Синтаксис приведен ближе к модным Python/JS и тд = больше вкатунов 🤔 От себя В целом, история звучит складно, но • откуда тейк про 67 ярдов - не понятно, just trust bro • не припомню, чтобы по статистике от OWASP мобилки сильно страдали от memory management, как будто в топе были иные проблемы (можно вспомнить про Dirty-COW, но насколько она эксплуатируема в мобилках - инфы нет) • раз была серьезная проблема, то почему так мало персонала было привлечено к разработке и релиз состоялся только через 4 года? "Небизнесовый" подход какой-то, тот же Go за год-два сварили (чую "это другое", спорить не буду) ну и добило меня Java had solved memory safety with garbage collection — but the unpredictable pauses were unacceptable for iOS’s fluid 60fps animations как будто у дроид-коллег были большие проблемы с 60fps анимациями именно из-за сборщика мусора, напишите в комменты 🍿 По итогу ощущение такое... то-ли кликбейт, то-ли нейронка написала (длинных "—" много, да, это косвенно), грустно 😭 🍕А выводы то какие? А вот выводы автор делает как будто в отрыве от всей остальной статьи, они довол

🍟 Легкое и познавательное чтение перед выходными —————— 🤫 Особенности построения и развития дизайн-системы в мобильном приложении СберЗдоровья В разработке нередко встречаются ситуации, когда разные части проекта имеют различный внешний вид и поведение, что затрудняет поддержку, ведет к увеличению сроков выпуска обновлений и ухудшению качества продукта. Решением подобных проблем является дизайн‑система, которая обеспечивает единую библиотеку компонентов и строгие правила их использования, позволяя сократить время разработки, минимизировать расхождения между частями продукта и значительно облегчить дальнейшую работу над проектом. Наш братик и по совместительству 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 👏

🤖 📡 Базовые протоколы клиент-серверного взаимодействия (без обратной связи) Хочется сделать серию постов по основам CS и system-design. Если будет отклик, масштабируем в mind-map. И начать хочется с сетевого взаимодействия. Когда мы говорим про клиент-серверные запросы в большинстве приложений, мы почти всегда имеем в виду модель request → response. Важно сразу зафиксировать: это не всегда про HTTP, хотя на практике часто выглядит именно так. В первом посте разберём основные стили взаимодействия, которые используются для однонаправленных запросов с ответом. 📌 Немного про транспорт: - SOAP — почти всегда поверх HTTP/HTTPS - REST — по определению строится поверх HTTP - GraphQL — чаще всего поверх HTTP, подписки через WebSocket (но об этом можно глубже, в другом посте) - RPC — не обязан использовать HTTP 👉 Поэтому корректнее говорить не «HTTP-протоколы», а API-стили / протоколы поверх разных транспортов. Небольшая затравка из практики: В бородатых годах я использовал Apache Thrift на Objective-C — тогда для меня это был "магический" опыт с RPC: отличный кодген, строгие контракты, минимум ручной работы. Это был классический пример RPC-подхода, задолго до хайпа gRPC, и он отлично показывал разницу между: - «я работаю с ресурсами» (REST) - и «я вызываю удалённые методы» (RPC) Детальнее про протоколы: 🔹 SOAP (Simple Object Access Protocol) Что это: Строгий протокол обмена сообщениями, основанный на XML и формальных контрактах (WSDL). Транспорт: почти всегда HTTP Когда применять: - корпоративные и интеграционные системы - среды с жёсткими требованиями к контрактам, безопасности и совместимости Почему: SOAP — это максимум формализма: строгая схема, строгие правила, минимум свободы. Цена — высокая сложность и избыточность. 📍 SOAP — это «корпоративный стандарт», а не инструмент скорости. 🔹 REST (Representational State Transfer) Что это: Архитектурный стиль, завязанный на HTTP, где всё крутится вокруг ресурсов и их состояний. Транспорт: HTTP. Когда применять: - CRUD-сц

☝️ 📦 Размер приложения — это не просто цифра в 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 аналитика позвол

☝️ 🚀 Как MCP-аналитика помогает AI-агентам кодирования принимать более «осознанные» решения AI-агенты всё чаще используются для помощи в разработке кода: автоматический code review, рефакторинг, автогенерация тестов и т.д. Но что если дать агентам не только доступ к самому коду, но и к данным о продукте, пользователях и эффективности фич? 📊 Вот статья, об использовании MCP для оптимизаций Rocket-Sim от SwiftLee. Кратко: 🔹 AI обычно принимает решения только на основании синтаксиса и семантики кода. 🔹 MCP интегрирует контекстные данные: метрики использования, показатели конверсий, результаты A/B-тестов и др. 🔹 Решения становятся не только технически корректными, но и бизнес-ориентированными. 💡 Что это даёт в практике разработки: ✔️ AI может приоритизировать решения не только по сложности кода, но и по влиянию на KPI. ✔️ Предложения по оптимизации функциональности учитывают реальные пользовательские данные. ✔️ Улучшается связь между агентом и аналитикой продукта. #L #AI #MCP 👏

😄 Статья CoordinatorKit 2.0: Production-Ready SwiftUI Navigation это пример честного разбора автором своих же ошибок. Можно даже сказать, пост-мортем. В противовес многочисленным “hello NavigationStack”, в ней хорошо объясняется, почему нативные SwiftUI-паттерны ломаются и даёт идеи, которые можно заимствовать даже без внедрения фреймворка или использовать как основу собственной навигационной архитектуры. На самом деле сделать фреймворк навигации, который будет удобным для использования и гибким для переиспользования под разные продуктовые кейсы это невероятно сложная задача. В больших проектах никуда без диплинков, сложных навигационных кейсов типа логин/логаут или внезапных кросс-фичовых переходов. Отдельного внимания заслуживает обработка жестов вроде смахнуть/свайпнуть экран, а точнее запретить это сделать для отдельных продуктовых случаев. Между первой и второй версией фреймворка виден невероятный разрыв. Аналогично, первая статья выглядит как наивная попытка сделать все легко, чисто и по правилам паттерна. А вторая статья это уже полноценный инструмент, набравший силы, повидавший требования и изменчивость продакшна. Топ "неожиданных" инсайтов: ❌ SwiftUI navigation не production-ready из коробки. 🍋 Достаточно больно жить без контроля над жестами, над root-экраном и над состоянием стека. 🐸 Coordinator-паттерн остаётся актуальным, но должен быть интегрирован глубже, должен быть concurrency-safe и должен перехватывать жесты, а не реагировать пост-фактум. ✈️ Навигация, по своей сути, ближе к бизнес-логике, чем к деталям UI. 📎 GitHub: CoordinatorKit #D #Arch #Navigation #Coordinator #SwiftUI 👏