Госкорпорации и ведомства закупают планшеты и смартфоны на «Авроре» десятками тысяч штук. Минцифры держит ОС в реестре отечественного ПО, а методические рекомендации прямо называют её предпочтительной мобильной платформой для госорганов. Значит, привычный рабочий процесс сотрудника придётся переносить с Android и iOS на платформу с другим стеком, другим магазином приложений и другими правилами сертификации. Перенос «в лоб» не работает – Android-приложение на «Авроре» не запустится. Разберём, что это меняет для команды разработки.

Стек: Qt и QML вместо привычного Kotlin и Swift

«Аврора» построена на Sailright и использует нативный стек на C++ и Qt, а интерфейс описывается на QML. Это ближе к разработке десктопных кроссплатформенных приложений, чем к мобильной в её Android-понимании. Команда, которая годами писала на Kotlin или Swift, столкнётся с другой парадигмой: декларативный UI на QML, сигналы и слоты, ручное управление жизненным циклом.

Практический вывод: не рассчитывайте переиспользовать UI-слой. Бизнес-логику на C++ или на общем ядре частично переносят, но интерфейс пишут заново. Кросс-платформенные обёртки вроде Flutter официальной поддержки под «Аврору» не имеют, поэтому ставка на нативный Aurora SDK – это не выбор, а условие задачи. Закладывайте время на обучение команды и на освоение эмулятора из состава SDK – он заметно медленнее железных устройств.

Дистрибуция, сертификация и доверенная среда

В мире «Авроры» нет Google Play. Приложения распространяются через RuStore или, что чаще для ведомств, через закрытый корпоративный магазин и системы управления мобильными устройствами (MDM/EMM). Пакеты подписываются, а доступ к части системных API открывается только подписанным и доверенным приложениям – это вопрос не удобства, а соответствия требованиям ФСТЭК и регламентам конкретного заказчика.

Заранее уточняйте у заказчика класс защищённости и допустимый канал поставки. От этого зависит, какие разрешения вы вообще сможете запросить и через какую процедуру пройдёт приёмка. Сборку и подпись лучше встроить в CI с самого начала – ручная подпись перед каждой демонстрацией съедает время и порождает ошибки.

Интеграция с корпоративным контуром

Мобильный клиент почти никогда не живёт сам по себе. Он ходит в учётные системы, в СЭД, в каталоги документов. Если вы уже выстраивали документооборот без тяжёлого ECM, мобильный клиент станет ещё одной точкой входа в тот же контур и протоколы интеграции придётся проектировать с учётом ограничений «Авроры» по фоновым задачам и сетевым политикам.

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

Вывод

Разработка под «Аврору» – это не порт Android-приложения, а отдельный проект с нативным стеком, своей дистрибуцией и требованиями к сертификации. Закладывайте обучение команды, ранний CI с подписью пакетов и проектирование интеграций под ограничения платформы. Тогда мобильный клиент впишется в импортозамещённый контур, а не станет изолированным островом. Под эти ограничения и выстраивается разработка мобильных приложений для госсектора.