Привет, это команда ОС Аврора.

У нас есть проблема, о которой не принято говорить в блоге вендора, но без неё вся эта история не имеет смысла. Про Аврору мы регулярно слышим одно и то же: платформа хорошая, но приложений мало, а переносить на неё уже готовые приложения с Android сложно и дорого. Пет-проект — ладно. Корпоративное приложение — тоже: их у нас уже много, просто они живут внутри закрытых контуров, и вы их не видите. А вот массовое приложение, которому для существования нужна миллионная аудитория, вроде бы обречено: никто не станет переписывать миллион строк legacy-кода ради новой платформы.

Дальше разговор обычно упирается в одну и ту же фразу: у нас всё нативное. Kotlin, Swift, годы накопленного кода, и переписывать это долго и дорого. Кроссплатформа есть далеко не у всех.

Тем, у кого она есть, нам уже давно есть что ответить: Flutter под Аврору поддерживается официально, Compose Multiplatform — тоже, и такие команды переезжают без драмы. А вот всем остальным мы до недавнего времени могли предложить только сочувствие.

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

Гипотеза

Формулировка была такой: если ИИ-агент действительно умеет переносить приложения между платформами, то главный экономический аргумент против новых мобильных ОС перестаёт работать.

Слабое место гипотезы лежит ровно в нашем огороде. Про Android и iOS модели знают всё, там миллионы строк примеров в обучающих данных. Про Аврору они не знают почти ничего. Именно это нам чаще всего и приводят как контраргумент: «вашей платформы нет в базе знаний нейросетей, значит ИИ вам не поможет».

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

Почему Алексей

Мы обратились к Алексею Гладкову, мобильному инженеру с 13-летним опытом, автору каналов @mobiledevnews и @alexgladkovblog. Выбор был не случайным. Алексей давно и предметно занимается агентными пайплайнами и сделал несколько собственных инструментов, включая MCP claude-in-mobile, который позволяет агенту физически взаимодействовать с устройством, и набор claude-code-agents.

Условия были простые: платформу выбираем мы, приложение выбирает он, в процесс мы не вмешиваемся, результат публикуем как есть.

Дальше по тексту цитатами идут его собственные комментарии. Приглаживать мы их не стали.

Приложение: Mattermost

Алексей выбрал Mattermost — опенсорсный мессенджер, мобильный клиент которого написан на React Native и местами дополнен нативным кодом на языке Java (и немного Kotlin). В проекте больше 220 тысяч строк.

Это опенсорс-продукт, а значит там куча всякого легаси и проблем. Плюс это мессенджер, поэтому там много разных плагинов, много технологий и сложная внутренняя архитектура. Проект выбран удачно.

Для нас в этом выборе было важно, что Mattermost не витрина. Внутри реальный код, который писали годами разные люди. Ровно тот случай, на который нам обычно и указывают.

Почему начали с Flutter

Для переноса можно было использовать и Flutter, и Qt. В первом эксперименте мы остановились на Flutter — прежде всего из-за готового набора инструментов и материалов для ИИ-агента.

Flutter для Авроры — официальный и хорошо документированный путь. На mos.hub опубликованы руководства и примеры корректной интеграции. Для эксперимента это оказалось критически важно: материалы можно передать агенту в контекст, и тогда модель не выдумывает устройство платформы, а опирается на актуальную документацию.

Для Qt под Аврору также доступны документация, референсные примеры и материалы по Aurora Controls и особенностям платформы. Они дают ИИ-агенту необходимый контекст для переноса и разработки приложений. Практическая применимость этого подхода уже подтверждена, в частности, переносом RustDesk на Qt под Аврору. Например, уже есть MCP-сервер с информацией по Авроре (и теперь можно легко уточнять нужные данные).

Первый заход мы сделали на Flutter: для него уже был готов удобный набор инструментов и примеров, подходящий для такого эксперимента. При этом Qt остаётся полноценным вариантом — выбор технологии зависит от исходного приложения и доступного контекста для агента.

Тулинг, который пришлось доделывать нам

Первое, обо что споткнулся эксперимент, — рабочее место. У Алексея macOS, как и у значительной части мобильных разработчиков. Аврора традиционно ориентирована на Linux.

Так совпало, что именно в это время мы выпустили полноценную версию Flutter Aurora SDK под macOS. Мы делали её как удобство для разработчиков и не рассчитывали, что она окажется условием, без которого весь сценарий не складывается.

Складывается он так. Чтобы агент работал автономно, ему нужна некая цель, которую он может проверить и достичь сам. «Приложение собирается и запускается на целевой платформе» — в данном случае цель была сформулирована таким образом. Без возможности собрать приложение под Аврору на своей машине разработчик остаётся с обходными путями:

Можно пойти хитрым путём и запускать Flutter-приложение под Android, чтобы сверить, что все экраны портированы. Но это не гарантирует запуска приложения именно под Аврору.

Второй инструмент — упомянутый выше claude-in-mobile. Он нужен по причине, которая показалась нам самой интересной технической деталью всего эксперимента:

Нейронка всегда недооценивает код. Если её спросить, всё ли перенесено, она посмотрит в исходники и скажет, что да. Живое устройство не даёт ей отлынивать, она вынуждена опираться на реальные данные.

Третий инструмент — специализированный агент под Аврору. Алексей собрал его, предоставив Claude доступ к нашей документации на mos.hub. Агент опубликован в открытом доступе и, по сути, стал главным практическим артефактом эксперимента — тем самым недостающим элементом базы знаний, которого нам давно не хватало.

