Swift *

Язык, с которым у ИИ плохо

В подкасте Радио-Т 1018 был интересный момент, что у ИИ сейчас гораздо меньше опенсорсных репозиториев и датасетов на Swift, чем условно на Python или Go. И поэтому, как Claude Code, так и Codex хреново пишут нативные iOS приложения. А ведь API языка обновляется, имеющиеся данные в нейронках устаревают с каждым WWDC.

Я как бэкендер с этой темой не сталкиваюсь. Стало интересно, как в Apple вайбкодят разрабы и влияет ли это как-то на темпы разработки по сравнению с конкурентами. Apple Intelligence пока пытались запустить для обычных потребителей, или когда анонсировали переход на Gemini-бэкенд, это повлияло как-то на пайплайн разработчиков? Есть ли у их моделей какой-то секретный проприетарный датасет, чтобы повысить качество работы с их экосистемой?

Мне короткий гуглеж выдал, что анонсировался Swift Assist в 2024, но в 2025 году от него отказались в пользу доступа к любым моделям с помощью API-ключей. То есть сама компания не может предоставить продакшн тулинг за счет доступа к самому большому в мире закрытому репозиторию Swift-кода. Получается, Apple со своей закрытой инфраструктурой не может оставаться верной своей концепции. В эпоху агентской разработки у компании не получается замыкать на своем решении инженеров, чтобы не уступать конкурентам.

Тут у меня котелок начал накидывать вопросы.

Apple ладно, а какое будущее у новых языков программирования? Будут ли авторы новых языков задаваться вопросом «как мой язык будут поддерживать нейросети?» Их популяризация будет целиком и полностью за счет опен-сорс коммьюнити теперь, пока остальные языки будут писать агенты? Сообщества сами генерят синтетические данные для языков программирования, чтобы локальные модели лучше умели в определенный скилл? Или может для языков будут сразу разрабатываться скиллы или MCP? Какую роль в адаптации к агентсткой разработке будут играть компилируемые языки со строгой типизацией по сравнению с нестрогими, скриптовыми языками? А поддержка нового языка агентами на сносном уровне, - это повод для флекса в презентации у компании?

В интересное время живем.

Представлен открытый инструмент Notchprompt, который прячет телесуфлёр прямо в «чёлку» MacBook. Во время видеозвонков текст подсказок выводится прямо в зоне камеры. Можно одновременно читать и смотреть в камеру без уводящегося взгляда и неловких пауз. Инструмент работает нативно на macOS, поддерживает приватный режим, гибкую настройку отображения и горячие клавиши для быстрого управления. Его уже используют для созвонов, презентаций и записи видео, где важно говорить уверенно и без потери структуры.

Вы попали в следующую ситуацию: граница, проверка, оператор просит разблокировать телефон. Отказаться нельзя или невыгодно. Что можно?

Стандартные ответы у мессенджеров слабые. Обычный app-lock PIN открывает то же приложение, под принуждением бесполезен. «Удалить аккаунт по PIN» лучше, но видно что что-то стёрто. Облачные TTL текущий запрос не закрывают.

В RCQ сделали по-другому. Локальная история шифруется AES-256-GCM, ключ выводится из PIN’а через PBKDF2-HMAC-SHA256 на 400к раундов с per-install salt в keychain. Разные PIN’ы открывают разные хранилища.

400к раундов это около секунды CPU на iPhone, достаточно медленно чтобы offline-bruteforce был дорогой. Но реальная защита это длина PIN’а: 4-значный перебирается за десятки минут на M-чипе, 8-значный за месяцы. Default 6-8 символов.

Четыре режима

1. Real PIN - открывает реальный аккаунт.

2. Decoy PIN - открывает отдельный аккаунт с собственным UIN и SQLite. Не пустой экран (пустой это сигнал), а правдоподобно освоенный: пара контактов, несколько сообщений.

3. Wipe PIN - тихо стирает оба SQLite, чистит keychain, дёргает DELETE /auth/account. Без подтверждений и прогресс-баров. Через 3 секунды приложение перезапускается как свежеустановленное.

