Выбор архитектуры мобильного приложения определяет бюджет на годы вперёд, а не на спринт. Нативная разработка, кросс-платформа и PWA решают разные задачи, и подменять одно другим по принципу «так дешевле» – прямой путь к переписыванию через год. Разберём, когда какой подход оправдан в проектах для бизнеса и госсектора.
Три подхода и их цена владения
Нативная разработка (Kotlin для Android, Swift для iOS) даёт полный доступ к платформе: камера, биометрия, фоновые задачи, работа с защищёнными хранилищами. Платите за это двумя кодовыми базами и двумя командами. Берите нативный путь, когда приложение – основной канал работы с пользователем и нагружает железо: финтех, логистика со сканированием, полевые сервисы.
Кросс-платформа (Flutter, React Native) собирает обе платформы из одной кодовой базы. Экономия на старте реальная, но за неё расплачиваются зависимостью от фреймворка и его экосистемы. Здесь важно трезво оценивать vendor lock-in: смена мажорной версии фреймворка или уход библиотеки иногда обходится дороже, чем вторая нативная команда. Кросс-платформа хороша для типовых корпоративных приложений – каталоги, заявки, личные кабинеты, дашборды.
PWA – это веб-приложение, которое ставится на экран и работает офлайн через service worker. Распространяется по ссылке, минуя сторы. Для госсектора и B2B это часто решающий аргумент: не нужно проходить ревью Apple и Google, обновления выкатываются мгновенно, а на фоне ограничений с публикацией российских приложений в зарубежных сторах независимость от модерации становится стратегическим преимуществом. Платите за это урезанным доступом к аппаратным возможностям и более слабым офлайн-режимом, чем у нативного кода.
Что диктует выбор в госсекторе и B2B
Технология вторична – первичны требования к данным, распространению и устойчивости. Если приложение обрабатывает персональные данные, архитектура должна изначально учитывать защиту ПДн по 152-ФЗ: где хранятся данные, как шифруется локальное хранилище, что уходит на сервер. Это влияет на выбор сильнее, чем удобство разработчика: PWA с server-side обработкой проще аудировать, чем толстый нативный клиент с локальной БД.
Способ распространения тоже фильтрует варианты. Внутреннее корпоративное приложение можно раздать через MDM или PWA-ссылку без сторов вообще. Массовый продукт для граждан упирается в политику площадок и здесь PWA либо нативная сборка с альтернативной дистрибуцией снимают зависимость от чужих правил.
И backend никуда не девается. Мобильный клиент любой архитектуры бесполезен без устойчивого API. Закладывайте отказоустойчивость серверной части с первого дня: мобильные пользователи работают в плохих сетях, и приложение обязано переживать таймауты, повторы и деградацию сервиса без потери данных.
Как мы выбираем на практике
Мы начинаем не с фреймворка, а с трёх вопросов: какие аппаратные функции критичны, как приложение будет распространяться и какой класс данных оно обрабатывает. Ответы отсекают лишнее. Часто оптимум – гибрид: PWA для быстрого выхода и широкого охвата, нативный модуль там, где нужна камера или биометрия.
Поэтому архитектуру мобильного приложения мы проектируем под ограничения заказчика, а не под моду: сначала фиксируем требования к данным, распространению и аппаратным функциям, и только потом выбираем стек.
Вывод
Нет «лучшей» технологии – есть подходящая под задачу. Нативно – для нагрузки на железо, кросс-платформа – для типовых корпоративных приложений, PWA – для скорости и независимости от сторов. Решение принимайте от требований к данным и распространению, а не от стека.
