Разработка · 5 мин чтения

Разработка мобильных веб приложений вместо нативных: когда это оправдано

Клиенты чаще всего приходят с запросом «сделайте приложение для iOS и Android», хотя по факту нужен канал продаж и push-уведомления, а не два отдельных билда в сторах. Разработка мобильных веб приложений в таких случаях закрывает задачу быстрее и дешевле: один код работает в браузере смартфона, обновляется без модерации в Google Play и App Store и ставится на главный экран как обычная иконка. Разбираю, по каким критериям выбирать между веб-версией и нативным приложением, сколько это стоит на практике и какие технологии реально работают на телефоне.

Чем мобильное веб-приложение отличается от нативного и от PWA

Мобильное веб-приложение - это сайт, спроектированный под сенсорный экран: крупные кнопки, нижняя навигация и логика, которая держит состояние без перезагрузки страницы. Обычно это SPA на React или Vue с бэкендом на Laravel или Node.js. PWA (Progressive Web App) - надстройка над таким приложением: файл manifest.json описывает иконку и цвет темы, а service worker кеширует ресурсы и даёт работать без сети. Нативное приложение - отдельный код на Swift или Kotlin, либо кроссплатформенный на Flutter или React Native, собранный под конкретную операционную систему и опубликованный в сторе.

На практике границы смазаны. PWA с рабочим service worker внешне неотличима от нативного приложения: открывается с домашнего экрана без адресной строки, шлёт уведомления на Android, работает в офлайне. Разница всплывает в деталях - доступе к железу, скорости первого запуска и правилах публикации.

Когда веб-приложение оправдано: сценарии из практики

  • Проверка гипотезы. Нужно быстро понять, будет ли спрос, прежде чем вкладываться в разработку под два стора. Веб-версию можно выпустить за 8 недель и менять функционал по фидбеку без ожидания ревью Apple.
  • Внутренние сервисы для сотрудников. Учёт смен, склад, заявки на отпуск - людям не нужно ничего ставить из стора, достаточно ссылки и авторизации. Делал такие панели на React с бэкендом на Laravel, с доступом по логину и роли.
  • Интернет-магазины и лендинги с оплатой. Оформление заказа с оплатой через T‑Bank или на WooCommerce работает в браузере не хуже, чем в приложении, а конверсия у веб-версии часто выше - меньше шагов до покупки.
  • Сервисы с аудиторией в Telegram. Если основной трафик уже приходит из Telegram, логичнее сделать Mini App или бота на aiogram, чем убеждать пользователя ставить отдельное приложение.
  • Частое обновление контента. Курсы, новости, каталоги - веб-версия обновляется мгновенно на всех устройствах, без ожидания публикации новой сборки в сторе.

Бесплатный материал

🎁 Полезный скрипт в подарок

Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.

Без спама. Отписка в 1 клик.

Сроки и стоимость: веб-приложение против нативной разработки

Разница в бюджете обычно и решает вопрос. Ниже сравнение по практике заказов и по рыночным ориентирам на нативную разработку.

Критерий Мобильное веб-приложение (PWA/SPA) Нативное приложение iOS + Android
Срок первой рабочей версии от 8 недель от 3-4 месяцев на платформу
Публикация по ссылке, без модерации ревью в Apple и Google, до 1-2 недель на каждый релиз
Поддержка двух платформ один код и один бэкенд два отдельных проекта или кроссплатформенный фреймворк
Push-уведомления на iPhone с iOS 16.4, после добавления на экран без ограничений
Доступ к камере, NFC, Bluetooth частично, через Web API полный

Разработку веб-сервиса или SPA с PWA-настройкой я оцениваю от 300 000 ₽, срок от 8 недель - сюда входит фронтенд, бэкенд и интеграции. На рынке нативная разработка под обе платформы у студий обычно стоит от 800 000 до 2 000 000 ₽, потому что по сути это два отдельных проекта с двумя циклами тестирования и отдельной публикацией в каждом сторе.

