Разбор того, как отказаться от системного UINavigationBar и собрать собственный навигационный бар на обычном UIView: с коллапсирующим large title как у Apple, встроенной строкой поиска и произвольными панелями под заголовком — и так, чтобы он работал и с UITableView, и со списками на Texture (AsyncDisplayKit). Внутри — устройство компонента и честный разбор компромиссов из реального продакшена.
Для простых анимаций хватает UIView.animate и CABasicAnimation, но для сложных синхронных цепочек этого мало. Разбираю, почему Timer на 1/60 секунды рвёт анимацию под нагрузкой, и как CADisplayLink решает это, синхронизируясь с реальным обновлением экрана. Показываю свой DisplayLinkAnimator: строго согласованные констрейнты нескольких view, кастомные timing-функции и многоточечные кривые Безье (которых не даёт CAMediaTimingFunction), пауза и возобновление — с примерами кода.
Три ночи я был уверен, что у меня сломан рендер.
Вертикальные картинки — те самые 9:16, под обои телефона и под сторис, — на экране разъезжались горизонтальными полосами. Как будто старый телевизор поймал помехи. Квадрат рисуется нормально. Горизонталь — нормально. А вертикалку рвёт в труху.
Три раза я её «починил». И все три раза чинил вообще не то.
Правда оказалась дурацкой и красивой одновременно: файлы были в полном порядке. Рвало только то, как macOS показывала их на экране. Но к этому моменту я уже немного поседел.
Это не история из серии «смотрите, какой я молодец». Это честный рассказ, как обычный человек без программистского образования за неделю собрал себе на Mac локальный генератор картинок — и на какие грабли наступил по дороге. Я энтузиаст, не разработчик. И сразу самое важное, чтобы потом не было неловко: я не написал ни одной строчки кода. Ни единой. Даже Xcode толком не открывал. Код писал вместе со мной Claude Code, модель Opus 4.8. И сам движок генерации — тоже не мой. А моё во всём этом — то, что движок не топит ваш Mac и не показывает вам битые картинки. Звучит мелко? Вот про эту мелочь и весь рассказ. Прятать тут нечего, про границы расскажу честно прямо сейчас.
В мобильной разработке мы привыкли, что красивый анимированный фон — это либо видео, либо пара слоёв с CAGradientLayer и медленным параллаксом. Для большинства задач этого хватает. Но иногда хочется большего: настоящий живой космос — туманности, которые медленно перетекают друг в друга, планеты с кольцами, звёзды разных классов и в центре — чёрная дыра с аккреционным диском, как в «Интерстелларе».
У меня есть небольшая аркада-раннер про полёт сквозь космос. Фон там — не картинка, а процедурная сцена, которую целиком рисует фрагментный шейдер: каждый пиксель экрана вычисляется математикой из шума. Сначала всё это жило на SpriteKit, а потом я переписал на Metal — и вот тут началось самое интересное, потому что красивая сцена на десктопе и та же сцена на телефоне — это две очень разные истории.
Расскажу, как я это делал, на какие грабли наступил, и почему в итоге пришлось рисовать фон… полосками.
Я долго пользовался разными кодинг‑агентами, и на их фоне Claude Code для меня заметно выделялся: качеством решений, удобством работы и вниманием к деталям. В какой‑то момент мне захотелось не просто пользоваться таким инструментом, а понять, что на самом деле происходит у него под капотом. Так я сел писать собственного агента на Swift, с нуля, без использования готовых решений.
Довольно быстро стало понятно, что сложность не в том, чтобы вызвать модель и попросить ее сгенерировать код. Настоящая сложность начинается там, где система должна стабильно работать: удерживать контекст, пользоваться инструментами, справляться с ошибками и непредсказуемыми ответами модели. На обвязку вокруг модели и уходит почти все время.
Дальше я разберу места, где это проявляется: от устройства главного цикла до управления контекстом. Многие выводы задним числом кажутся очевидными, но на практике они становятся понятны, только тогда когда строишь агента сам и упираешься в каждую проблему руками.
AI сделал нас быстрее, очень сильно быстрее, но у этого момента есть побочный эффект. Наверно многим, кто уже столкнулся в вайбкодингом в своих проектах, знакомо такое чувство когда радуешься от того, что фичи делаются быстро и потом в какой-то момент ты понимаешь, что система деградировала настолько, что новое впиливается все сложнее и сложнее, кол-во багов растет, тех долг накапливается и кажется, что проще все снести и переписать.
В прошлой статье я рассказывал, как собрал мобильный видеоредактор с мультитреком, кейфреймами и ИИ‑ассистентом, который монтирует по промпту. Тогда ассистент умел резать, двигать, накладывать эффекты — но создавать картинки и видео приходилось где‑то сбоку: сгенерировал, скачал, импортировал, подогнал под проект.
Это раздражало. Монтаж — это поток. Любая лишняя вкладка в браузере — как пауза посреди джазовой импровизации.
Поэтому в MultiTrack появился встроенный ИИ‑генератор — отдельная панель «AI Generation» на базе Higgsfield. Не заглушка «попробуйте нейросеть», а полноценный цикл: промпт → генерация → скачивание → Import to Project → клип сразу в библиотеке и на таймлайне. Без выхода из редактора.
В 2025 году вместе с iOS 26 компания Apple представила разработчикам Apple Foundation Models. Теперь порог входа для on-device AI упал до нескольких строк, и далее в статье мы рассмотрим как он выглядит.
А в январе 2026 года Apple заключила сделку с Google в рамках которой следующее поколение Apple foudation models будет основано на технологии Google Gemini. По данным Bloomberg стоимость этой сделки составляет 1 млрд долларов в год. Apple по-прежнему держит контроль над пользовательскими данными, запросы будут выполняться локально, что-то сложное, с чем не может справиться локальная модель - будет отправляться в облако Apple Private Cloud Compute.
Несмотря на активное использование мессенджеров, электронная почта все еще занимает весомую долю в коммуникации, особенно в рабочей среде, из-за этого не исключена необходимость в отправке почтовых сообщений прямо с iOS приложения.
В данной статье мы ознакомимся с протоколами, по которым работает почта. Сфокусируемся на реализации протокола для отправки почтовых сообщений (SMTP) на низком уровне (BSD сокеты). И, используя собственный сетевой слой для работы с почтой, реализуем iOS клиент для отправки почтовых сообщений через любые почтовые провайдеры (ex: gmail, yandex, mail).
Эта статья — не ревью чужого кода и не пересказ абстрактных паттернов. Это практическое описание того, как я подхожу к проектированию сетевого слоя, какие решения считаю удачными, какие — опасными, и почему. Основа текста — реальный подход к построению сети в production iOS-приложении: с явной EndpointPolicy, RequestContext, interceptor-pipeline, безопасным логированием, отдельной обработкой refresh flow, snapshot-first чтением и выделенным transport для долгих upload-сценариев.
Мой главный тезис простой: сетевой слой — это не “место, где отправляются запросы”, а инфраструктура приложения. URLRequest и URLSessionConfiguration в Foundation уже работают как объекты, которые несут не только URL, но и правила поведения запроса; Swift Concurrency даёт структурированную асинхронность и безопасную модель доступа к разделяемому состоянию через actors. На практике это значит, что retry, auth, timeout, cache, logging и metrics лучше проектировать как часть контракта, а не как случайный набор if внутри одного большого send().
Если сжать статью до одного абзаца, получится так: я начинаю не с URLSession, а с вопросов кто имеет право знать о transport, где живёт policy, кто отвечает за retry, как не утечь токенами в логах, где source of truth для UI и как выяснить, что именно сломалось в production. Всё остальное — код вокруг этих решений.
Existential Container — одна из тех тем, которые регулярно всплывают на собеседованиях на middle и senior iOS-разработчика. Если понимать layout контейнера, проще объяснить несколько связанных тем: any vs some, Protocol with Associated Types, type erasure и стоимость protocol dispatch.
Статья построена в формате подготовки к собеседованию: сначала компактная шпаргалка с вопросами и ответами для быстрого повторения, затем детальный разбор с примерами и диаграммами.
Я перестал верить стримингам. Не философски, а практически. Половина любимых альбомов либо ушла из каталогов, либо вернулась пересведенной так, что слушать тошно. Концертные записи, винил-рипы, региональные релизы — их там и не было. А моя коллекция в FLAC просто лежит на диске и никуда не девается.
Для своей коллекции я написал плеер. Для себя. Через полгода это превратилось в нишевое приложение для iOS на 11 языках: с собственным DSP, распознаванием музыки, онлайн радио и CarPlay.
Что в итоге внутри и где было не очевидно. Места, в которых документация молчит, а ты сидишь и гадаешь, почему оно вообще так себя ведет.
Каждый раз, когда нужно добавить новую модель в проект, приходится писать буквально одинаковый код: с одинаковыми проверками, с одинаковыми корректировками, с одинаковыми Codable, с одинаковыми тестами.
Полагаю, вы тоже постоянно с этим сталкиваетесь, особенно при работе с текстом: почистить от лишних пробелов, убрать декоративные символы, привести к нужному регистру, сделать проверку на «не пусто» и так далее.
В этой статье рассказываю про собственные наработки, про то, как удалось существенно сократить бойлерплейт и улучшить читаемость кода.
За полтора месяца после релиза я добавил в свой iOS-апп 9 сетевых инструментов — и почти каждый оказался отдельной задачей: параллельный MTR, Path MTU на ICMP Echo, детект блокировок по SNI. Делюсь самыми интересными граблями и кодом.
«Что нового в Swift» — кураторский дайджест релизов, видео и обсуждений в проекте и сообществе Swift.
Для начала мы остановимся на некоторых локальных группах встреч, которые делятся контентом о Swift:
По всему миру локальные группы встреч и конференции объединяют разработчиков Swift, и некоторые из них появились даже раньше самого Swift! У многих есть каналы на YouTube, где они публикуют видео со своих мероприятий, так что вы можете подключаться удалённо. Давайте выделим несколько.
В мае на встрече SF Swift прошёл доклад Дэна Федермана «Agentify Your Swift Repo», в котором рассказывается о создании агента для CI и обратной связи при ревью кода. Swift Barcelona имеет своё представительство на YouTube, а некоторые группы, например новое сообщество MLX India, публикуют плейлисты мероприятий, включая недавний доклад об использовании MLX Swift в iOS-приложениях, который стоит посмотреть. Существует даже организованный сообществом YouTube-канал Swift Community Meetups, который проводит онлайн-встречи и содержит серию кросс-платформенных докладов о Swift.
Эти группы поддерживают разработчиков несколькими важными способами:
В крупных приложениях для iOS взаимодействие между компонентами зачастую оказывается сложнее, чем сам компонент. Сервис завершает операцию, координатор должен отреагировать, возможно, потребуется обновить несколько экранов, и передача каждой зависимости по всему дереву навигации быстро начинает казаться излишней «рутинной» работой. Внедрение зависимостей и управление состоянием по-прежнему имеют своё место. Шина (данных) событий предоставляет нам ещё один инструмент для слабосвязанных уведомлений, где прямое управление добавило бы ненужную сложность. Цель этого компонента проста: позволить одной части приложения публиковать событие, а другим частям приложения — подписываться на события определенного типа. Реализация сосредоточена на типовой безопасности, потокобезопасном хранении, автоматической очистке при деаллокации владельца, явной отмене отдельных подписок, доставке MainActor для кода пользовательского интерфейса и поддержке AsyncStream для потребителей async/await.
Разбираем очень неприятный баг в React Native + iOS: почему push-уведомления сохраняются на Android, но теряются на iOS в background/killed state. В статье обсудим как на самом деле устроены APNS, Notification Service Extension, App Groups и почему проблема вообще не в React Native. Будет интересно…
StillCore — лёгкое приложение для отслеживания энергопотребления, частоты, нагрузки, температуры и состояния батареи из строки меню macOS. Это анонс и небольшая история о том, как я его писал.
Я сделал приложение NeonDrift — живые обои для macOS на основе Metal-шейдеров. Для базовой работы не нужны сторонние библиотеки, Screen Recording или Accessibility-доступ. Только AppKit, MetalKit и SwiftUI.
В статье разберу как это устроено изнутри: от трюка с уровнями окон до шейдеров и упаковки в .app. Попутно расскажу про баги, которые я поймал в процессе — растянутую плазму на Retina, крэш при первом же запуске упакованного приложения, анимацию, которая сбрасывалась при каждом переключении Space, и фризы на втором мониторе при смене Space на основном.
Главная идея статьи не в том, чтобы сделать ещё один wallpaper app, а в том, чтобы показать как на macOS можно аккуратно совместить AppKit window management, Metal render loop и SwiftUI-настройки без приватных API — и где именно этот подход начинает трещать по швам.
Месяц назад я начал делать pet-приложение для государственных закупок: свайпай тендеры как в Tinder, видишь AI-скоринг заказчика — стоит ли вообще лезть. Для скоринга нужны данные обо всех контрактах заказчика. Источник один — ЕИС zakupki.gov.ru. И тут начались сюрпризы.
SOAP-API требует ЭЦП юр.лица — отвал на старте. FTP-сервер с XML-выгрузками закрыт с 1 января 2025. OpenData портал — красивый каталог датасетов, но без единой ссылки на скачиваемый файл. Часа три я экспериментировал и сдался.
Остаётся HTML-парсинг публичных страниц. Дальше всё интереснее: 44-ФЗ и 223-ФЗ имеют разную вёрстку, заказчик идентифицируется тремя разными форматами одновременно (real_inn / orgId / orgCode), а НМЦК и дата эл.акта приёмки лежат вообще не там, где подсказывает имя URL.
В статье — архитектура на Vapor + Redis + PostgreSQL, код канонизации ИНН, четыре грабли где я тормозил по нескольку часов, и реальные цифры: 128k+ строк контрактов в БД, ~340 уникальных заказчиков с полным скорингом, ~100ms средняя latency на feed-запрос.
Если кто-то знает легальный путь к данным ЕИС без ЭЦП юр.лица — буду благодарен в комментах. Может я что-то упустил.
