PWA, нативное или кроссплатформа: как выбрать подход к мобильной разработке

Содержание

• С чего начинается выбор: не с технологии, а с задачи
• PWA: когда сайт работает как приложение
• Нативная разработка: когда без неё нельзя
• Кроссплатформа: React Native и Flutter
• Сравнение подходов в одной таблице
• Критерии выбора для бизнеса
• Публикация и модерация в App Store и Google Play
• Аутентификация в мобильных приложениях
• Обновления и поддержка
• Что важно при заказной мобильной разработке
• FAQ

Запрос «нужно мобильное приложение» почти никогда не означает, что нужно именно нативное приложение из двух сторов. За ним стоит бизнес-задача: продавать, обслуживать клиентов в личном кабинете, дать сотрудникам инструмент на смартфоне, нарастить вовлечение. И вот здесь начинается развилка, на которой ломаются бюджеты: PWA, нативная разработка под iOS и Android или кроссплатформа на React Native либо Flutter.

Цена ошибки заметная. Мобильный трафик давно перевалил за половину всего веба — порядка 60% посещений сайтов идёт со смартфонов против 6% в 2011 году, десятикратный рост за полтора десятка лет. Но «много мобильного трафика» не равно «нужно нативное приложение в App Store». Иногда правильный ответ — обернуть существующий сайт в PWA за пару недель, а иногда — только нативный код спасёт производительность и доступ к железу. Разберём подходы по существу: где каждый силён, где проваливается и как выбирать под конкретный проект.

С чего начинается выбор: не с технологии, а с задачи

Главная ошибка — выбирать стек по моде или по тому, что знает знакомый разработчик. Правильная логика обратная: сначала фиксируем требования продукта, потом подбираем под них технологию.

Ключевые вопросы, на которые нужно ответить до старта:

• Нужен ли офлайн и насколько глубокий? Просмотр кэшированных данных — это одно, полноценная работа без сети с локальной синхронизацией — совсем другое.
• Нужен ли доступ к «железу»? Камера, Bluetooth, NFC, биометрия, фоновая геолокация, сканер документов — здесь у веба есть потолок.
• Какая производительность критична? Списки на тысячи элементов, анимация 60 fps, обработка видео, 3D, игры — это нагрузка, на которой веб-обёртка начинает заметно проседать.
• Нужны ли push-уведомления и насколько они критичны для бизнес-модели?
• Есть ли требование присутствия в сторах? Пользователи привыкли искать приложения в App Store и Google Play; для части аудитории отсутствие в сторе равно отсутствию доверия.
• Какой бюджет и срок? Две нативные кодовые базы — это почти всегда дороже и дольше, чем одна.

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

PWA: когда сайт работает как приложение

PWA (Progressive Web Application) — это веб-приложение, которое за счёт service worker, манифеста и набора браузерных API ведёт себя как нативное: устанавливается на домашний экран, открывается в полноэкранном режиме без адресной строки, работает офлайн на кэше и может показывать push (на Android — полноценно, на iOS — с ограничениями и только при установке на экран «Домой»).

Главная экономическая идея PWA: вам не нужно разрабатывать отдельно сайт, приложение под iPhone и приложение под Android. Достаточно поддерживать одну веб-кодовую базу. Для бизнеса с уже работающим адаптивным сайтом превратить его в PWA «довольно быстро можно сделать» — это вопрос недель, а не месяцев.

Где PWA реально выигрывает у приложений из сторов:

1. Индексируется поисковиками. PWA — это сайт, со всеми вытекающими для SEO. Нативное приложение в выдаче Google не появится.
2. Доставка обновлений — это просто деплой. Никаких сборок и прохождения модерации сторов. Выкатили на сервер — все пользователи мгновенно на новой версии. Первоначальная же выкладка приложения в стор «много нервов съедает».
3. Легче интегрируется в экосистемы — те же мини-аппы внутри мессенджеров и супераппов.
4. Раздаётся пользователю напрямую — по ссылке, без установки из стора. То, что собрано на React Native, ещё «умотаешься в стор запихивать», а PWA «просто так можно пользователю отдать».
5. Хорошо ведёт себя на слабых устройствах и плохом интернете — на рынках с дешёвыми телефонами PWA нередко показывает себя лучше тяжёлого нативного клиента.

