Kotlin 2.4.20 упрощает передачу sealed-типов в Swift

В Kotlin 2.4.20 Swift Export получил поддержку sealed-классов и интерфейсов. Через sealedType() можно получить Swift enum и разобрать варианты в switch без default. Когда в Kotlin появится новый подкласс, компилятор поможет найти необработанную ветку.

Для XCFramework со SwiftPM-зависимостями задача assembleSharedXCFramework теперь генерирует Package.swift. Его нужно распространять вместе с фреймворком, чтобы зависимости корректно разрешались.

Инкрементальная компиляция klib перешла в Beta. Для проверки в своём проекте её включают через kotlin.incremental.native=true в gradle.properties; по умолчанию она пока не активирована.

В Xcode появился JSON-формат проекта

Добавление файла в старый project.pbxproj меняет несколько секций и создаёт новые идентификаторы. Когда два разработчика делают это в разных ветках, приходится разбирать конфликты в описании проекта.

В разборе нового формата Xcode 27.2 показан project.xcproj: файл описывается одной записью, а настройки сборки не приходится дублировать для каждой конфигурации. В примере автора 300 строк property list превратились в 123 строки JSON.

Переключение доступно в File inspector проекта. Перед миграцией нужно проверить версии Xcode в команде и инструменты, которые читают project.pbxproj напрямую: CocoaPods, XcodeGen, Tuist и собственные CI-скрипты.

SwiftFairy проверяет структуру SwiftUI-кода локально

Агент может знать правило и всё равно написать код, который ему противоречит. SwiftFairy разбирает Swift-код на Mac, ищет известные проблемные конструкции и через MCP возвращает замечания с привязкой к строкам и примерами исправлений.

Один из примеров — ForEach внутри List, где каждый элемент создаёт разное количество строк. Чтобы посчитать их, SwiftUI приходится вычислять содержимое для всех элементов коллекции, что замедляет длинный список.

Проверки сопоставляют структуру кода с заданными шаблонами. Сейчас есть наборы для SwiftUI, Swift Charts и современного Swift; найденное замечание стоит рассматривать вместе с контекстом конкретного экрана.

От чатбота к агентам: опыт Митчелла Хашимото

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

Так он выяснял, какие задачи можно поручать ИИ. Дальше добавлял инструкции в AGENTS.md, файл с правилами проекта, и способы проверить изменения, включая запуск тестов.

В истории освоения ИИ в разработке Хашимото связывает выбор задач с настройкой рабочего окружения. Отдельные чаты при этом остались в его повседневной работе.

#ии #инструменты

Почему KMP-код красный в IDE, но успешно собирается

Общий код KMP иногда видит платформенные объявления из зависимостей во время сборки, хотя IDE считает их недоступными. Из-за этого могут различаться выбранная перегрузка, выведенный тип и результат выполнения.

В Kotlin 2.5.0-Beta1 появилась экспериментальная отдельная компиляция. Она разрешает обращения из общих source sets по metadata KLIB, чтобы компилятор соблюдал те же границы, что и IDE.

Включается через kotlin.kmp.separateCompilation=true. Старые неявные обращения к платформенному коду могут перестать собираться: связь потребуется описать через expect/actual. Для проектов с C interop ещё остаются известные проблемы.

Как проверить SF Symbols до запуска приложения

Название иконки выглядит правдоподобно, но символа может не существовать или он появится только в новой iOS. В руководстве по CLI SF Symbols показано, как проверять это из терминала.

Команда search поддерживает точное совпадение имени, минимальную версию платформы и вывод JSON. Фильтр учитывает переименования: например, для iOS 13 вместо xmark.bin нужен bin.xmark.

Версии доступности различаются и по режимам рендеринга. heart.fill есть в iOS 13, а multicolor для него требует iOS 15. Проверку имени и нужного режима можно добавить в инструкции агенту, чтобы он сверял каталог перед созданием Image(systemName:).

Как собрать Swift-пакет через Gradle без CocoaPods

Kotlin/Native получает привязки к Apple-коду через cinterop, которому нужны C- или Objective-C-заголовки. У Swift-пакета таких заголовков изначально нет, а Gradle самостоятельно его не собирает.

В разборе SDK RevenueCat показана цепочка: SwiftPM описывает пакет, Gradle запускает сборку Swift, создаёт Objective-C-заголовок, статическую библиотеку и module map. Затем cinterop упаковывает привязки и библиотеку в klib.

Отдельная проблема — кеш. Изменение тела Swift-функции может не изменить заголовок, и cinterop пропустит обновление. RevenueCat добавляет хеш исходников в .def, чтобы изменения запускали задачу заново. У этого решения есть ограничения для зависимостей и конфигураций сборки.