Swift *

Telegram — технически самый сложных мессенджер в мире. В iOS приложении 2.1M+ строк, 700+ модулей, 86% Swift, 13 лет кодовой базы, и мало ObjC — это колоссальный труд.

Но при этом приложение лагает на флагманах, AsyncDisplayKit открывает по 10 дублей окон разом(а это явно тормозит ARC), крэши на редактировании изображений стабильны годами.

Почему?

Потому что 86% кода написаны на Swift, но разработчики мыслят все еще в парадигме ООП.

ООП в Swift — это не просто устаревший стиль, это потерянная производительность.

Миграция большого iOS-проекта с Objective-C на Swift кажется понятной задачей ровно до тех пор, пока не начинаешь считать объём. В нашем случае это были 10 тысяч файлов, сотни тысяч строк кода и постоянная необходимость не останавливать развитие продукта. Ручной подход работал слишком медленно, поэтому мы начали автоматизировать миграцию с помощью LLM — и в итоге превратили её из бесконечного техдолга в воспроизводимый процесс.

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

Меня зовут Андрей Сикерин, я руковожу одной из групп iOS-разработки Яндекс Браузера. Вместе со мной статью писала Елизавета Мазулова, разработчица из нашей же команды. Она создала систему промптов для миграции, ревью, рефакторинга и автоматизации тестирования. Вместе мы расскажем, как устроен весь процесс изнутри: от выбора порядка миграции модулей до контроля качества через тесты.

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

За последний год я перепробовал всё: Cursor, Claude Code, Codex, локальные Qwen-модели для ревью, пять версий своего CLAUDE.md, Xcode MCP от Apple, mobile-mcp, Conductor для параллельных агентов. Что-то осталось в проде, что-то выкинул через неделю. А какие-то вещи, которые казались обязательными год назад, сегодня выглядят как антипаттерны.

Это статья не про «AI изменит всё» и не про то, как за вечер собрать Todo-приложение через Claude Code. Это про то, как iOS-разработчику, который уже живёт с AI-инструментами, выжать из них максимум - и не наступить на грабли, на которые наступили до тебя остальные.

Представьте ситуацию: вы работаете в огромном проекте, где количество модулей давно перевалило за тысячу. Вы решаете обновиться до свежего Xcode 26.2, ожидая прироста производительности, но вместо заветного «Build Succeeded» получаете молчаливое падение: SWBBuildService quit unexpectedly.

Всем привет, меня зовут Алексей Севко, я ведущий разработчик программного обеспечения из команды Delivery & Performance Яндекс Go. В этой статье я расскажу почти детективную историю о том, как:

— Искать иголку в стоге сена: когда падает закрытый бинарник Xcode.

— Стать контрибьютором swift-build: почему иногда проще переписать системный поиск макросов в swift-build, чем ждать фикса от Apple.

— Использовать свою версию билд-системы: как мы внедрили инфраструктуру прозрачной подмены компонентов Xcode через XCBBUILDSERVICE_PATH, чтобы не ждать релиза Xcode со Swift 6.3 и работать стабильно уже сегодня.

Если ваш проект тоже перерос стандартные инструменты Apple или вам просто интересно, как превратить рекурсию в итерацию и не сойти с ума от 45-минутных дебаг-сессий, — добро пожаловать под кат!

AIVPN — это VPN-протокол на Rust, который не только шифрует трафик, но и маскирует его под реальные приложения. Внутри: короткие криптотеги вместо открытого идентификатора сессии, малозаметный старт соединения, профили масок для мимикрии трафика и легковесный модуль нейросетевого резонанса, который отслеживает деградацию маски и позволяет автоматически переключаться на резервный профиль. Сейчас проекту нужна поддержка для развития протокола и выпуска iOS-версии с оплатой Apple Developer Program и размещением в App Store.

У меня нет макбука. Но два моих приложения лежат в App Store. Рассказываю весь путь: регистрация Apple Developer из России, сертификаты без Xcode, автоматическая сборка через GitHub Actions. Три варианта: для вайбкодеров, программистов без мака и хардкорщиков.

Всем привет! Я Данила Горячкин — iOS-инженер в команде Performance в Авито. Занимаюсь оптимизацией производительности iOS‑приложений и менторингом разработчиков.

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

Всем привет! Я Данила Горячкин — iOS-инженер в команде Performance в Авито. Занимаюсь оптимизацией производительности iOS‑приложений и менторингом разработчиков.

В этой статье последовательно разберем, как Swift управляет памятью: от базовых понятий вроде ARC,  Copy‑on‑Write, экзистенциальных контейнеров до нетипичных задач с «зомби»-объектами и non-frozen типами. Материал основан на документации Swift, докладах WWDC и практических примерах. Статья рассчитана на middle- iOS‑разработчиков, которые хотят лучше понимать, что происходит с их кодом на уровне памяти и почему одни решения оказываются дороже других.

Эта статья выйдет в двух частях: в первой разберем теорию, а во второй — практические примеры с кодом.

Как я без Mac, с помощью Claude AI и GitHub Actions, создал кроссплатформенное приложение для шифрования сообщений поверх любого мессенджера. Android на Kotlin, iOS на Swift без MacBook, десктоп на Python. AES-256, три платформы, два отказа от Apple и один баг с буквой «а».

Привет, Хабр! Меня зовут Кирилл Маканков, я iOS-разработчик в ПСБ.  