Реальные сценарии, где PWA — правильный выбор: личный кабинет (например, кабинет пациента в клинике), внутренние бизнес-инструменты, каталоги и витрины, B2B-порталы, MVP для проверки гипотезы. Отдельный аргумент в российском контексте — независимость от политики Apple: регистрация новых аккаунтов Apple Developer для части компаний затруднена, и делать iOS-приложение означает «играть с Apple по их правилам, которые могут поменяться». PWA эту зависимость снимает.

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

Нативная разработка: когда без неё нельзя

Нативное приложение пишется на «родном» для платформы стеке: Kotlin (или Java) и Jetpack Compose под Android, Swift и SwiftUI под iOS. Это даёт максимум: полный доступ ко всем API устройства, лучшую производительность, самый гладкий UX и первыми — новые возможности ОС.

Нативная разработка оправдана, когда:

• Производительность — это сам продукт. Игры, графические и видеоредакторы, AR, тяжёлая обработка данных на устройстве.
• Нужен глубокий доступ к железу и системным возможностям: сложная работа с камерой, Bluetooth LE, NFC, фоновые сервисы, точная геолокация, виджеты, интеграция с системными функциями.
• UX должен быть идеальным и следовать гайдлайнам платформы до мелочей — там, где приложение является лицом бренда.
• Push-уведомления критичны для бизнес-модели и должны работать безотказно.

Цена — две независимые кодовые базы, две команды компетенций (или дорогие специалисты, владеющие обеими платформами), удвоенная стоимость поддержки. Поэтому нативная разработка под обе платформы с нуля — самый дорогой путь, и идти на него стоит осознанно, когда требования действительно его требуют. Если же критична только одна платформа (например, корпоративное приложение под парк служебных Android-устройств), нативная разработка под неё одну часто оказывается и быстрой, и недорогой.

Кроссплатформа: React Native и Flutter

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

React Native (Meta) — UI собирается на JavaScript/TypeScript и React, рендерится в нативные компоненты платформы. Главный козырь — экосистема и кадры: если в команде уже есть фронтендеры на React, порог входа минимален. Связка React + Next.js на вебе и React Native на мобиле позволяет переиспользовать и людей, и часть логики. Минус — мост между JS и нативным слоем исторически был узким местом производительности (новая архитектура с JSI это во многом снимает), а под нетривиальные нативные фичи всё равно нужны нативные модули.

Flutter (Google) — UI пишется на Dart и рендерится собственным движком, минуя нативные виджеты платформы. За счёт этого Flutter даёт очень стабильные 60+ fps, «рисуется быстро», пиксель-в-пиксель одинаковую картинку на iOS и Android и сильные инструменты разработки (DevTools, hot reload, предкомпиляция шейдеров). Цена — собственный язык Dart, который придётся осваивать, и то, что приложение не использует родные системные виджеты (для части заказчиков это плюс единообразия, для части — минус «неродного» ощущения).

Что выбрать из двух — зависит в первую очередь от команды и продукта. Грубое правило: есть React-команда и нужна тесная связка с вебом — React Native; нужна максимально гладкая собственная графика, сложный кастомный UI и предсказуемый рендеринг — Flutter. По чистой производительности фреймворки давно идут ноздря в ноздрю, и бенчмарки не дают однозначного победителя — разница чаще в архитектуре конкретного приложения, чем в самом фреймворке.

Отдельно стоит упомянуть Kotlin Multiplatform — подход, где общей делается бизнес-логика, а UI остаётся нативным на каждой платформе. Это разумный компромисс для команд, у которых уже есть сильная Android/Kotlin-экспертиза и которые не хотят жертвовать нативным UI ради общего кода.

Сравнение подходов в одной таблице

Критерии выбора для бизнеса

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