4. Biometric - опциональная вторая дверь к real. Не совмещается с decoy/wipe (скорее для удобства).

Честно про границы

Защищает от: казуального осмотра, принуждённой разблокировки, ситуации «5 секунд до того как заберут».

Не защищает от: forensic-лаб с offline-bruteforce’ом короткого PIN’а, jailbroken устройства с активным debugger’ом, человека рядом который видел как вы вводите PIN (разумеется).

Threat model правильный: «есть несколько секунд до того как кто-то откроет приложение, дальше я не контролирую устройство». Для «forensic с неограниченным временем» нужны другие инструменты. Главное из них: не пользоваться телефоном для чувствительных переписок вообще.

Стек живёт в RCQ, открытая бета на iOS. Код открытый: github.com/rcq-messenger/rcq-ios. Про маскировку самого факта установки приложения будет отдельно.

Разработчики из команды «Яндекса» выложили в открытый доступ первое решение на базе большой языковой модели (LLM) для автоматизации миграции iOS‑проектов с Objective‑C на Swift, современный язык Apple. Оно особенно актуально для крупных проектов, накопивших сотни тысяч строк устаревшего кода. Решение ускоряет процесс миграции в 2,5 раза, позволяя разработчикам переключиться с рутинных задач на проверку качества.

Решение Migration toolkit for Swift разработано при миграции кодовой базы «Яндекс Браузера». Команда при переписывании кода столкнулась с целым рядом проблем: затраты времени и ресурсов, неизбежные при ручной работе ошибки, и всё это — при необходимости параллельно развивать проект. В результате за пять лет удалось сократить технический долг только наполовину.

Новый подход на базе LLM не только ускорил миграцию, но и позволил освободить разработчиков от монотонного переписывания кода — вместо этого они валидировали корректность миграции и выполняли сложный рефакторинг. За два месяца команда интегрировала 106 пул-реквестов, переписав около 97,5 тысячи строк устаревшего кода и более двух тысяч файлов. Обработка такого объёма данных вручную заняла бы больше года.

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

Готовые промпты автоматически подгружаются в контекст диалога в большинстве современных агентских IDE, поэтому решение совместимо с популярными инструментами для работы с кодом. Все промпты, скрипты и шаблоны проекта доступны на GitHub и SourceCraft.

Инструменты, которые упрощают iOS-разработку

Старый код усложняет рефакторинг, тесты в команде запускаются по‑разному, баги не воспроизводятся на хорошем Wi‑Fi, а после обновления инструментов локальная сборка начинает расходиться с CI — по отдельности все это мелочи, но именно они постепенно начинают тормозить разработку.

Ринат, iOS‑разработчик Naumen, рассказал об инструментах, которые помогают ему решать такие задачи и упрощать повседневную работу.

• Periphery: поиск мертвого кода в Swift‑проектах

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

Periphery помогает находить такие места и наводить порядок перед изменениями в кодовой базе.

Как использую

Запускаю Periphery перед рефакторингом — например, когда нужно обновить модуль профиля с сотнями файлов.

periphery scan

После сканирования инструмент показывает классы, методы, свойства, enum cases, imports и другие элементы. Так проще понять, что действительно участвует в работе приложения.

Что важно знать: результаты всегда нужно проверять вручную. Инструмент может не учитывать динамические вызовы, reflection, Objective-C runtime, storyboard-ссылки или код, который используется через строки.

• Network Link Conditioner: тестирование слабой сети

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

Network Link Conditioner — инструмент от Apple, который помогает эмулировать разные сетевые условия. Например, индикатор загрузки крутится бесконечно, повторная попытка не срабатывает, время ожидания слишком короткое, а пользователь не получает понятного сообщения об ошибке.

Как использую

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

Что важно знать: проверять стоит не только низкую скорость интернета, но и нестабильность сети. А еще важно не забывать выключать Conditioner после проверки :)

• just: короткие команды вместо длинных инструкций

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

just собирает основные сценарии работы в одном месте и запускает их через короткие понятные команды. В итоге justfile становится чем‑то вроде живой документации проекта.

Как использую