На первой итерации агент не занимался ни архитектурой, ни красотой кода. Только перенос.

Как шёл перенос

Подготовка контекста. Для Android она не нужна, модель и так понимает, что от неё хотят. Для Авроры отдельный вводный промпт обязателен, иначе агент в процессе уходит в сторону. Это прямое следствие того, что нас нет в обучающих данных, и ровно та часть, которую мы со своей стороны хотим убрать. Подготовка должна жить в агенте-оркестраторе, а не в голове у разработчика.

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

Loop-разработка. Процесс делится на однотипные стадии, для каждой готовится чек-лист. Дальше агент работает часами. Ключевая инструкция звучала так: на каждой фазе сравнивать Android-сборку со сборкой под Аврору по экранам, а не по коду, до полного совпадения.

Гладко шло не всё. Честности ради приведём претензию, которая к нам отношения не имеет, но на процесс повлияла:

Claude Code, как бы точно вы ни описали ему видение результата, в какой-то момент всё равно остановит процесс и спросит, продолжать или нет. К этому надо быть готовым, той автономности, которая нужна, вам просто не дадут.

Финальная стадия: живое устройство

Иллюзия «агент закончил, значит работает» разбивается на первом же запуске. Финальным шагом был сквозной сценарий на реальном сервисе: залогиниться в Mattermost, написать в чат, пройти те же пути, что и на Android. Ради этого пришлось завести аккаунт на community.mattermost.com и отдать его агенту.

Результат: приложение перенесено, визуальный стиль сохранён, всё работает как обычное Flutter-приложение. Попутно нашлась пара багов в исходной Android-версии.

Из шероховатостей всплыл баг на macOS при нескольких подключённых мониторах. Иногда на эмуляторе приложение отображалось на 1/4 экрана. Мелкий, мы его уже правим.

Что этот эксперимент сказал нам о нас самих

Ради этого раздела всё и затевалось, поэтому здесь без корпоративного оптимизма.

Нам не хватает AI-ready-интерфейса. Это главный вывод, и он неприятный. Агент пока не может полноценно взаимодействовать с полями ввода, кнопками и другими элементами на Авроре. Ему нужен аналог Android Debug Bridge — низкоуровневая точка входа, поверх которой сообщество сможет строить инструменты вроде claude-in-mobile.

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

Работа в этом направлении уже активно ведётся. Мы прорабатываем AI-ready-интерфейс и необходимые инструменты, которые позволят агентам полноценно взаимодействовать с приложениями на Авроре, а разработчикам — использовать готовую инфраструктуру вместо того, чтобы каждый раз собирать её с нуля.

Часть Flutter-плагинов ещё не перенесена. Issues открыты, и закрыть такую задачу сегодня заметно проще, чем год назад, в том числе параллельно с переносом собственного приложения.

Подготовка контекста не должна быть заботой разработчика. Её место в оркестраторе.

Мы недооценивали важность локальной сборки. SDK под macOS выпускался как удобство, а оказался необходимым условием входа.

Релиз в RuStore

Приложение прошло публикацию в RuStore. Алексей так описывает путь публикации приложения под Аврору:

  1. Авторизоваться в RuStore.

  2. Получить сертификат разработчика под Аврору, которым подписываются приложения. На этом этапе также уточняются данные по ИНН.

  3. Загрузить сборки под 32- и 64-битную архитектуру.

  4. Заполнить карточку приложения. Если в нём есть авторизация, обязательно приложить тестовые данные: первую заявку отклонили именно из-за их отсутствия.

  5. Пройти модерацию.

По оценке Алексея, процесс отработал примерно на 95%, но видно, что пользуются им пока нечасто. Исправить это можно только практикой: чем больше приложений проходит этот путь, тем быстрее он шлифуется. Веб-админки для приложений под Аврору пока нет, поэтому карточку сегодня можно посмотреть только с устройства на ОС Аврора.

Первый фидбэк от скачавших есть. Мелкие недочёты нашлись, критичного нет.

Зачем мы это опубликовали

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

Что из этого не следует: что теперь любое приложение переносится на Аврору за вечер. Не переносится, и выше мы перечислили, чего именно для этого не хватает с нашей стороны.

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

Мы согласны и уже работаем над своей частью: AI-ready-интерфейсом, оркестратором с подготовленным контекстом и оставшимися плагинами.

Если возьмёте наш SDK, агента Алексея и перенесёте что-то своё, напишите нам. Интересен и успех, и особенно то, что не получилось.

Ссылки

P.S. «Зачем это всё, если Авроры нет в B2C»

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

Растём мы в B2B, и растём быстро. Госсектор, промышленность, транспорт, медицина, крупные корпоративные контуры. У этих заказчиков есть общая черта: у них уже написаны мобильные приложения, часто не одно, и написаны они годами под Android. Складские приложения, приложения для выездных бригад, внутренние мессенджеры, системы учёта. Когда такая компания приходит к нам, разговор почти никогда не начинается с чистого листа. Он начинается с фразы «у нас есть вот это, и оно нам нужно на Авроре».

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

Mattermost мы выбрали в том числе поэтому. Это корпоративный мессенджер с собственным сервером, то есть ровно тот класс продуктов, который сегодня и приезжает на Аврору чаще всего. Разница только в том, что он опенсорсный и результат можно показать публично, а не пересказывать под NDA.

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