Приложение или мобильный сайт: что нужно вашему бизнесу

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

Разница в деньгах есть, но она не главная: сайт от 250 000 ₽, приложение от 350 000 ₽. Главная разница в том, сколько стоит привести человека внутрь. На сайт он попадает по ссылке за секунду, в приложение - через магазин, установку, разрешения и регистрацию.

Разработка мобильных приложенийот 350 000 до 1 200 000 ₽сроки: 8-16 недель до релиза в сторах

Барьер установки

Между рекламным объявлением и первым экраном сайта - один тап. Между тем же объявлением и первым экраном приложения - переход в стор, страница карточки, кнопка «Установить», ожидание загрузки, открытие, запрос разрешений на уведомления, форма регистрации. Каждый шаг теряет часть людей, и потери там не проценты, а разы.

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

Отсюда простое правило: приложение имеет смысл, если частота возврата покрывает стоимость установки. Доставка еды, банк, фитнес-клуб с записью, сервис для сотрудников - покрывает. Установка окон, юридические услуги, продажа сложного оборудования - не покрывает и не покроет.

Что умеет приложение и не умеет сайт

Разница не в дизайне. Мобильный сайт можно сделать неотличимым от приложения по ощущениям. Разница в доступе к системе.

• Пуш-уведомления. Не «браузерные», которые на iOS почти не работают, а нормальные системные, с бейджем на иконке, звуком и доставкой при закрытом приложении. Это главная причина, по которой вообще делают приложения.
• Работа без сети. Локальная база, очередь операций, синхронизация при возврате связи. Сайт без интернета показывает динозаврика.
• Биометрия. FaceID и TouchID для входа и подтверждения операций. В вебе есть WebAuthn, но он про другое и разворачивается сложнее.
• Камера и файлы по-настоящему. Не «выбрать файл», а запись видео с контролем параметров, доступ к галерее, чтение HEIC, обработка медиа на устройстве.
• Фоновые задачи. Догрузка данных, отправка отложенных операций, геолокация в фоне.
• Иконка на домашнем экране. Самая недооценённая функция. Она бесплатно напоминает о вас каждый день, а закладка в браузере не напоминает никогда.
• Системные интеграции. Обработчик «Поделиться» из чужих приложений, виджеты, быстрые действия по долгому нажатию, NFC.

Если ни один пункт из этого списка вам не нужен, вы платите за иконку. Иногда это осмысленная покупка, но называть её надо своим именем.

Что закрывает PWA, а что нет

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

На iOS всё скромнее. Пуши в PWA появились, но работают только после того, как пользователь сам добавил сайт на домашний экран через меню «Поделиться», а это делают единицы. Фоновая работа ограничена: service worker живёт короткими сессиями, а не постоянно. Хранилище может быть очищено системой после долгого простоя. Доступа к биометрии, обработчику «Поделиться» и виджетам нет.

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

Приложение или мобильный сайт: сравнение по параметрам

Сравнение

Где кто сильнее

Шкала 0-100. Выше тот вариант, который сильнее по этому параметру.

А Мобильный сайт Б Приложение

0255075100

Стоимость входа

А 75

Б 45

перевес А на 30 Сайт от 250 000 ₽, приложение от 350 000 ₽ - выше тот, у кого порог ниже

Скорость запуска

А 85

Б 45

перевес А на 40 4-8 недель против 8-16 недель, и это без учёта ревью сторов

Охват новой аудитории

А 90

Б 25

перевес А на 65 В поиск человек приходит сам, в магазин приложений за незнакомым брендом - нет

Удержание постоянных

А 35

Б 85

перевес Б на 50 Иконка на экране и пуш возвращают, закладка в браузере не возвращает

Доступ к железу

А 30

Б 95

перевес Б на 65 Камера, биометрия, офлайн, фоновые задачи, NFC, виджеты

Стоимость привлечения пользователя

А 80

Б 30

перевес А на 50 Один тап против установки, разрешений и регистрации

Стоимость обновления

