Swift *

Ещё несколько лет назад разговоры об 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. Поэтому стоимость разработки повышает и сразу две команды делают одно и тоже.

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

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

Foundation Models в iOS 26: разбор фреймворка для on-device LLM

На WWDC 2025 Apple показала одну из самых недооценённых вещей презентации — Foundation Models Framework. Теперь iOS-разработчики получили доступ к системной языковой модели Apple буквально в несколько строк Swift-кода.

Без OpenAI API. Без интернета. Без отправки данных в облако.

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

Мы — разработчики Surf, Android и iOS команды: Светлана Сорокина, Антон Бояркин и Алексей Рябков. Когда начали работать с Бургер Кинг над трансформацией приложения, столкнулись с похожей историей. Поэтому мы решили переписать архитектуру так, чтобы разные подрядчики могли нормально работать вместе, а продукт — развиваться быстрее.

Разработка iOS-приложения для ручной съёмки на iPhone: ISO, выдержка, фокус, RAW, stop motion и попытка ограничить вычислительную обработку снимков. Описываю принцип работы приложения.

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

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

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

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

Продолжаю делать свое macOS приложение DynamicNotch. В последнем обновлении делал реализацию добавления обложки текущего воспроизведения на заблокированный экран.

Вообще‑то, я бэкендер последние лет 20, но недавно остался без работы (и AI тут не причём), решил «замутить» свой «стартап», пока ищу новую работу Java‑программиста. А заодно подтянуть новые технологии, поглубже изучить немецкий и английский и немного развеяться…

Писать приложения под iOS было моим хобби последние лет 10, и пару моих приложений до сих пор постоянно висят в топе в Российском AppStore, но это были всё «игрушки», а захотелось сделать что‑то взаправду стоящее, и так возникла идея написать лучшее (ни больше ни меньше) приложение для изучения языков с помощью аудирования. Точнее, товарищ подсказал идею. А ещё точнее — идея давно была реализована под Андроид, но аналогов под iOS нет, а очень хотелось. И мне, и товарищу:). Да и смартфона с андроидом у меня нет и никогда не было, не судите строго, но не люблю я вирусы и глюки.

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

Итак, идея есть, какие технологии использовать? В старых моих приложениях был UIKit, Realm/CoreData, и, сториборды. Не судите строго, я как бэкэндер тогда не знал, что использование сторибордов среди «трушных» айосников считается плохим тоном и плохой приметой. Но теперь‑то я решил использовать современные технологии! И выбрал такой стэк: SwiftUI, SwiftData, Speech Framework. Что касается последнего, то он вроде бы доступен ещё с iOS 10, но я решил, что технологии развиваются, и распознавание текста из аудио должно было бы сделать со времени iOS 10 огромный рывок вперёд. Но теперь я не так сильно в этом уверен, и об этом эта моя маленькая статья…

Да, монтирую видео очень давно, около 20 лет, и часто не хватает софта, чтобы что‑то быстро подправить или смонтировать на выезде, на ходу и даже в отпуске. Ноут далеко не всегда с собой, а вот iPad бывал частенько, и тогда в те времена года три назад очень не хватало софта нормального, какие‑то огрызки, на них разве что рилсики пилить. Несерьезно.

Основная претензия от меня как от профи — на всех приложениях, как правило, одна дорожка! Я решил написать редактор видео таким, каким я его вижу на мобильном устройстве.

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

Когда Apple добавила вырез (notch) в MacBook, реакция у многих была примерно одинаковая:

он есть — и с ним приходится просто мириться.

В отличие от iPhone, где появился Dynamic Island и вырез стал частью интерфейса, на macOS он до сих пор остаётся пассивным элементом. Он не несёт функциональной нагрузки и никак не взаимодействует с пользователем.

У меня возник простой вопрос:

а что если сделать вырез частью UI, а не ограничением?

Так появился проект DynamicNotch.

В 2024 году Google тихо убил Timeline в Google Maps. Историю местоположений перевели в «локальный режим», который на практике работает через раз - данные теряются, синхронизации нет, а у многих просто исчезли годы накопленной истории.

Для меня это было важно: я много езжу на машине и хотел знать простую вещь - сколько конкретная поездка стоит в бензине. Ничего подходящего не нашёл и решил написать сам. Я бэкенд-разработчик, до этого проекта не написал ни строчки на Swift - дальше про то, как за месяц вечерами собрал GPS-трекер с фильтром Калмана, fog of war на geohash и Live Activity.

От автора: Я до сих пор помню конец 90-х, когда установил на свой компьютер Internet Information Services. Это позволило мне запускать страницы Classic ASP, подключенные к базе данных Microsoft SQL Server. Так я впервые познакомился с серверной разработкой.

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

За годы работы я успел познакомиться с различными серверными технологиями, включая ASP.NET Web Forms, ASP.NET MVC, ExpressJS, Flask, Vapor, а теперь и Hummingbird.

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

Теперь можно писать на Swift в более широком спектре популярных интегрированных сред разработки, включая Cursor, VSCodium, Kiro от AWS и Antigravity от Google. Благодаря совместимости с расширениями VS Code эти редакторы напрямую подключаются к реестру Open VSX, где теперь доступно официальное расширение Swift.

Swift уже давно поддерживает разработку с использованием множества интегрированных сред разработки, включая VS Code, Xcode, Neovim и Emacs. Swift также совместим с редакторами, поддерживающими протокол Language Server Protocol (LSP). Эта растущая экосистема поддержки редакторов особенно важна, поскольку Swift продолжает демонстрировать свою универсальность на разных платформах и в различных средах разработки, включая агентные IDE.

Решение ошибки You do not have required role or permission to perform an operation при загрузке в TestFlight через Xcode

Столкнулся с ошибкой при отправке сборки в TestFlight из Xcode (впервые такое)

При этом:

✅ аккаунт в App Store Connect был владельцем

✅ все соглашения, налоговые формы и банковские данные были заполнены

✅ Bundle Identifier совпадал

✅ архив собирался корректно

Проблема оказалась не в правах App Store Connect, а в том, что в аккаунтах у меня было добавлено несколько учетных записей Apple ID. Из-за этого Xcode путался при работе с App Store Connect и при отправке сборки выдавал ошибку прав доступа.

Помог выпил из Xcode всех учеток кроме той, через которую выполняется публикация. 🔨