#видеозаписи

Открываем новую видеозапись выступления:
Анна Жаркова — Java-Swift interop vs Kotlin-Swift export. Путь к сингулярности

Доклад о различиях между новым инструментом для конвертации кода из Java в Swift и обратно и прямым экспортом Kotlin-Swift. Анна рассказала о том, как можно использовать эти решения на практике, как и когда их использовать в приложениях Android и iOS, в том числе через Gradle и SPM, и что лучше: натив или кроссплатформа.

😉 YouTube

Скачать презентацию с сайта Mobius

Новый релиз VibeStudio 0.0.7
https://github.com/AlexGladkov/VibeStudio/releases/tag/v0.0.7

👉 Добавил правую панель с поддержкой статуса изменений файлов (modified, uncommitted и тд)
👉 Исправлены мелкие баги
🔥 Появился новый режим - проекты CodeSpeak

CodeSpeak - это новый подход в разработке ИИ, представленный Андреем Бреславом (автор Kotlin), который предлагает программирование на английском. В целом, это spec-driven development, но специфический. Больше подробностей можете найти на сайте - https://codespeak.dev

👉 Появилась поддержка CodeSpeak проектов при открытии (открываются в отдельном режиме)
👉 Основные команды для сборки спеки, запуска и так далее
👉 Удобный FileTree для разделения спек и сгенерированных файлов

Как обычно если есть предложения - пишите в Issues

🔊 Новый регулятор громкости в ОС Аврора 5.2

В версии 5.2 появился обновленный регулятор громкости. Как и раньше, он настраивается под ситуацию: регулирует громкость уведомлений, звонков или разговора в зависимости от того, что вы делаете.

А теперь еще удобнее! В любой момент можно вручную отрегулировать каждый из четырех звуковых потоков отдельно:
🔹 звонок
🔹 уведомления
🔹 медиа (музыка, видео)
🔹 будильник — да, его громкость тоже регулируется независимо

🎥 Как это работает, показываем в нашем видео

📲 Аврора в MAX

🈲 Как LLM помогает миграции крупных проектов

🤝 Привет, это руководитель группы iOS-разработки Андрей Сикерин и разработчица Елизавета Мазулова. В Яндекс Браузере мы делаем приложение на iOS. Уже много лет в нашем сервисе шла миграция с Objective-C на Swift: это 10 тысяч файлов и сотни тысяч строк кода. А параллельно с миграцией мы продолжали развивать продукт.

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

⏭ В отличие от существующих инструментов-конвертеров, наша система с LLM понимает не только грамматику языка, но и архитектуру конкретного проекта. В её основе лежат четыре специализированных промпта:

🟠 Первый определяет оптимальный порядок миграции файлов, переписывает код и проверяет результат через компиляцию и тесты

🟠 Второй адаптирует код под лучшие практики Swift

🟠 Третий проводит автоматическую проверку по чек-листу: заголовки файлов, корректность замены типов, соответствие стандартам

🟠 Четвёртый очищает код от устаревших аннотаций, когда необходимость в них отпадает

За время работы над проектом мы полностью делегировали LLM рутинное переписывание кода. Разработчики только валидируют корректность миграции и занимаются сложным рефакторингом. В итоге затраты человеко-часов снизились примерно в 2,5 раза. Меньше чем за год мы влили 106 пул-реквестов в master, обработали 97 500 строк легаси-кода и 2167 файлов.

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

🎲 Читайте статью на Хабре, в которой мы подробно рассказали об архитектуре решения, контроле качества и устройстве промптов.

🎲 Найти наш опенсорс-инструмент можно на гитхабе или в SourceCraft.

Подписывайтесь:
💬 @Yandex4Mobile
📹 @YandexforMobile