Чтобы каждый раз не вспоминать синтаксис, храню основные сценарии работы в justfile.

test:
    xcodebuild test -scheme MyApp -destination 'platform=iOS Simulator,name=iPhone 15'
format:
    swiftformat .
    swiftlint
clean:
    rm -rf ~/Library/Developer/Xcode/DerivedData

После этого вместо длинных команд достаточно написать:

just test
just format
just clean

Что важно знать: just не заменяет CI, Makefile или build system. Это скорее удобный слой для повседневных команд. Поэтому лучше держать justfile простым и не превращать его в большой набор скриптов.

• Mint: фиксация версий CLI-инструментов на Swift

Когда у разработчиков разные версии линтеров, форматтеров и других CLI‑инструментов, могут появиться расхождения. Mint помогает зафиксировать набор инструментов внутри проекта и сделать локальный запуск ближе к CI, чтобы у всей команды был одинаковый результат.

Как использую

Вместо глобальной установки SwiftLint, SwiftFormat, XcodeGen или других CLI‑инструментов можно хранить версии в Mintfile и запускать их одинаково у всех разработчиков.

mint run realm/SwiftLint
mint run nicklockwood/SwiftFormat

Что важно знать: Mint полезен именно для Swift CLI-пакетов. Для Ruby-gems, Node.js-инструментов или системных утилит понадобятся другие менеджеры. Также важно кэшировать установленные бинарные файлы в CI, иначе сборки могут тратить лишнее время на установку инструментов.

Представлен открытый проект PureMac для очистки Mac от мусора:

• сканирует и анализирует системные файлы;

• чистит кэш приложений, логи и остальной мусор;

• находит старые файлы;

• не ломает систему, не удаляет важные файлы;

• можно настроить очистку по расписанию.

Apple представила Swift Hypertext UI для вайбкодеров.

SwiftHUI новый декларативный язык разметки интерфейсов для iOS и macOS.

Никакого Swift. Никакого Xcode. Просто описываешь интерфейс словами.

vstack spacing=20
  text font=title "Hello, Vibe!"
  button action=tap "Do the thing"
/vstack

Переход на SwiftHUI будет безболезненным — вы уже умеете читать.

Apple позиционирует SwiftHUI как следующий шаг после SwiftUI: меньше кода и зависимости от инструментов. Работает даже в заметках.

What's new in Dub Dub — сайт, на котором собрали все анонсы WWDC с 2015 года. Есть вкладки по разным операционным системам Apple, списки аппаратных обновлений, фреймворков, API, интерфейса, версий Swift, Xcode, SF Symbols и других инструментов для разработчиков. Для фреймворков и API предусмотрели ссылки на страницы в официальной документации.

BPN vs MVM

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

В одном файле эта задача реализована в архитектуре BPN (Business Process Notation), о которой рассказывал раньше здесь. А во втором файле тот же код организован по архитектуре MVVM.

Код и в том, и в другом файле написан с помощью Claude Sonnet. В случае с BPN структурировал код вручную, следуя бизнес-процессам. А во втором случае попросил Клода сделать рефакторинг, используя традиционный современный подход и он выбрал MVVM.

Что можно сказать в итоге, сравнивая архитектуру в том, и другом случае. 

Объём кода

В BPN варианте 270 строки кода с комментариями, в MVVM - 524.

Т.е., в MVVM случае кода практически в 2 раза больше.

Количество сущностей, объектов.

BPN - один класс и 3 раширения к нему.

MVM - 6 классов, 1 структура, 3 протокола, каллбэки, фабрика, расширение.

Архитектура

BPN - монолит.

MVVM - вью и модель, анимация и аудио как сервисы, роутер, отдельная структура для хранения значений свойств и т.д.

Что лучше

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

В BPN нравится, что можно видеть модель процесса, в данном случае модель одной из задач приложения.

Что такое “Модель”

Наиболее традиционны 2 понимания термина “модель”.

В одном случае, это структура данных, модель объекта.

Например:

struct Person {

let firstName: String

let lastName: String

var age: Int

}

В другом случае, под моделью понимается всё, что не относится к интерфейсу.

