Разработка

Мобильное приложение или мобильная версия сайта

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

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

Главный барьер — установка

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

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

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

Что действительно даёт установка

Есть возможности, которые в браузере либо недоступны, либо работают заметно хуже. Именно они, а не имидж, оправдывают проект.

Push-уведомления. Прямой канал к человеку на экран блокировки. Для доставки, такси, записи, оповещений о статусе это ключевая функция. В браузере уведомления существуют, но их поддержка и поведение разнятся по платформам, а разрешение люди дают неохотно.

Работа без сети. Если пользователь работает в поле, на складе, в подвале или в поездке, приложение может хранить данные локально и синхронизировать их позже. Сайт в этой ситуации просто не открывается.

Камера, датчики, геопозиция. Сканирование штрихкодов и документов, фотофиксация, фоновое отслеживание маршрута, работа с Bluetooth-устройствами. Часть этого доступна в браузере, но с ограничениями, и как только требуется фоновая работа — только приложение.

Скорость и плавность при интенсивной работе. Если человек проводит в интерфейсе часы, разница в отзывчивости накапливается.

Иконка на экране. Прозаично, но существенно: приложение видно каждый день, сайт нужно вспомнить.

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

Когда достаточно адаптивного сайта

Обратные признаки столь же различимы:

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

Последний пункт недооценивают. У сайта версия одна и она всегда свежая. В приложении часть аудитории месяцами сидит на старой версии, и поддерживать приходится обе.

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

Во что обходятся две платформы

Здесь конкретных цифр не будет, но структура расходов важнее цифр.

  1. Две платформы — не один проект. iOS и Android различаются правилами интерфейса, механикой уведомлений, работой в фоне. Даже при общей кодовой базе часть работы делается дважды, и тестировать нужно на обеих.
  2. Устройства и версии. Android — это множество экранов и версий системы. Проверка занимает заметно больше времени, чем на сайте, где браузеров по сути несколько.
  3. Бэкенд всё равно нужен. Приложение — клиент. Данные, учётные записи, логика живут на сервере, и это отдельная часть проекта, не связанная с числом платформ.
  4. Публикация в сторах. Аккаунты разработчика с ежегодной или разовой платой, подготовка описаний и скриншотов, политика конфиденциальности, ответы на вопросы модерации. Проверка занимает время, и отказ по формальной причине — обычное дело.
  5. Обновления проходят ту же процедуру. Срочная правка на сайте выкладывается сразу. В приложении она проходит модерацию, а затем ждёт, пока пользователи обновятся.
  6. Требования платформ меняются. Новые версии систем, новые правила по разрешениям и данным. Приложение, которое год не трогали, может перестать пускаться в стор или сломаться на свежей ОС.

Разработка приложения — разовая трата, наличие приложения — постоянная. Если во втором бюджета нет, не стоит и первого.

Поддержка как постоянная статья расходов

Это та часть, которую регулярно забывают заложить, и именно из-за неё приложения тихо умирают.

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

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

Как решить в своей ситуации

Ответьте на вопросы честно, про текущее положение дел, а не про планы.

  1. Как часто человек будет открывать продукт? Ежедневно или еженедельно — приложение обсуждаемо. Раз в месяц и реже — нет.
  2. Есть ли в сценарии хоть одна вещь из списка возможностей: push, офлайн, камера, датчики, фоновая работа? Если нет — ответа «приложение» у задачи нет.
  3. Откуда придут пользователи? Если из поиска и рекламы, им сначала нужна страница. Приложение может появиться позже, для уже существующей базы.
  4. Есть ли у вас база клиентов, которой можно предложить установку? Приложение без такой базы ставить будет некому.
  5. Заложены ли деньги на поддержку на несколько лет вперёд? Если нет, проект закончится через год.
  6. Нужен ли обмен ссылками? Если пользователи пересылают друг другу конкретные экраны, веб удобнее.

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