Swift *

Привет! Я Валерия Кудрявцева, iOS-разработчик в KTS. Пора поговорить о новинке.

9 сентября 2026 года Apple представила iPhone Duo, свой первый складной смартфон. Пока пользователи обсуждали новый форм-фактор, у нас, iOS-разработчиков, вопрос был другой: как поддерживать приложение на устройстве с двумя экранами и сгибом. Для нас Apple подготовила раздел HIG о проектировании под Duo, шесть Tech Talks и хаб Get Ready for iPhone Duo.

Статья основана на опубликованных Tech Talks Apple. Xcode 27.1 beta на момент подготовки ещё не вышел, поэтому возможности 27.1 описаны по презентациям. Проверить их на практике нужно после выхода SDK.

Сразу оговорюсь. По информации Apple, существующие приложения запустятся на Duo и без пересборки. Но адаптацию интерфейса это не отменяет: то, как приложение займёт внутренний дисплей и как поведут себя стандартные панели, зависит от SDK, с которым оно собрано. Различия разберу ниже.

Отдельный интерфейс под каждую pose Duo делать не нужно. А вот допущения в текущей вёрстке проверить придётся. Если код берёт доступное пространство из модели устройства или ориентации и считает отступы симметричными, на Duo такие расчёты дадут неверный результат. Основа остаётся одна: адаптивный UI, который смотрит на размер текущего окна и на size class.

Дальше разберу изменения iOS 27, что система сделает сама и что нужно править в коде, новые API 27.1 и типичные ошибки при аудите. В конце сравню подходы с Android foldable и расскажу, что из этого уже есть в Compose Multiplatform.

Случайно услышал на просторах интернета, что у Сбера, оказывается, есть открытая модель, которая по бенчмаркам русского языка бьёт Whisper, проверил, и понял, что она не просто не хуже, она работает мгновенно? да еще и на обычном процессоре, без GPU, а текст появляется быстрее, чем успеваешь отпустить кнопку

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

Что получилось и как работает:

Держишь правый ⌘ command, говоришь, отпускаешь, текст с пунктуацией и заглавными уже вставлен туда, где стоял курсор.

Замеры дали такие параметры: фраза на 6 сек вставляется за 0.08 сек, запись 30 сек транскрибируется меньше чем за полсекунды, а загрузка модели поднимается за 0,22 сек.

Все локально звук не покидает комп, сама модель весит 204 МБ, а приложение 32 мб и работает на процессоре, видеокарту не используем, код открыт, лицензия MIT, с названием мудрить не стал, раз пишет под диктовку, пусть будет Писарь

Почему Писарь, а не Whisper

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

GigaAM, на базе которого я собрал Писаря, обучена Сбером специально на русском, и на нём она заметно точнее, плюс расставляет пунктуацию и заглавные, английские вкрапления в русской речи (термины, названия) она тоже переваривает как надо.

Привет! Меня зовут Даниил, я iOS-инженер в Циане. В этой статье расскажу, как мы заставили XCUITest работать с экраном, к которому он в принципе не мог подойти.

У нас есть server-driven UI экран, наш BDUI, про движок которого была отдельная статья. Дерево вьюх у него настолько глубокое, что любое обращение теста к элементам падало. Причём двумя разными способами, и оба — не из-за кода, а из-за жёстких лимитов внутри самого фреймворка автоматизации.

В итоге мы научились читать дерево произвольной глубины и тапать/вводить текст в поля, которые лежат глубже ~60 уровней AX-дерева, где публичный XCUITest бессилен. Далее я буду фокусироваться на общей технике для XCUITest, а не на внутреннем устройстве нашего движка. Так что статья пригодится, даже если у вас никакого BDUI нет, а просто есть очень глубокий экран.

Привет, Хабр! (И тебе, 1С-ник, который открыл статью только чтобы убедиться, что пока точно не надо изучать новый продукт. И тебе, питонист, который сейчас будет морщиться. И тебе, мобильный разработчик, который уверен, что без Kotlin/Swift нормальное приложение не родится - держи кружку крепче.)

Эта статья будет посвящена технологии, на которой можно написать своё мобильное приложение за пару дней. И я вам на примере реализованного мною полноценного проекта логистического приложения покажу, что сейчас из себя представляет эта технология на нашей родной КИРИЛЛИЦЕ, и что на ней можно сделать прямо сейчас. И самое главное, как…

С системной функцией Picture-in-Picture (PiP) сталкивались, пожалуй, все владельцы iPhone: кто-то смотрит видео на фоне переписки, кто-то общается по видеосвязи в любимых мессенджерах. Для пользователя это просто удобство, а для разработчика видеосервиса — отдельный механизм со своей инфраструктурой, жизненным циклом и набором ограничений. В этой статье я разберу интеграцию PiP как встроенного плеера: от первого запуска до переключения контента. Поделюсь нюансами, с которыми вы точно столкнётесь на практике, и покажу, как обойти типовые грабли.

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

Практически каждый современный AI-агент, будь то Claude Code, Cursor, Codex, Gemini CLI или OpenCode, предлагает один и тот же механизм расширения своих возможностей - напишите Skill, опишите процесс решения задачи, добавьте примеры, подключите документацию и агент начнет выполнять эту работу значительно лучше.