• Бюджет и срок. Минимальные — PWA. Ограниченные, но нужно приложение в сторах — кроссплатформа. Производительность и UX важнее экономии — нативная разработка.
• Офлайн. Нужен серьёзный офлайн с локальной базой и синхронизацией — нативное или кроссплатформенное приложение. Достаточно кэша для чтения — PWA справится.
• Доступ к железу. Нужны NFC, Bluetooth LE, сложная работа с камерой, фоновые сервисы — веб отпадает, остаются натив и кроссплатформа.
• Push. Критичны на iOS — это аргумент против PWA (там пуши ограничены) в пользу приложения в сторе.
• Производительность. 60 fps, тяжёлые списки, графика, видео — нативное либо Flutter; для большинства бизнес-интерфейсов хватит любого из подходов.
• Дистрибуция и доверие. Нужно быть в сторах и попадаться в их поиске — приложение; нужна индексация в Google и раздача по ссылке — PWA.

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

Публикация и модерация в App Store и Google Play

Здесь начинается то, о чём заказчики обычно не думают на старте, а зря: попасть в стор — отдельный проект внутри проекта. Чтобы опубликовать приложение, его нужно «обернуть в SDK платформы» — и там сразу всплывает всё: реклама, платежи, push. Первоначальная выкладка действительно «много нервов съедает», и закладывать на неё время нужно заранее.

Что важно учесть:

• Аккаунты разработчика. Apple Developer Program — 99 $ в год, Google Play — разовые 25 $. Для российских компаний регистрация новых аккаунтов Apple может быть затруднена — это иногда само по себе склоняет чашу весов к PWA или к публикации через партнёра.
• Сроки ревью. Google Play обычно пропускает приложение быстро (часы — дни), Apple ревьюит строже и дольше. Политика ревью Apple исторически считается жёсткой: команда модерации обладает большой властью, и это закладывалось в систему осознанно.
• Платежи. Если продаёте цифровой контент или подписки внутри приложения — будьте готовы к комиссии стора (исторически до 30%) и к требованию использовать встроенные покупки (IAP). Попытка показать пользователю «куда на самом деле уходят деньги» или увести оплату мимо стора — классическая причина отказа.

Типичные причины отказов, к которым стоит готовиться заранее:

1. Нарушение правил по платежам — обход IAP, ссылки на внешнюю оплату цифровых товаров.
2. «Тонкое» приложение — по сути обёртка вокруг сайта без добавленной мобильной ценности; Apple такие отклоняет особенно охотно.
3. Неполные метаданные и проблемы приватности — отсутствие или несоответствие privacy-описаний, запрос разрешений без объяснения зачем.
4. Навязчивый UX — например, запрос оценки приложения, который нельзя закрыть, или тёмные паттерны вокруг рейтинга.
5. Битые сборки и краши на устройстве ревьюера, недоступный тестовый аккаунт, неработающий функционал.
6. Несоответствие гайдлайнам контента — правила регулярно меняются, и то, что было разрешено в прошлом релизе, может оказаться запрещено в следующем.

Отдельная российская специфика: регуляторные требования к приложениям меняются, и под локальный рынок может потребоваться доработка (например, обязательная интеграция определённых сервисов). Это стоит держать в плане как риск, а не как сюрприз.

Аутентификация в мобильных приложениях

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

Базовая схема для большинства приложений:

• Токены, а не сессии. Сервер выдаёт access-токен (короткоживущий) и refresh-токен (долгоживущий). Приложение шлёт access-токен в каждом запросе и обновляет его через refresh, когда тот истекает. О различиях подходов мы подробно писали в разборе JWT vs сессии в Spring Security.
• Безопасное хранилище. Refresh-токен нельзя класть в обычные настройки — только в системное защищённое хранилище: Keychain на iOS, Keystore / EncryptedSharedPreferences на Android.
• Биометрия. Вход по Face ID / Touch ID / отпечатку — это не замена паролю на сервере, а локальная разблокировка доступа к уже сохранённым токенам. Удобно и безопасно при правильной реализации.
• OAuth 2.0 / OpenID Connect для входа через корпоративный SSO или социальные провайдеры; на мобиле используется поток Authorization Code с PKCE.

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