🐥 Swift 6 краши при многопоточности
Если вам кажется что Swift 6 strict concurrency - это просто больше compile-time проверок - это не так. Часть проблем ловится уже в runtime, причём иногда прямо в production. Даже если проект собирается без warnings, Swift может вставить dynamic isolation checks на границах акторов и GCD. И если код ожидал один execution context, а приехал в другой — приложение упадет 😥. Чаще всего в crash reports это выглядит так:
_dispatch_assert_queue_fail
_swift_task_checkIsolatedSwift

Суть проблемы простая: closure или метод унаследовал actor isolation там, где был объявлен, а вызвали его потом из другого потока. Например, closure внутри @MainActor context может неявно стать main-actor-isolated. А потом вы передаёте её в context.perform у Core Data, который выполняет блок на своей private queue.
Где это особенно легко поймать:
🟢Core Data context.perform из @MainActor-кода
🟢Combine pipeline, где operator выполняется до receive(on:)
🟢NotificationCenter publisher, если notification прилетает с background thread
🟢delegate callbacks от SDK, которые не обещают main thread
🟢MainActor.assumeIsolated, если вы на самом деле не на MainActor
🟢actor methods, где после await состояние уже могло измениться из-за reentrancy

Практические правила:
🟢если Combine-operator должен работать на main — ставьте .receive(on: DispatchQueue.main) до него, а не после
🟢если closure не должен наследовать actor isolation — явно помечайте его @Sendable
🟢если delegate может прийти не с main thread — делайте метод nonisolated, а UI-работу отправляйте в Task { @MainActor in ... }
🟢не используйте MainActor.assumeIsolated как красивую замену await MainActor.run
🟢не рассчитывайте, что @MainActor на всём классе автоматически безопасен для всех callback’ов

Swift 6 начал громко показывать то, что раньше было скрытой проблемой:
🟡closure наследует isolation от места объявления, а не от места выполнения
🟡receive(on:) не спасает код, который уже выполнился до него
🟡delegate от системного SDK не обязан приходить на main thread
🟡билд без ворнингов не гарантирует отсутствие рантайм крашей из-за многопоточности
🟡после await внутри actor нельзя слепо доверять старому состоянию

Swift 6 concurrency — это не только про то, чтобы пофиксить warnings, это про пересмотр границ - где выполняется код, кто владеет состоянием и какой thread/actor реально вызывает callback.

🏝 JetBrains обновили дефолтную структуру KMP проектов. Теперь общий код живёт в shared модуле, а под каждую целевую платформу свой отдельный application модуль.

Раньше всё было в одном composeApp, который одновременно был и KMP библиотекой, и приложением. Это создавало путаницу в build конфигах и платформенных настройках. iOS при этом уже жил в отдельной папке, и асимметрия торчала наружу.

Главным триггером изменений стал Android Gradle Plugin 9, который больше не позволяет применять Android application plugin к multiplatform модулю. Entry point Android приложения теперь обязательно вынесен в отдельный модуль.

Если в проекте есть нативный UI (например, SwiftUI для iOS), shared разбивается на два модуля: sharedLogic без Compose зависимостей и sharedUI только для платформ с Compose Multiplatform. Для проектов с серверной частью добавляется server модуль и core с общими моделями и валидацией для шаринга между клиентом и сервером.

Я ещё до этого держал каждый application в отдельном модуле, так что для меня новая дефолтная структура лишь оформляет то что уже стало здравым смыслом. Раньше с одним shared было неприятно из-за того что Kotlin stdlib и зависимости тащились в каждый iOS framework. Несколько атомарных shared модулей решают эту проблему и позволяют точечнее управлять тем что попадает на каждую платформу. Очень рад что JetBrains двигаются в сторону более атомарных модулей, но пока есть вопросы не будет ли дублирования базовых Kotlin библиотека в каждый Xcode фреймворк.

Новая структура уже доступна в KMP wizard на kmp.new и в IDE плагине.

🔗 Анонс
📹 Видео разбор от JetBrains

#Kotlin #KMP #Gradle