Мобильное приложение для бизнеса: натив, кроссплатформа или PWA

Когда компания решает сделать мобильное приложение, первый технический спор почти всегда один и тот же: писать отдельно под iOS и Android, взять Flutter или React Native, или вообще обойтись PWA. У каждого варианта есть сторонники, и каждый в своей ситуации прав. Проблема в том, что выбор часто делают по принципу «так умеет наш подрядчик», а не по задачам продукта.

Ниже — честное сравнение подходов к разработке мобильного приложения для бизнеса: в чём сильные и слабые стороны нативной и кроссплатформенной разработки и PWA, когда что выбирать, и что нужно знать о публикации в App Store, Google Play и RuStore. Без религиозных войн — только критерии, по которым мы сами принимаем решение на проектах.

Сначала задача, потом технология

Прежде чем выбирать стек, стоит ответить на несколько вопросов. От ответов зависит больше, чем от любых сравнительных таблиц.

• Зачем приложение, если есть сайт? Повторные покупки, программа лояльности, push-уведомления, работа без сети, доступ к камере, геолокации, Bluetooth. Если ничего из этого не нужно, возможно, приложение не нужно вовсе.
• Кто пользователи и на каких устройствах? Клиенты массового сервиса, сотрудники на складе с корпоративными Android-терминалами, водители, партнёры.
• Насколько важна «нативность» ощущений? Для банковского или медийного продукта, где пользователь сравнивает вас с лидерами рынка, — критично. Для внутреннего инструмента учёта — второстепенно.
• Что с устройством? Сложная работа с камерой, AR, фоновая геолокация, интеграция с носимыми устройствами, низкоуровневая работа с сетью.
• Кто будет поддерживать приложение через два года? Своя команда, подрядчик, и какие у них компетенции.

Эти вопросы мы разбираем на первом этапе — исследовании аудитории и сценариев. Технологию выбираем после, а не до.

Стек выбирают по задачам продукта, а не по принципу «так умеет наш подрядчик».

Нативная разработка: максимум возможностей платформы

Нативное приложение пишется отдельно под каждую платформу: под iOS — на Swift, под Android — на Kotlin, с использованием родных инструментов и интерфейсных компонентов.

• Плюсы. Полный и быстрый доступ ко всем возможностям устройства и новым функциям ОС сразу после их выхода. Лучшая производительность в тяжёлых сценариях: сложная анимация, обработка видео, работа с камерой и сенсорами. Интерфейс ведёт себя ровно так, как привык пользователь платформы.
• Минусы. Две кодовые базы — значит, по сути две команды или два направления работы, и каждая функция делается дважды. Выше стоимость разработки и поддержки, сложнее синхронизировать релизы, чтобы версии на iOS и Android не расходились по функциональности.

Когда выбирать. Продукт, где приложение — основной канал и ключевое конкурентное преимущество; сложная работа с железом; высокие требования к производительности и плавности; большие ресурсы на долгосрочное развитие.

Кроссплатформенная разработка: Flutter и React Native

Кроссплатформенная разработка позволяет писать одну кодовую базу для iOS и Android. Два самых распространённых фреймворка устроены по-разному.

Flutter

Фреймворк от Google на языке Dart. Отрисовывает интерфейс собственным движком, поэтому приложение выглядит одинаково на всех платформах и даёт полный контроль над каждым пикселем. Хорошо подходит для продуктов с собственным выразительным дизайном, где не нужно точно повторять системные элементы iOS и Android. Ограничение — меньше специалистов на рынке, чем по JavaScript, и для специфических функций устройства иногда приходится писать нативные модули.

React Native

Фреймворк от Meta на JavaScript или TypeScript. Использует нативные компоненты платформ, поэтому интерфейс ближе к системному. Большой плюс — общий язык и часть логики с веб-разработкой: команда, которая делает ваш сайт или веб-сервис на React, может переиспользовать знания и часть кода. Ограничения похожи: для нестандартной работы с устройством нужны нативные модули, а обновления фреймворка и библиотек требуют внимания.

Где кроссплатформа проигрывает

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

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

PWA: приложение без магазинов

PWA (Progressive Web App) — это веб-приложение, которое можно установить на главный экран прямо из браузера. Оно умеет работать офлайн с закешированными данными и отправлять push-уведомления.

