iOS *

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

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

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

В 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. 

В этом выпуске новинки WWDC26 - обновления в UIKit и SwiftUI, App Store, Xcode и Foundation Models. Кроме того, SMTP с нуля на сокетах и исследования RuStore, оптимизация Adapter и миграция навигации на Compose, один файл CLAUDE.md из 4 простых правил, который получил виральное распространение, мобильный рынок Ближнего Востока и многое другое. Заходите!

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

В данной статье мы ознакомимся с протоколами, по которым работает почта. Сфокусируемся на реализации протокола для отправки почтовых сообщений (SMTP) на низком уровне (BSD сокеты). И, используя собственный сетевой слой для работы с почтой, реализуем iOS клиент для отправки почтовых сообщений через любые почтовые провайдеры (ex: gmail, yandex, mail).

Я полгода улучшал продукт и почти не зарабатывал. А потом поменял не сам продукт, а только путь пользователя до оплаты — и внезапно появились годовые подписки.

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

В новом дайджесте победители Apple Design Awards 2026 и эффективность использования памяти в Android 17, обертки свойств в Swift и корутины на низком уровне, PWA после блокировки в App Store, игровая реклама 2026, дообучение LLM, метрики, практики, компромиссы и многое другое. Заходите!

Блокировки это одно. Их обходят: VLESS, Reality, прокси, про это уже написано много, в том числе у нас. Но есть сценарий жёстче. Интернета нет вообще. Не «YouTube не открывается», а мобильную сеть увели в ноль, Wi-Fi бесполезен, потому что аплинк перекрыт. Такое включают точечно: митинг, площадь, район, иногда целая страна на несколько часов.

Вопрос простой: могут ли два телефона в этой ситуации всё равно обменяться сообщением. Без вышек, без интернета, без сервера. Ответ: да, но честный ответ длиннее, и в нём много «но». Мы (команда из трёх человек, делаем мессенджер RCQ) собрали для этого режим, который называется Radio. Ниже что он реально умеет, чего не умеет, и какие грабли мы собрали по дороге.

Я мобильный разработчик. Иногда при работе со структурами данных я имею дело с endpoint-ами, иду в вики, нахожу страницу с описанием — и не верю ей. Потому что по опыту знаю: страница описывает API таким, каким он был задуман полгода назад, а не таким, какой он сейчас. Дальше начинается знакомый ритуал: пишу в чат бэкендеру, он отвечает «глянь в сваггере», сваггер сгенерирован из аннотаций и показывает приблизительную картину, реальный ответ с сервера от неё отличается, потому что правило сериализации живёт в одном месте, а правило генерации описания — в другом. В итоге я делаю то, что делает большинство клиентских разработчиков: дёргаю endpoint «вживую», смотрю реальный JSON и верю только ему. То же самое бывает и при работе с внешними API (в том числе и солидных компаний).

Это и есть проблема источника правды. У нас не один источник, а несколько, и они конкурируют. Вики — это намерение. Код бэкенда — это реализация. Реальный трафик — это факт. И когда между ними возникает расхождение (а оно возникает всегда), цена ошибки ложится в первую очередь на потребителя API: на фронтенд, на iOS, на Android, на десктоп, на внешних интеграторов.

Эту боль на Habr описывали многие. Алексей, Java-разработчик ЮMoney, в статье «Как улучшить межсерверное взаимодействие и сэкономить время разработчика» формулирует её предельно прямо: «Swagger UI, который генерируется автоматом по метаданным классов, показывает очень примерное описание того, что у нас реально отдаётся из API. Поэтому фронты и мобильные разработчики не могут начать разработку, не вызвав endpoint на живую». Это не чья-то личная неаккуратность — это структурный изъян процесса, в котором правда не централизована.

Я перестал верить стримингам. Не философски, а практически. Половина любимых альбомов либо ушла из каталогов, либо вернулась пересведенной так, что слушать тошно. Концертные записи, винил-рипы, региональные релизы — их там и не было. А моя коллекция в FLAC просто лежит на диске и никуда не девается.

Для своей коллекции я написал плеер. Для себя. Через полгода это превратилось в нишевое приложение для iOS на 11 языках: с собственным DSP, распознаванием музыки, онлайн радио и CarPlay.

Что в итоге внутри и где было не очевидно. Места, в которых документация молчит, а ты сидишь и гадаешь, почему оно вообще так себя ведет.

Каждый раз, когда нужно добавить новую модель в проект, приходится писать буквально одинаковый код: с одинаковыми проверками, с одинаковыми корректировками, с одинаковыми Codable, с одинаковыми тестами.

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

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