Технологии, которые делают веб-приложение похожим на нативное

Офлайн-режим и кеширование

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

Push-уведомления и ограничения iOS

Web Push API работает на Android и в десктопном браузере сразу после разрешения пользователя. На iPhone уведомления доступны только начиная с iOS 16.4 и только если сайт добавлен на экран через кнопку «Поделиться» - без этого шага Safari push не отправит. Для критичных сообщений, вроде статуса заказа или прибытия доставки через СДЭК, дублирую канал через разработку Telegram-бота на aiogram - его получают все подписчики независимо от версии iOS и настроек браузера.

Когда нативное приложение всё же лучше веб-версии

Есть задачи, где веб-версия проигрывает объективно:

  • Тяжёлая графика и игры - рендеринг на Unity или Unreal не заменить браузерным canvas без потери производительности.
  • Фоновая геолокация - трекинг курьера или пробежки, когда приложение свёрнуто, у веб-версии работает нестабильно из-за ограничений браузеров.
  • Постоянное сопряжение с Bluetooth-устройствами - фитнес-браслетами, кассовым оборудованием, медицинскими датчиками.
  • Требования корпоративного MDM - когда устройства сотрудников управляются централизованно и приложение ставится через закрытый корпоративный каталог.
  • Доверие аудитории - для банковских и финансовых сервисов присутствие в App Store и Google Play само по себе работает как сигнал надёжности.

Как я строю мобильное веб-приложение под задачу

Начинаю с того, какой канал уже приносит трафик и что должно происходить внутри приложения кроме просмотра контента. Дальше фронтенд на React или Vue, бэкенд на Laravel или Node.js, PWA-обвязка с manifest и service worker, интеграции под конкретную задачу - эквайринг T‑Bank, расчёт доставки через СДЭК, синхронизация с amoCRM или Bitrix24.

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

Если у клиента уже есть сайт на Tilda и нужно только добавить возможность поставить его на экран и кешировать страницы для офлайна, это комплексная доработка от 40 000 ₽. Полноценное веб-приложение с бэкендом и своей логикой - отдельный проект от 300 000 ₽ со сроком от 8 недель.

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

Подойдёт ли мобильное веб-приложение вместо нативного для интернет-магазина?

Для большинства магазинов - да, особенно если оплата принимается через T‑Bank или другой эквайринг, а доставка считается через СДЭК: эти интеграции работают в браузере так же, как в приложении. Отдельное нативное приложение имеет смысл добавлять, когда магазин вырастает и нужна программа лояльности с push-уведомлениями и офлайн-оплатой по NFC в физических точках.

Можно ли слать push-уведомления пользователям iPhone из веб-приложения?

Да, но с ограничением: работает начиная с iOS 16.4 и только если пользователь вручную добавил сайт на домашний экран через кнопку «Поделиться». Без этого шага уведомления на iPhone не дойдут, поэтому для важных статусов стоит держать запасной канал, например бота в Telegram.

Нужно ли публиковать мобильное веб-приложение в App Store и Google Play?

Нет, PWA открывается по ссылке или добавляется на экран напрямую из браузера, без стора и без ревью. При желании такое приложение можно завернуть в нативную оболочку через Capacitor или TWA и опубликовать в Google Play - ревью для такой обёртки обычно проходит быстрее, чем для полноценного нативного приложения.

Сколько стоит разработка мобильного веб-приложения?

Полноценный веб-сервис с бэкендом и PWA-настройкой я оцениваю от 300 000 ₽ при сроке от 8 недель. Если нужно добавить офлайн-режим и иконку на экран к существующему сайту на Tilda, это комплексная доработка от 40 000 ₽.

Есть задача?

Обсудим в мессенджере

Расскажите, что нужно сделать — отвечу в течение 4 часов в рабочее время. Первая консультация бесплатно.

Продолжая пользование настоящим сайтом Вы выражаете своё согласие на обработку Ваших персональных данных (файлов куки) с использованием Yandex.Metrika.
Понятно