Swift *

Разработчики из команды «Яндекса» выложили в открытый доступ первое решение на базе большой языковой модели (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 отличается в деталях. Это разные уровни логирования и возможности настройки логов. С помощью расширений можно создать несколько логгеров, отвечающих за логирование разного функционала.

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

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

У Apple оказалось так много всего интересного в экосистеме, что компания представила роадмапы (Pathways) по своим сервисам. Внутри каждого из шести направлений есть ссылки, где структурно представлена через документацию и видео-туториалы подробная база данных по необходимым библиотекам для разработчиков.

Apple выпустила документацию по работе с новым жестом сжатия Apple Pencil. Разработчики могут использовать его в своих приложениях. Вместе с этим добавили разделы документации по работе с вибрацией и двойным нажатием. Примеры кода доступны как для UIKit, так и для SwiftUI.

Жест сжатия работает только с Apple Pencil Pro, а сам стилус — только с iPad Pro (M4) и iPad Air (M2). Более подробно о функциях разных поколений Apple Pencil можно узнать из этой статьи.