А 90

Б 40

перевес А на 50 Сайт обновляется деплоем за минуты, приложение проходит ревью и ждёт, пока обновятся пользователи

Обратите внимание на две крайние строки. Приложение выигрывает у сайта там, где человек уже ваш, и проигрывает везде, где его ещё надо привести. Поэтому приложение почти никогда не бывает первым каналом: его строят поверх работающего потока клиентов, а не вместо него.

Стоимость обновления - отдельная боль. Правку на сайте я выкатываю за минуты. Правку в приложении надо собрать, подписать, отправить на ревью, дождаться публикации, а потом ещё ждать, пока пользователи обновятся. Часть аудитории будет сидеть на версии полугодовой давности, и сервер обязан её поддерживать.

Когда приложение обязательно

Программа лояльности и регулярные покупки. Кофейня, доставка, барбершоп, аптека. Человек заходит еженедельно, пуш про акцию реально работает, карта лояльности живёт на экране, а не в кошельке.

Работа с железом на месте. Сканирование, фото с обработкой, NFC, офлайн. Тут показателен пример платформы событий и билетов, которую я делал целиком: продажа билетов, QR-контроль на входе, бонусы и лиги. Контролёр стоит на площадке, где связь пропадает регулярно, и должен сканировать билеты потоком. Сканер обязан работать без сети, помнить уже погашенные билеты локально, отбивать повторный скан и учитывать истёкший срок действия. Без приложения этот сценарий не собирается: браузер не даст ни надёжного офлайна, ни быстрого доступа к камере при сотнях сканов подряд.

Внутренний инструмент для сотрудников. Курьеры, монтажники, торговые представители, склад. Здесь установка не барьер: сотруднику приложение выдают вместе с работой, и вопрос стоимости привлечения не существует вовсе. Внутренние приложения окупаются лучше всех клиентских.

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

Когда приложение не нужно

Услуги с редкой покупкой. Ремонт, строительство, окна, мебель, юристы, медицинское оборудование. Человек покупает раз в несколько лет и не поставит ради этого ничего. Сюда же почти вся B2B-разработка с длинным циклом сделки.

Каталог с заявкой. Если функциональность сводится к «посмотреть товары и оставить телефон», приложение не добавляет ни одной возможности, зато отрезает весь поисковый трафик. Такой сценарий полностью закрывает мобильная вёрстка.

Лендинг и промо. Одна страница, один оффер, трафик из рекламы. Приложение тут выглядит как способ потратить бюджет.

Приложение «чтобы было». Самый частый запрос и самый честный отказ. Если вы не можете назвать, что человек будет делать в приложении на второй неделе после установки, приложения ещё нет - есть желание его иметь.

Третий путь

Между «сайт» и «приложение» есть вариант, который я обычно и предлагаю: сначала мобильный веб, потом приложение из той же кодовой базы.

Работает это так. Интерфейс пишется как обычное веб-приложение и запускается в браузере - его находят в поиске, он открывается по ссылке, обновляется деплоем. Когда становится понятно, что аудитория возвращается и пуши нужны, тот же код собирается в нативные приложения через Capacitor: веб-слой упаковывается в контейнер, к нему добавляются нативные возможности - уведомления, биометрия, камера, офлайн-хранилище. Там, где веба не хватает, дописываются плагины на Swift и Kotlin.

Так делалась и платформа событий, и мои прошлые проекты. Плюс подхода в том, что вы не платите дважды и не принимаете решение про приложение вслепую: к моменту решения у вас уже есть данные о том, сколько людей возвращается и как часто. Минус в том, что архитектуру надо заложить сразу, а не переписывать потом, - и это единственное решение, которое реально надо принять на старте.

Разбор конкретного сценария, оценку по экранам и честный ответ, нужно ли вам приложение вообще, я делаю на странице мобильной разработки. Если задачу закрывает сайт, я так и напишу - терять три месяца и полмиллиона на иконку, которую удалят, невыгодно нам обоим.