Но есть и третье понимание модели - это модель приложения, или модель отдельных процессов внутри приложения. Т.е., составные части приложения (процесса) и их последовательность.

В BPN файле такая модель проступает наглядно:

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

В файале MVVM блоков кода гораздо больше и нужно несколько раз проскоролить чтобы увидеть их в выпадающем меню. И увидеть целостную модель здесь сложнее.

Conclusion

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

BPN позволяет видеть целостную модель задачи (процесса, приложения).

Императивное, декларативное и генеративное программирование.

Создатели фреймворка SwiftUI всегда подчёркивают, что он создан на основе парадигмы декларативного программирования. В отличие от предыдущего фреймворка UIKit, который характеризуется как пример императивного программирования.

Когда речь заходит о том, чем императивное программирование отличается от декларативного, то объяснение чаще всего сводится к тому, что при декларативном программировании разработчику нужно просто сказать, что ему нужно и SwiftUI это сделает. А если используется UIKit, то здесь типа надо все сделать самому.

Честно говоря, не очень внятное объяснение, поэтому попробую описать это различие сам на одном примере.

Итак, если в UIKit нам нужно вывести на экран список элементов, то мы используем TableView или CollectionView, которые уже подписаны на 2 протокола, а затем должны реализовать 3 метода: количество секций, количество строк в секциях, и в третьем методе скомпоновать ячейку и прописать загрузку в неё данных.

Та же задача в SwiftUI решается следующим образом:

List(items) { item in
Text(item.name) }

Т.е., меньше кода, меньше времени тратится на реализацию задачи.

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

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

Например, уже даже не надо писать команду List и т.д., а достаточно сказать ИИ "сделай список из таких-то элементов".

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

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

В итоге, получаем такую триаду:

• Императивное программирование

• Декларативное программирование

• Генеративное программирование

Опыт использования Claude для написания готового приложения

Ну вот и я сподобился - написал приложение полностью на Claude.

Приложение на SwiftUI, не enterprise, но достаточно сложное, из категории Favorite.

Начал на Claude Sonnet 3.7, потом вышел 4, закончил на нем.

Всего 1156 строк кода и без ошибок!

Естественно было несколько итераций. Причём практически все - это уточнение промта.

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

Как оно там внутри вертится крутится даже не смотрел. Главное - работает и этого достаточно.

В общем, впечатлён. Не ожидал. Предполагал, что будут ошибки, заторы, что придётся с ними разбираться. Ан нет, все зашло без глюков, с первого раза.

Конвертация книги Swift Programming Language в формат PDF и готовой к печати.

Поддерживается два режима рендеринга:
- Цифровой режим с гиперссылками для перекрестных ссылок между главами и внешними ссылками.
- Режим печати с номерами страниц, сопровождающими перекрестные ссылки между главами, и полными URL-адресами, отображаемыми в сносках для внешних ссылок.

https://github.com/ekassos/swift-book-pdf

VK (видео)

📦 API for Any(thing) 2

☝️Возможно ли создать интерфейс для получения любого объекта одинаковым способом? 

Библиотека работает на продакшене в приложениях:
Энергия
NFC Tool
КубГТУ

Во второй части доклада практическая реализация 💡

Хабр
Medium
GitHub

El-Machine.com Apps 🤖

Теория:
Часть 1

YouTube (видео)

📦 API for Any(thing) 

☝️Возможно ли создать интерфейс для получения любого объекта одинаковым способом? 

Продолжаю развивать свою идею архитектуры для 100% инкасуляции, разбития на модули и тестирования всего слоя Model

Хабр
Medium
GitHub

Первая часть доклада теоретическая. В поисках API для любого (Any) объекта

Во второй части доклада практическая реализация 💡

Поделитесь мыслями:
Что думаете про декларативны подход? Описываю результат и получаю нужный объект

Часть 2

Совместно используемая память в Swift и С/C++

Без прошлого нет будущего. Поэтому мы с заботой и любовью сохраняем наследие прошлого и используем проверенные инструменты в новых проектах. Благо, что разработчики Swift заложили возможность простого подключения библиотек, написанных на С, а с недавних пор еще и C++. 

