ОС Аврора для разработчиков: разбор возможностей и подводных камней

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

Читать на Дзен
Читать на Workspace

ОС Аврора — российская мобильная операционная система, созданная на базе финской Sailfish OS. Разрабатывается с 2016 года компанией "Открытая мобильная платформа", дочкой Ростелекома.

Цель Авроры — создать защищенную мобильную платформу для государственных учреждений и корпораций. Система получила сертификат ФСБ и включена в реестр российского ПО. В данный момент одними из основных пользователей — Почта России, РЖД, министерства и крупные корпорации.

Техническая основа — Qt Framework с использованием языков QML и C++, что отличается от привычной Android-разработки на Java/Kotlin. Однако экосистема постепенно расширяется: доступна поддержка Flutter, позволяющая использовать Dart
и создавать приложения с единым кодом для Авроры и других платформ. Это особенно актуально для разработчиков, знакомых с Android или кроссплатформенными фреймворками.

В экосистеме уже около 100 приложений, преимущественно корпоративного
и государственного назначения.

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

Архитектурные отличия: Вместо императивного создания UI через код приложения строятся декларативно через QML. Нет привычных Activities и View Controllers — все базируется
на компонентах и их состояниях. Навигация реализуется через StackView и PageStack вместо Intent'ов и segue.

Системные API: Доступ к камере, GPS, уведомлениям происходит через Qt API, которые работают поверх Linux-сервисов. Вместо Android Services используются D-Bus демоны. Разрешения настраиваются через конфигурационные файлы, а не runtime запросы.

Процесс сборки: Отсутствует привычный Gradle или Xcode Build System. Используется qmake или CMake с Qt-специфичными настройками. Сборка происходит в виртуальных машинах, что усложняет CI/CD процессы.

Отладка: Нет аналогов Layout Inspector или Instruments. Отладка UI ведется через текстовые логи QML. Профилирование производительности доступно только через базовые Qt-инструменты.

Управление данными: SQLite работает через Qt SQL модули с другим API.
Нет ORM-решений уровня Room или Core Data. Сетевые запросы реализуются
через QNetworkAccessManager вместо Retrofit или URLSession.

Главное отличие — смена парадигмы с объектно-ориентированной мобильной разработки на компонентно-декларативную desktop-подобную архитектуру в мобильном форм-факторе.

Разработка под Аврору сопряжена рядом специфических сложностей, которые важно учитывать перед началом изучения платформы.

Главная проблема — крайне ограниченная экосистема. Готовых библиотек
и компонентов в десятки раз меньше, чем в Android или iOS, поэтому многие решения придется писать с нуля или адаптировать из Qt библиотек.

Документация существенно уступает стандартам Android и iOS. Официальные гайды часто поверхностны, примеры кода устаревают, а детальные технические спецификации недоступны. Разработчикам приходится методом проб и ошибок изучать особенности платформы.

Тестирование на реальных устройствах затруднено. Смартфоны и планшеты на Авроре стоят дорого, их сложно купить в рознице. Эмулятор работает медленнее аналогов
и не всегда корректно воспроизводит поведение реального железа.

Начать разработку под Аврору можно практически бесплатно — все основные инструменты распространяются без лицензионных ограничений. SDK Аврора, Qt Creator и эмулятор доступны для скачивания с официального сайта после простой регистрации.

Минимальные системные требования демократичны: большинство ноутбуков последних 5 лет с 8 ГБ ОЗУ и поддержкой виртуализации подойдут для разработки простых приложений.

Примечания:

• macOS (особенно ARM-чипы) официально не поддерживается;
• Docker используется для сборки, VirtualBox — для запуска эмуляторов;
• Поддержка ALT Linux актуальна, особенно в госорганизациях РФ.

Дополнительные инструменты зависят от специфики проектов. Для работы с государственными системами понадобятся средства криптографической защиты информации — они платные
и требуют сертификации.

Альтернативой локальной разработке становятся облачные решения, которые предлагает ОМП для корпоративных заказчиков. Разработчик получает доступ
к настроенной среде через браузер, но такой подход подходит только для работы
в рамках конкретного проекта.

У разработчика Авроры есть всего два реальных варианта: нативная разработка
на Qt Framework или кроссплатформенная на Flutter.

Qt Framework — единственный полностью поддерживаемый стек для серьезной разработки под Аврору. Все системные приложения, корпоративные решения
и сложные проекты создаются именно на Qt с использованием C++ и QML.

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

Для мобильных разработчиков платформа представляет значительные трудности. Кривая обучения крутая — C++ и QML кардинально отличаются от Android/iOS подходов. Время разработки увеличивается в 1.5-2 раза по сравнению с привычными мобильными фреймворками. Отладка сложнее, инструменты менее удобные. Частично проблему решает поддержка Flutter — можно использовать привычный фреймворк и портировать готовые приложения.