Десятилетиями мы учили разработчиков, что Markdown - это документация. Средство общения между людьми. Формат, который не исполняется и никак не влияет на поведение программы, а затем неожиданно оказалось, что один Markdown-файл способен изменить проект сильнее, чем сотни строк кода и здесь индустрия практически мгновенно наступила на старые грабли.

У меня есть физический радар детектор — коробочка на стекле. И есть купленное приложение-антирадар. Что общего у них двух? В каждом чего-то не хватает. В одном не нравится одно, в другом другое. Годами я ловил себя на мысли, вот бы взять лучшее из обоих, а раздражающее просто не тащить.

В какой-то момент я перестал мечтать и сел писать своё. Наивно думая, что это несложно Ну что там, показывай точку из базы да пикай при подъезде. (Спойлер) Я ошибался почти в каждом своём предположении. Эта статья про то, как «тут же нечего делать» превратилось в фьюжн сенсоров, счисление пути в тоннелях, геодезию проездов и краудбазу с криптозащитой. И про то, чему меня научила каждая набитая шишка.

Flutter активно движется в сторону Swift Package Manager (SPM) и, как и весь Swift‑мир, постепенно отказывается от CocoaPods. Сам Flutter описывает миграцию в два шага: включить флаг flutter config --enable-swift-package-manager и запустить сборку. Если после этого приложение собирается и в консоли появляется предложение deintegrate CocoaPods — вы счастливчик. Если нет, добро пожаловать под кат. 

Привет! Меня зовут Даниил Гиренко, я Flutter‑разработчик в Яндекс Про. Проект по переводу нашего супераппа с CocoaPods на Swift Package Manager оказался одним из самых сложных и долгих в моей карьере программиста. Весь мой пережитый ужас опыт я решил выразить в этой статье, чтобы решившиеся на миграцию разработчики (или агенты) понимали, какие подводные камни их ждут. Буду рад, если ваш проект займёт недели, а не месяцы, как у меня.

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

Самая вычислительно прожорливая индустрия в истории считает на языке, который медленнее C примерно в 70 раз и занял 26-е место из 27 по энергоэффективности. Разбираемся, как Python стал королём ИИ, во сколько обходится его корона — в микросекундах, гигаватт-часах и удвоенном труде инженеров, — и почему новые территории (on-device, edge, локальный инференс) уже отвоёвывают компилируемые языки, в первую очередь Swift. С цифрами, ссылками на первоисточники и разбором честных контраргументов.

Если серьёзно — зависимостей у RuSwitcher действительно ноль: только системные фреймворки и чистый Swift, никакой телеметрии и ничего постороннего в Package.swift. Но начнём с боли.

Если вы пишете на двух языках, то знаете эту боль: набрал полстроки, поднял глаза — а там ghbdtn вместо «привет». На Windows эту проблему закрывает Punto Switcher. А на macOS? Его Mac‑версию Яндекс забросил ещё в 2017-м, да и у самого Punto хватает «сюрпризов»: встроенный кейлоггер‑«дневник», телеметрия, навязывание Яндекс‑сервисов и закрытый код. Мне хотелось простого, открытого и без слежки — поэтому я написал своё: RuSwitcher, лёгкий переключатель раскладки в меню‑баре. Open source (MIT), ноль зависимостей, ноль телеметрии.

В статье — как это устроено внутри: перехват клавиатуры через CGEventTap, динамический маппинг любых двух раскладок через UCKeyTranslate, и отдельно — раздел «грабли», включая историю про то, как я случайно выложил релиз, где DMG назывался 2.1.0, а внутри лежала сборка 2.0.3.

В мобильной разработке мы привыкли, что красивый анимированный фон — это либо видео, либо пара слоёв с CAGradientLayer и медленным параллаксом. Для большинства задач этого хватает. Но иногда хочется большего: настоящий живой космос — туманности, которые медленно перетекают друг в друга, планеты с кольцами, звёзды разных классов и в центре — чёрная дыра с аккреционным диском, как в «Интерстелларе».

У меня есть небольшая аркада-раннер про полёт сквозь космос. Фон там — не картинка, а процедурная сцена, которую целиком рисует фрагментный шейдер: каждый пиксель экрана вычисляется математикой из шума. Сначала всё это жило на SpriteKit, а потом я переписал на Metal — и вот тут началось самое интересное, потому что красивая сцена на десктопе и та же сцена на телефоне — это две очень разные истории.

Расскажу, как я это делал, на какие грабли наступил, и почему в итоге пришлось рисовать фон… полосками.

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

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

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

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

StillCore — лёгкое приложение для отслеживания энергопотребления, частоты, нагрузки, температуры и состояния батареи из строки меню macOS. Это анонс и небольшая история о том, как я его писал.

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

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

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

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

Почему?

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

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

Привет! Меня зовут Сергей, я тимлид iOS-команды в Банки.ру. В разработке уже 11 лет — успел поработать и на аутсорсе, и в продуктовых финтех-компаниях.

Если вы iOS-разработчик и планируете внедрять Live Activities в своё приложение — эта статья для вас. Особенно если обновления LA у вас триггерятся на бэкенде, а не в коде приложения. Мы наступили на несколько граблей, нашли неочевидное решение и хотим сохранить вам пару недель отладки.

Миграция большого 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-минутных дебаг-сессий, — добро пожаловать под кат!