Обновления и поддержка

Жизнь приложения после релиза — это часто недооценённая статья. Модель обновлений сильно зависит от выбранного подхода.

• PWA обновляется деплоем: новый код на сервере — и все пользователи на свежей версии при следующем запуске. Никакой модерации, никакого «зоопарка версий».
• Нативное и кроссплатформенное приложение обновляется через стор, то есть каждое обновление снова проходит ревью (особенно у Apple). Плюс остаётся проблема пользователей, которые не обновляются годами, — бэкенд приходится держать совместимым со старыми клиентами.
• OTA-обновления (over-the-air) у React Native и Flutter позволяют доставлять часть изменений — прежде всего JS/Dart-логику — мимо стора. Это ускоряет правки, но не отменяет полноценные релизы для нативной части и не должно нарушать правила сторов.

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

Что важно при заказной мобильной разработке

Если вы заказываете мобильную разработку, на берегу стоит проговорить несколько вещей, которые потом определяют успех проекта:

• Начинайте с задачи, а не со стека. Хороший подрядчик сначала разберётся, нужно ли вам вообще приложение в сторах, или PWA закрывает 90% потребности дешевле и быстрее.
• Считайте полную стоимость владения, а не только разработку: публикация, аккаунты разработчика, поддержка двух платформ, обновления под новые версии ОС, реакция на изменения правил.
• Зафиксируйте, кому принадлежат аккаунты и исходники. Приложение должно публиковаться под вашим аккаунтом разработчика, а код — лежать в вашем репозитории. Это вопрос контроля над собственным продуктом.
• Закладывайте время на ревью сторов в план релизов — особенно для iOS.
• Думайте о бэкенде сразу. Мобильное приложение почти всегда — это клиент к серверной системе; аутентификация, API и данные проектируются вместе, а не вдогонку. Часто за мобильным приложением стоит полноценная заказная разработка ПО на стороне сервера.

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

FAQ

Можно ли PWA опубликовать в App Store и Google Play? В Google Play — да, через обёртку (Trusted Web Activity), это рабочая практика. В App Store «чистую» PWA Apple не пускает: нужна нативная обёртка, и она должна добавлять реальную мобильную ценность, иначе приложение отклонят как «тонкое». Поэтому, если присутствие именно в App Store обязательно, чаще выбирают кроссплатформу.

Что дешевле — PWA, кроссплатформа или нативная разработка? По возрастанию стоимости: PWA (одна веб-кодовая база), кроссплатформа (одна кодовая база плюс работа со сторами), нативная разработка под обе платформы (две кодовые базы). Но «дешевле» не значит «правильнее» — выбор определяется требованиями к производительности, железу и дистрибуции.

React Native или Flutter — что выбрать? Если в команде есть React-разработчики и важна связка с веб-фронтендом — React Native. Если нужна максимально гладкая собственная графика, сложный кастомный UI и предсказуемый рендеринг на обеих платформах — Flutter. По производительности они сегодня сопоставимы.

Почему приложение могут не пропустить в стор? Самые частые причины: обход встроенных покупок и комиссии, приложение-обёртка без добавленной ценности, проблемы с приватностью и разрешениями, навязчивый UX, краши на устройстве ревьюера. У Apple ревью строже и дольше, чем у Google.

Нужно ли отдельное приложение, если у нас уже есть хороший адаптивный сайт? Часто — нет. Если задачи бизнесовые (личный кабинет, каталог, портал), PWA поверх существующего сайта закроет их быстрее и дешевле. Отдельное приложение в сторе оправдано, когда критичны push на iOS, глубокий доступ к железу, максимальная производительность или само присутствие в сторах как канал привлечения.

Планируете мобильное приложение и не уверены, какой подход выбрать? Мы в Новакоме помогаем определиться на старте — от выбора между PWA, кроссплатформой и нативом до проектирования бэкенда и публикации в сторах. Посмотрите наши услуги по разработке мобильных приложений и заказной разработке ПО или напишите нам с описанием задачи — подскажем, что реально нужно вашему продукту, а на чём можно сэкономить.