Flutter для Авроры доступен с августа 2023 года, но это не обычный Flutter
с официального сайта Google. ОМП портировала фреймворк специально под свою платформу, поэтому нужно использовать их версию.

Плюсы для мобильных разработчиков: знакомый Dart, привычная архитектура, возможность переиспользовать код с Android/iOS проектов. Можно быстро портировать существующие Flutter-приложения.

Минусы: доступны не все плагины и библиотеки, некоторые функции работают
по-другому. Производительность ниже нативного Qt. Зависимость от ОМП — новые версии Flutter выходят с задержкой относительно официальных релизов Google.

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

Основная сложность — гибридная природа системы. Аврора базируется на Linux,
но включает Android-совместимый слой, что создает архитектурную путаницу. Разработчик должен понимать, какие функции работают через Qt API, какие через Android-слой, а какие через нативные Linux-сервисы. Это требует более широких знаний,
чем разработка под "чистый" Android или iOS.

Системы управления состоянием работают по-другому. В отличие от Android с его четким жизненным циклом Activity, в Авроре приложения управляются через D-Bus и systemd. Для мобильных разработчиков это неожиданность — нужно изучать desktop Linux подходы для решения мобильных задач.

Ограничения безопасности серьезнее конкурентов. Каждое обращение к системным ресурсам требует явных разрешений, подписи сертификатами, соблюдения политик ФСТЭК. Архитектуру нужно планировать с учетом этих ограничений с самого начала.
Интеграция с корпоративными системами усложнена. Типичная задача — интегрировать мобильное приложение с 1С или другой ERP-системой заказчика. На Android это решается готовыми библиотеками, на Авроре приходится писать адаптеры с нуля
или использовать веб-сервисы.

Одним из ключевых вопросов для разработчика является производительность платформы и скорость разработки. Аврора показывает смешанные результаты
в этих аспектах.

Производительность:

• Qt обеспечивает стабильную работу на слабом железе
• Сложные интерфейсы с анимациями могут тормозить
• Игры и мультимедиа требуют серьезной оптимизации
• Для корпоративных CRUD-приложений производительности достаточно
• Производительность предсказуема, но не выдающаяся

Публикация в Aurora Store кардинально отличается от привычных Google Play
и App Store.

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

Многие заказчики требуют сертификат даже для внутренних корпоративных приложений. Эти расходы нужно закладывать в бюджет проекта с самого начала.

Требования к разработчикам жесткие. Нужно российское юрлицо, аккредитация в реестре разработчиков ПО, соответствие требованиям ИБ. Физлица и иностранные компании фактически исключены из рынка.

Реклама в приложениях практически невозможна — нет аналогов AdMob или Facebook Ads. Российские рекламные сети не интегрированы с Aurora Store.
Модель "бесплатно + реклама" не работает.

In-app покупки реализованы примитивно. Нет подписок, сложных тарифных планов,
A/B тестирования цен. Монетизация возможна только через прямые продажи приложений
или корпоративные лицензии.

Автоматические обновления работают плохо. Пользователи часто остаются
на старых версиях месяцами, что усложняет поддержку. Приходится поддерживать совместимость с 3-4 версиями API одновременно.

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

Продвижение приложений затруднено. В Aurora Store нет аналогов App Store Optimization, рекламных кампаний, featured-размещений. Популярность зависит только от word-of-mouth и прямого маркетинга.

Аналитика пользователей примитивна. Нет детальной статистики использования, воронок конверсии, когортного анализа. Сложно понять, как улучшить продукт
и увеличить retention.

Длительные циклы публикации убивают MVP-подход. Нельзя быстро тестировать гипотезы и итерировать продукт. Приходится тщательно планировать функциональность заранее, что увеличивает риски.

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

Многие разработчики обходят Aurora Store через корпоративные каналы.
Продают лицензии напрямую заказчикам, устанавливают через
enterprise MDM-системы. Это быстрее, но ограничивает масштабирование.

Некоторые используют веб-приложения вместо нативных — не нужна сертификация, быстрые обновления, простая аналитика. Но функциональность ограничена, производительность хуже.

Публикация в Aurora Store подходит только для долгосрочных проектов с большими бюджетами. Стартапы и MVP-продукты экономически нецелесообразны. Если планируете разработку под Аврору, закладывайте публикацию как отдельный этап проекта длительностью 1-2 месяца.

Разработка под ОС Аврора — перспективное, но одновременно сложное направление, ориентированное прежде всего на корпоративный и государственный сектор. Платформа существенно отличается от привычных Android и iOS — как технически,
так и организационно.

При этом у Авроры есть объективные ограничения: сложная архитектура, нестандартные инструменты, ограниченная экосистема, высокая цена входа
и публикации. Разработка требует больше времени, ресурсов и компетенций.
Механизмы распространения и монетизации упрощены, а скорость обновлений невысока.