🔊 Новый регулятор громкости в ОС Аврора 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

🤖 Google анонсировала ADK for Android 0.1.0 вместе с ADK for Kotlin

ADK (Agent Development Kit) - это open-source фреймворк для AI-агентов, и теперь у него есть Android-артефакт с поддержкой on-device моделей.

Ключевая архитектурная идея: облачный оркестратор ведёт диалог с пользователем и координирует работу. Когда нужно обработать приватные данные - документы, брони, личные файлы - он делегирует subagent'у, который работает на устройстве через ML Kit GenAI и AICore. Данные за пределы устройства не уходят.

В стек входят LLM-агенты, sequential agents, MCP tools, session state и long-term memory через Memory service, OpenTelemetry для наблюдаемости.

Можно использовать три варианта моделей:
👉 ML Kit GenAI для on-device Gemini Nano
👉 Firebase AI Logic для облачного Gemini
👉 Google GenAI для быстрого прототипирования.

‼️ ВАЖНО: версия 0.1.0, статус "В активной разработке". Это очень ранний экспериментальный релиз, не для продакшна.

Архитектурный паттерн с разделением на облачный оркестратор и on-device агент выглядит разумно - именно так я бы и хотел видеть подобный инструмент. Но внедрять в прод рано.

🔗 Источник Android Dev Blog

#Android #AI #Gemini