В статье были описаны небезопасные указатели и их взаимодействие с объектами Си. Но не прозвучал один важный, на мой взгляд, вопрос: где выделяется память под совместно используемые объекты. Из документации и руководств по Swift мной была усвоена настойчивая рекомендация использовать вместо выделения памяти на стороне Си, функцию allocate класса UnsafeMutableRawPointer, там где это возможно.

let buf = UnsafeMutableRawPointer.allocate(byteCount: 128, alignment: 4)

Для того, чтобы Swift понимал содержание памяти, нужно сделать её привязку к поддерживаемому типу. Многие базовые типы Си поддерживаются через классы Swift с созвучным названием (CBool, CChar, CDouble, CFloat, CInt, CLong, CLongLong, CShort, CSignedChar, CUnsignedChar, CUnsignedInt, CUnsignedLong и т.д.).

let sbuf = buf.bindMemory(to:CChar.self, capacity:128)

Последовательность символов CChar воспринимается языком Swift как строка в стиле Си, которая поддерживается конструктором класса строк, что упрощает, например, вывод строк:

print(String(cString:sbuf))

Осталось только напомнить, что надо явно освобождать память буферов после использования с помощью функции deallocate:

buf.deallocate()

Спасибо за внимание!

Продолжаем разбираться с алгоритмами DFS и BFS.

В прошлый раз мы знакомились с тем, как работают алгоритмы поиска по N-деревьям. А в новом ролике Артур Михайлов, head of iOS в Технократии, показывает, как применять эти алгоритмы на практике.

Полезно как для тех, кто готовится к собеседованиям, так и тем, кто применяет алгоритмы в работе.

Разбираемся, как работают алгоритмы BFS и DFS. Конечно, в «Алгоритмической качалке»

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

Так что знания максимально полезные. Переходите по ссылке и не забывайте поставить лайк и написать комментарий — это очень помогает нам продвигать контент.

Как написать алгоритм работы «критического удара» для компьютерной игры

Нет, мы не начали внезапно заниматься геймдевом. Тренер «Алгоритмической качалки» Артур — давний фанат РПГ-игр, и ему интересно было разобраться в том, как работает такая механика, как «критический удар».

В новом ролике Артур покажет два варианта реализации алгоритма работы «крита». Переходите по ссылке, ставьте лайки и рассказывайте в комментариях свои идеи реализации.

Apple собрала все сессии WWDC 2024 на одной странице. Записи рассортировали по темам, чтобы разработчики сразу могли перейти к интересующему разделу. Страница доступна как на сайте Apple Developers, так и в фирменном приложении для разработчиков.

Виды логирования в Swift

Логирование — важный инструмент в арсенале разработчика. Оно помогает систематизировать сообщения, дает возможности фильтрации и многое другое. У Apple несколько основных инструментов для логирования.

Print — базовая функция, выводящая текст в консоль Xcode. Она часто используется для дебаггинга и неплохо справляется, когда решать приходится простые проблемы. В релизном коде Print оставаться не должен.

DebugPrint — очень похож на обычный Print, но отличается тем, что предоставляет дополнительную информацию о печатаемых объектах. DebugPrint имеет смысл использовать для дебага. Он покажет больше полезной информации о том, с каким типом объектов мы имеем дело. 

Dump — еще одна функция для распечатки сообщений в консоль. При работе с объектами и массивами объектов Dump показывает себя лучше, чем Print и DebugPrint. Мы получаем более наглядный результат, можем повлиять на то, в каком виде представлена информация, избавиться от лишнего «шума» в консоли.

OSLog — наш главный инструмент для ведения логов. Для этой функции мы передаем тип, название файла и название функции. Кастомизировать это можно как угодно.

Logger — более свежая альтернатива, доступная с iOS 14. Logger от OSLog отличается в деталях. Это разные уровни логирования и возможности настройки логов. С помощью расширений можно создать несколько логгеров, отвечающих за логирование разного функционала.

Подробнее о каждом инструменте — в нашем блоге.