Ко мне регулярно приходят с вопросом: делать нативное приложение или обойтись мобильной версией сайта. Разработка мобильного веб-приложения, то есть PWA, в большинстве проектов закрывает задачу бизнеса быстрее и дешевле нативной разработки под iOS и Android. Но не всегда. Ниже - критерии выбора между PWA и нативкой, состав цены и сроков, порядок работ и ошибки, которые я регулярно вижу на брифах.
PWA или нативное приложение: как выбираю под задачу бизнеса
Первый вопрос на брифе не «какой бюджет», а «что должно происходить на телефоне пользователя, чего нельзя сделать в браузере». Если ответ - каталог, форма заявки, личный кабинет, статус заказа, запись на услугу - хватает PWA. Если в сценарии обязательны постоянный доступ к Bluetooth-оборудованию, работа без сети часами подряд с последующей синхронизацией или биометрия как основной способ входа - без нативной разработки не обойтись.
Сравнение по реальным критериям, а не по ощущениям:
| Критерий | PWA | Нативное приложение |
|---|---|---|
| Публикация | сразу на своём домене, без модерации площадок | через App Store и Google Play, с проверкой правил |
| Push-уведомления | работают на Android всегда, на iOS - начиная с версии Safari 16.4 для приложений, добавленных на экран | работают на всех версиях системы без ограничений |
| Офлайн и фоновые задачи | кеш через service worker, фон на iOS ограничен политикой WebKit | полноценный фоновый режим и локальные уведомления |
| Bluetooth, NFC, биометрия | доступ ограничен или отсутствует в браузере | полный доступ через нативные SDK |
| Обновления | новая версия service worker ставится в фоне, а активируется, когда закрыты все страницы, работающие под старой версией, либо сразу, если новый воркер вызывает skipWaiting() | через сторы, пользователь обновляет вручную |
| Кодовая база | одна на все устройства | чаще две, либо кроссплатформенный фреймворк с нативными модулями |
Что реально умеет PWA-приложение уже сегодня
PWA - это обычный сайт с манифестом и service worker. Манифест описывает иконку, имя, цвет темы и режим отображения (в полноэкранном виде, без адресной строки браузера). Service worker кеширует статику и часть данных, поэтому приложение открывается и частично работает без сети. Минимальный манифест выглядит так:
<link rel="manifest" href="/manifest.json">{
"name": "Название сервиса",
"short_name": "Сервис",
"start_url": "/",
"display": "standalone",
"background_color": "#ffffff",
"theme_color": "#111111",
"icons": [
{ "src": "/icons/192.png", "sizes": "192x192", "type": "image/png" },
{ "src": "/icons/512.png", "sizes": "512x512", "type": "image/png" }
]
}На одном проекте заказчик пришёл с готовым техзаданием на нативное приложение для сервиса доставки, хотя по факту нужны были каталог, корзина, отслеживание заказа и push о смене статуса. Я предложил PWA: одна кодовая база под все устройства, push заработали и на Android, и на iOS - с версии Safari 16.4 у Apple появилась поддержка Web Push для приложений, установленных на экран. Бюджет и срок в итоге вышли кратно меньше, чем при разработке под два стора отдельно.
Когда без нативного мобильного приложения не обойтись
Есть сценарии, где PWA объективно проигрывает не потому, что «плохо сделана», а потому что браузер физически не даёт нужный доступ:
- Работа с внешним оборудованием через Bluetooth или NFC - кассы, весы, медицинские и складские сканеры
- Полевая работа без связи часами подряд с последующей синхронизацией больших объёмов данных - курьерские и складские приложения
- Биометрия как основной, а не дополнительный способ входа
- Корпоративное распространение через MDM для сотрудников, минуя публичные сторы
- Продукт, где присутствие в App Store и Google Play критично для узнаваемости бренда и органического трафика внутри самого стора
В таких случаях я обычно предлагаю гибрид: веб-приложение как основа плюс нативная обвязка через Capacitor для доступа к конкретным API устройства. Это дешевле полностью нативной разработки на двух платформах и даёт доступ к железу там, где он реально нужен.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Из чего складывается цена и сроки разработки мобильного веб-приложения
Цена не привязана к слову «PWA» или «нативка» напрямую - она собирается из объёма работы:
- Число экранов и сложность пользовательских сценариев - чем больше веток и состояний, тем больше тестирования
- Бэкенд: API, авторизация, база данных, интеграции с оплатой (например, эквайринг Т‑Банка), доставкой (СДЭК), CRM
- Дизайн - с нуля или адаптация готового макета под мобильные экраны
- Офлайн-логика и синхронизация данных при восстановлении связи
- Кроссплатформенность - одна кодовая база или отдельные нативные модули под iOS и Android
- Тестирование на реальных устройствах, а не только в эмуляции DevTools
- Публикация в сторах для нативной части - аккаунты разработчика Apple и Google клиент открывает и оплачивает сам
Сроки зависят от тех же факторов плюс от скорости обратной связи заказчика: если правки по дизайну и доступы к интеграциям приходят с задержкой в неделю, срок сдвигается ровно на эту неделю. У меня разработка мобильного веб-приложения под ключ стоит от 300 000 ₽ при сроке от 8 недель - сюда входят бриф, архитектура, дизайн, разработка фронтенда и бэкенда, интеграции и тестирование на реальных устройствах.
Что в эту цену не входит: оплата аккаунтов разработчика в App Store и Google Play (это отдельные платные программы самих Apple и Google, суммы и условия уточняйте в их актуальных правилах), создание контента, продвижение и оптимизация карточки приложения в сторе, техподдержка после сдачи - она у меня отдельная услуга.
Как проходит разработка мобильного веб-приложения: этапы и что нужно от заказчика
Порядок работ
- Бриф и аудит задачи - какие сценарии обязательны (камера, офлайн, платежи, push), а какие нет
- Архитектура - выбор между PWA, нативкой и гибридом, состав экранов и API
- Дизайн по референсам заказчика или с нуля
- Разработка фронтенда, бэкенда и интеграций
- Тестирование на реальных устройствах - разные iPhone, разные версии Android, разные браузеры
- Публикация: для PWA - деплой на домен и настройка manifest и service worker, для нативки - загрузка в App Store Connect и Google Play Console
- Передача проекта: код, доступы, документация по интеграциям
Что нужно подготовить заказчику
- Доступ к хостингу и домену
- Аккаунты и токены платёжных систем и служб доставки, которые подключаем
- Контент - тексты, фото, карточки товаров или услуг
- Референсы дизайна или готовый макет
- Ответственного за согласования на стороне бизнеса
- Тестовые доступы в CRM, если нужна интеграция
Частые ошибки при выборе между PWA и нативкой
- Выбирают нативку «для солидности» без реальной потребности в железе телефона - переплата и более долгий срок без выигрыша для пользователя
- Ждут от PWA функций, которых на iOS объективно нет - постоянной фоновой синхронизации или доступа к NFC-оплате в обход системных ограничений
- Тестируют только эмуляцией мобильного экрана в Chrome DevTools вместо реального iPhone - и потом ловят баги в офлайн-кеше и push, которые в эмуляции не воспроизводятся
- Считают, что публикация в сторе сама по себе даёт трафик - продвижение карточки приложения это отдельная работа, а не бонус от факта публикации
- Экономят на брифинге интеграций с оплатой и доставкой - потом эти доработки обходятся дороже, чем если бы их заложили в архитектуру сразу
Возможности PWA на iOS и ограничения самой платформы меняются с обновлениями системы, поэтому я проверяю их перед проектированием.
Частые вопросы
Чем PWA отличается от обычного мобильного сайта?
PWA - это сайт с манифестом и service worker, из-за которых браузер предлагает установить его на экран как отдельное приложение, кеширует часть контента для работы без сети и умеет присылать push-уведомления. У обычного мобильного сайта нет ни иконки на экране, ни офлайн-кеша, ни установки.
Можно ли PWA опубликовать в App Store и Google Play?
Технически да. Для Google Play это делается через Trusted Web Activity и работает стабильно. Для App Store сложнее - у Apple жёсткие требования к минимальной нативной функциональности, и приложение, которое фактически является витриной сайта без дополнительной ценности, модерация может отклонить. Возможность публикации в App Store я всегда проверяю на этапе брифа, а не постфактум.
Сколько стоит разработка мобильного веб-приложения под ключ?
У меня цена стартует от 300 000 ₽ при сроке от 8 недель - сюда входят бриф, архитектура, дизайн, разработка фронтенда и бэкенда, интеграции и тестирование на реальных устройствах. Итоговая цена зависит от числа экранов, сложности интеграций и офлайн-логики конкретного проекта.
Часть функций нужна не сразу, а через полгода. Закладывать сразу нативное приложение?
Обычно нет. Я стараюсь строить архитектуру так, чтобы можно было начать с PWA и добавить нативную обвязку через Capacitor под конкретные задачи, когда они станут реальными, а не гипотетическими. Расширять готовую кодовую базу дешевле, чем переделывать проект с нуля.