Сегодня хочу поговорить про особенности реализации MVVM. Не с практической, а с теоретической стороны. С практической стороны этот архитектурный шаблон давно уже изучен вдоль и поперёк. А вот теоретических исследований, особенно применимых к Swift (и в общем, и к SwiftUI в частности), не так уж и много. Давайте вместе попробуем закрыть этот пробел и обосновать с теоретической точки зрения те или иные вариации реализаций в нашей ежедневной работе. Мобильным разработчикам на ObjC, Java и Kotlin данное исследование и обсуждение тоже будет полезно. Присоединяйтесь!

Если вы уже хорошо знакомы с MVVM, то в конце приведен опрос об используемой лично вами реализации. Давайте вместе определим, какая из реализаций самая популярная.

Swift известен системой pattern matching. Большинство разработчиков используют её в switch, иногда в if case или guard case. Но в языке есть ещё одна конструкция, которую многие никогда не видели — for case let.

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

В этой статье я хочу разобраться:

В работе постоянно сталкиваешься с багами. В топе самых неприятных — крэш. Еще хуже — когда он неочевидный, и сразу сложно сказать, откуда "растут ноги". В этой статье попробуем воспользоваться LLDB для разбора проблемы на реальном примере.

Вы узнаете, как на самом деле работает магия приложения Локатор (Find My в англоязычной версии): от аппаратных хитростей контроллера питания до пост-квантовых алгоритмов шифрования. Мы разберем, почему «выключенный» iPhone - это лишь иллюзия для пользователя, как математика защищает ваши координаты от самой Apple и почему ваш смартфон превращается в криптографический маяк, когда гаснет экран. Статья будет интересна разработчикам, специалистам по безопасности и всем, кто хочет понимать реальные возможности (и ограничения) современной электроники.

Если вам когда-нибудь приходила задача сделать страницу профиля как в популярных социальных сетях, то вы понимаете всю боль верстки такого дизайна на SwiftUI — особенно для версий iOS ниже 16. Готовые решения не гуглятся, полностью рабочих репозиториев нет, ИИ ещё не умеют в такие комплексные задачи, а Telegram скрывает похожий лэйаут за внутренними библиотеками. Давайте разбираться, что тут можно придумать.

Снепшот-тестирование — один из немногих надёжных способов контролировать визуальную целостность SwiftUI-компонентов. Но что делать, если ваш проект ограничен Xcode 13.3 и Swift 5.6, а большинство компонентов дизайн-системы обёрнуты в UIViewRepresentable?

Меня зовут Денис Третьяков, я iOS-разработчик в ПСБ. В этой статье расскажу, как мы организовали снепшот-тестирование SwiftUI-компонентов в условиях жёстких ограничений, с какими проблемами столкнулись и как их решили.

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

Проблема известна. Scala использует implicit parameters на уровне языка, Kotlin экспериментирует с context receivers, Android полагается на Dagger. А Swift не предлагает встроенного решения. Поэтому мы в команде Яндекс Браузера создали библиотеку Implicits — механизм неявной передачи зависимостей с compile‑time‑проверками. Она успешно работает в продакшне Браузера на полутора миллионах строк Swift‑кода, а ещё доступна в опенсорсе.

В этой статье я расскажу о поиске собственного подхода для передачи зависимостей в коде на Swift, о том, как внедрение Implicits позволяет существенно сократить boilerplate, ускорить рефакторинг и улучшить читаемость кода благодаря локальному объявлению только реально используемых зависимостей, а также покажу реальные примеры из продакшн‑кода мобильной версии Яндекс Браузера.

Привет, меня зовут Антон Огнев, я iOS-разработчик в ПСБ, и в этой статье расскажу о классах, компонентах и зависимостях между ними. Конкретно речь пойдет о том, какие принципы стоит всегда соблюдать при создании и поддержке компонентов, как определить, не рушит ли одна новая зависимость весь проект, как меняются приоритеты по компонентам между стартом новой разработки и зрелым продуктом. 

Большая часть теории основывается на книге «Чистая архитектура» Роберта Мартина. Я эту книгу читал несколько раз и каждый раз открывал для себя что-то новое, набирался опыта и на многие вещи начинал смотреть иначе. Между пояснением принципов буду делиться историями из собственных компонентных приключений в качестве примеров. 

Заглянули к себе в компоненты и обнаружили, что там бардак и обобщенные имена типа Cоmmon, Shared, Core, Base, Utils? Это текст для вас: сам был на вашем месте, помогу навести порядок. 

Привет! Я Тимур, разработчик мобильных приложений в KTS.

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

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

Да, тема довольно холиварная, и в статье я не заявляю, что KMP лучше Flutter’а во всем. Каждая технология хороша под свои задачи. Вместо этого я расскажу о конкретном проекте, на котором KMP оказался более удачным выбором. Также коснусь вопросов архитектуры и миграции Android-приложения на iOS с помощью CMP, а заодно подсвечу подводные камни, с которыми пришлось разбираться в процессе.

Привет! Меня зовут Антон, я iOS-разработчик в Банки.ру. Когда я только начинал изучать Combine, он казался для меня магией. Пара команд – и вот у тебя уже есть какие-то данные. Чтобы Combine перестал оставаться черным ящиком давайте заглянем внутрь. Эта статья – мое виденье этого фреймворка.

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

Давайте рассмотрим Combine изнутри!

Тестирование на Swift долгие годы держалось на трех китах: XCTest, сторонние библиотеки и собственная смекалка. Но на WWDC 24 Apple представила новый, современный фреймворк — Swift Testing, который предлагает концептуально новый подход к тестированию.

Меня зовут Кирилл Гусев. Я мобильный разработчик в ОК. В этой статье я расскажу о том, какие возможности предоставляет Swift Testing и как мы планируем их применять в ОК.