Swift *

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

Это раздражало. Монтаж — это поток. Любая лишняя вкладка в браузере — как пауза посреди джазовой импровизации.

Поэтому в 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-запрос.

Если кто-то знает легальный путь к данным ЕИС без ЭЦП юр.лица — буду благодарен в комментах. Может я что-то упустил.

В прошлой статье я рассказывал, как мы встроили VLESS + Reality прямо в наше iOS-приложение через sing-box, чтобы обход блокировок был не задачей пользователя, а деталью реализации. Если коротко: TLS-рукопожатие проксируется на посторонний крупный сайт, активный пробинг упирается в этот сайт, IP относимся как к расходнику, конфиг доставляется отдельно от сборки. Подход работает, и для подавляющего большинства соединений из России работает прямо сейчас.

Кроме одного класса сетей, в которых не работал.

Внутри этого класса оказались, в том числе, корпоративные подсети, гостевой Wi-Fi в некоторых аэропортах и часть регионального покрытия одного из операторов. Картина в логах одна и та же. Туннель поднимается, TCP-соединение на relay открывается, TLS-рукопожатие начинается, и через секунду sing-box на сервере пишет в журнал: REALITY: processed invalid connection. Сразу обрыв, нет ретраев которые что-то меняют.

Эта статья про то, что мы увидели в этих сетях, почему Reality в одиночку их не пробивает, и что мы поставили рядом, чтобы пробивал. Если читали предыдущую часть, продолжайте отсюда. Если не читали, важен один тезис: туннель у нас живёт внутри приложения, через sing-box, скомпилированный в нативный фреймворк, без системного VPN.

Ещё несколько лет назад разговоры об iPad как полноценном инструменте разработчика воспринимались скептически. Машинка для Netflix, блокнот для набросков, планшет для презентаций — но только не рабочая среда для написания и деплоя кода. У этого скептицизма были основания: iPadOS долго не имела нормальной многозадачности, инструментов для работы с серверами почти не существовало, а необходимость постоянно переключаться между приложениями делала любой серьёзный рабочий процесс мучительным.

Сегодня картина изменилась кардинально, и сразу по двум причинам, которые усиливают друг друга.

Мы делаем мессенджер. Весной 2026 наш бэкенд начал отваливаться у части пользователей из России: HTTPS‑запросы к API таймаутятся, WebSocket не поднимается. Картина знакомая всем, кто держит сервис с одним доменом и одним IP.

Для мессенджера это приговор. Не «неудобно», а именно приговор: приложение, которое не может даже подключиться, бесполезно. И вариант «попросите пользователя сначала включить VPN» нас не устраивал совсем. Ниже разберу, почему мы в итоге встроили обход прямо в приложение, на чём он работает и на какие грабли мы наступили. Без маркетинга, по делу.

Я выпустил небольшое iOS-приложение — NetDiag+. Это набор сетевых утилит: ping, traceroute, DNS lookup, whois, LAN-сканер, port scanner, проверка SSL-сертификатов, BGP/ASN lookup, Wi-Fi info и фоновый мониторинг хостов с пушами при падении. Я начинал его как пет-проект для собственных нужд, потому что на iOS приходилось переключаться между четырьмя разными приложениями для базовой диагностики, и в трёх из четырёх была реклама.

Хочу поделиться тем, что мне самому хотелось бы прочитать в начале — почему некоторые вещи на iOS работают не так, как ожидаешь от Unix-фона, и где грабли лежат не там, где кажется.

Сразу спойлер по выводам: самым болезненным оказалось не сетевое программирование, а интеграция UMP-консента для AdMob.

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

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

Почему?

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

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

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

В этой статье я расскажу про:

·       Наш топ технологий

·       Как улучшить кибербезопасность в приложении

·       Последние функциональные тренды

Наш топ технологий

Swift – 5 звезд

Keychain и биометрия Face ID/Touch ID работают на уровне аппаратного шифрования, и разработчикам не нужно придумывать велосипед для защиты платежей. Swift дает производительность, идеальную работу с камерой для сканирования карт и чеков, и дает полный доступ ко всем API устройства.

Для банков важна не столько скорость разработки, сколько то, чтобы под каждую платформу были свои решения. Потому что Google или Apple могут что-то менять, и, допустим, в App Store потребуется внести обходы, дополнительные функции или модификации. Технически это можно сделать и на кроссплатформе, но если банк хочет поддерживать имидж и безупречную работу, ему нужно идеальное соответствие каждой платформе. Поэтому до сих пор во многих банках основная часть приложений пишется на нативе: для Apple — Swift, для Android — Kotlin.

Поэтому при использовании Swift компании нужно также иметь отдельную команду для разработки на Android. Поэтому стоимость разработки повышает и сразу две команды делают одно и тоже.