За полтора месяца после релиза я добавил в свой iOS-апп 9 сетевых инструментов — и почти каждый оказался отдельной задачей: параллельный MTR, Path MTU на ICMP Echo, детект блокировок по SNI. Делюсь самыми интересными граблями и кодом.

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

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

Друзья, всем привет. Это моя проба пера на Хабре. Меня зовут Максим Талалаев, я достаточно давно управляю людьми. Вот теперь занимаюсь этим в сфере IT. Делаю с командой проект по созданию и развитию платформы временной (гибкой) занятости.

Пишем на PHP. Используем Laravel и Lifewire с Filament. Базы на PostgreSQL. Приложения писали на Flutter, хотя в первое время нас здорово выручал самописный mini‑App в телеграм. В общем все, как у всех.

И вот недавно встал вопрос в загрузке приложений на известные всем площадки: GooglePlay, RuStore. На «десерт» мы оставили AppStore, так как мифов о нем ходило гораздо больше, чем о двух вышеупомянутых источниках. Я не буду подробно останавливаться на самой процедуре, по которой написано немыслимое количество статей и материалов,а сразу перейду к моментам, на которые лично у меня ушло больше всего душевных и временных терзаний, а также управленчески неэффективно потраченного времени (ну, это уже по завершении всех этапов так можно сказать. Конечно, когда я был в процессе, мне так не казалось.). Естественно, я прошел все стадии, начиная от «Создать аккаунт разработчика на организацию в России сейчас невозможно» до «А ты попробуй найти специализированное бюро, которое тебе для Apple корректно сделает перевод на иностранный язык».

Привет, Хабр! Меня зовут Константин Шкурко, я ведущий разработчик мобильных приложений в РСХБ. Сегодня хочу рассказать историю о том, как всем известные обстоятельства заставили нас в сжатые сроки искать альтернат­ивные пути доставки нашего инвестиционного приложения «Свои инвестиции» пользователям iOS - и как это изменило наш технологический стек.

Когда Apple заблокировала российские банковские приложения в App Store, перед нами встала непростая задача. У нас были десятки тысяч активных пользователей на iOS, которые пользовались брокерским приложением для управления своими инвестициями. Торговля акциями, облигациями, аналитика портфеля, выставление заявок - всё это внезапно стало недоступно для значительной части клиентской базы.

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

В крупных приложениях для iOS взаимодействие между компонентами зачастую оказывается сложнее, чем сам компонент. Сервис завершает операцию, координатор должен отреагировать, возможно, потребуется обновить несколько экранов, и передача каждой зависимости по всему дереву навигации быстро начинает казаться излишней «рутинной» работой. Внедрение зависимостей и управление состоянием по-прежнему имеют своё место. Шина (данных) событий предоставляет нам ещё один инструмент для слабосвязанных уведомлений, где прямое управление добавило бы ненужную сложность. Цель этого компонента проста: позволить одной части приложения публиковать событие, а другим частям приложения — подписываться на события определенного типа. Реализация сосредоточена на типовой безопасности, потокобезопасном хранении, автоматической очистке при деаллокации владельца, явной отмене отдельных подписок, доставке MainActor для кода пользовательского интерфейса и поддержке AsyncStream для потребителей async/await.

Разбираем очень неприятный баг в React Native + iOS: почему push-уведомления сохраняются на Android, но теряются на iOS в background/killed state. В статье обсудим как на самом деле устроены APNS, Notification Service Extension, App Groups и почему проблема вообще не в React Native. Будет интересно…

В этом выпуске продолжаем исследовать новинки I/O 2026 и переводить пользователей, прекращаем использовать .onAppear и лезем Gradle под капот, делаем приватность частью архитектуры, создаем систему привлечения пользователей, поднимаем Llama 3 в облаке и многое другое. Заходите!

Я сделал приложение NeonDrift — живые обои для macOS на основе Metal-шейдеров. Для базовой работы не нужны сторонние библиотеки, Screen Recording или Accessibility-доступ. Только AppKit, MetalKit и SwiftUI.

В статье разберу как это устроено изнутри: от трюка с уровнями окон до шейдеров и упаковки в .app. Попутно расскажу про баги, которые я поймал в процессе — растянутую плазму на Retina, крэш при первом же запуске упакованного приложения, анимацию, которая сбрасывалась при каждом переключении Space, и фризы на втором мониторе при смене Space на основном.

Главная идея статьи не в том, чтобы сделать ещё один wallpaper app, а в том, чтобы показать как на macOS можно аккуратно совместить AppKit window management, Metal render loop и SwiftUI-настройки без приватных API — и где именно этот подход начинает трещать по швам.

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

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

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

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

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