• Плюсы. Одна кодовая база для всех устройств, включая компьютеры. Не нужна публикация в сторах и прохождение их модерации: обновления доступны пользователям сразу. Открывается по ссылке, индексируется поисковиками. Если у вас уже есть веб-сервис, PWA часто можно сделать из него с относительно небольшими доработками.
• Минусы. Ограниченный доступ к функциям устройства, особенно на iOS: часть API недоступна, а push-уведомления там работают только для PWA, добавленной на главный экран. Пользователи не находят приложение в сторе и не всегда понимают, как его «установить». Для массового потребительского продукта это ощутимая потеря.

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

Как выбрать подход: короткая шпаргалка

Если свести три подхода в одну таблицу, разница выглядит так.

• Нужно проверить идею быстро и недорого — PWA или кроссплатформенный MVP.
• Типовое бизнес-приложение для клиентов — кроссплатформа: Flutter или React Native в зависимости от дизайна и компетенций команды поддержки.
• Есть веб-команда на React и общая логика с сайтом — React Native.
• Собственный насыщенный визуальный стиль и анимации — Flutter.
• Сложная работа с камерой, сенсорами, AR, фоновыми процессами — натив.
• Внутренний инструмент для сотрудников — PWA или кроссплатформа, в зависимости от того, нужен ли доступ к функциям устройства.

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

Что заложить в приложение с первого релиза

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

• Бэкенд и админка. Каталог, акции, тексты и push-рассылки должны управляться без выпуска новой версии. Иначе каждое изменение контента ждёт модерации стора.
• Аналитика и сбор сбоев. Без них вы не узнаете, на каком шаге пользователи бросают оформление заказа и на каких устройствах приложение падает.
• Принудительное обновление. Механизм, который попросит пользователя обновиться, если старая версия перестала работать с сервером.
• Глубокие ссылки. Чтобы ссылка из письма, рекламы или SMS открывала нужный экран приложения, а не главную.
• Удаление аккаунта и работа с персональными данными. Это требование сторов и закона, а не пожелание.

Состав первого релиза влияет и на бюджет. Чем точнее описаны сценарии и интеграции, тем точнее оценка.

Публикация в App Store, Google Play и RuStore

Публикация — отдельный этап, который часто недооценивают при планировании сроков.

• App Store. Нужен аккаунт в Apple Developer Program, лучше оформленный на компанию. Каждая версия проходит ручную проверку на соответствие правилам Apple. Частые причины отказа — недоработанный функционал, отсутствие возможности удалить аккаунт, неочевидные сценарии оплаты цифровых товаров, недостаточное описание сбора данных.
• Google Play. Модерация обычно мягче, но есть свои требования: декларация о безопасности данных, политика конфиденциальности, актуальная версия целевого API Android. Для новых личных аккаунтов разработчиков действует обязательное закрытое тестирование перед выпуском в продакшн.
• RuStore. Российский магазин приложений для Android. Для аудитории в России его стоит рассматривать как дополнительный канал дистрибуции наряду с Google Play. У RuStore свои правила модерации и собственные инструменты для платежей и push-уведомлений.

После публикации работа продолжается: обновления под новые версии ОС, исправление ошибок, развитие функциональности по данным аналитики. Для приложения принцип тот же, что и для сайта: заранее решить, какие действия пользователя считаются успехом, и отслеживать их как цели и события.

Частые вопросы

Что дешевле: нативная или кроссплатформенная разработка?

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

Flutter или React Native — что выбрать?

Flutter удобен для продуктов с собственным насыщенным дизайном и анимациями, так как сам отрисовывает интерфейс. React Native выгоден, если у компании уже есть веб-разработка на React и хочется переиспользовать компетенции и часть логики. Оба подходят для большинства бизнес-приложений.

Может ли PWA заменить мобильное приложение?

Для внутренних инструментов, сервисов для партнёров и проверки гипотез — часто да. Для массового потребительского продукта PWA проигрывает: приложения нет в сторах, на iOS ограничены функции устройства, а push-уведомления работают только после добавления на главный экран.

Нужно ли публиковать приложение в RuStore?

Если ваша аудитория в России и пользуется Android, RuStore имеет смысл как дополнительный канал наряду с Google Play. Публикация требует подготовки сборки под правила магазина и, при необходимости, интеграции его платёжных инструментов.

На кого оформлять аккаунты разработчика в сторах?

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