Webest 
Тендеры и лиды
Информация
Мобильные устройства год от года всё глубже проникают во все сферы жизни. Этот тренд уже давно очевиден и в ближайшее время вряд ли куда-то исчезнет. Поэтому многие компании, которые так или иначе связаны с IT, рано или поздно начинают задумываться о собственном мобильном приложении.
Обычно к этому моменту у бизнеса уже есть какой-то web-продукт. Интернет-магазин, личный кабинет, сервис для клиентов или B2B-портал. Чаще всего начинают именно с веба, что вполне логично: сайт проще запустить, его можно найти через поиск, пользователю ничего не нужно устанавливать.
А дальше появляется вопрос: может, пора делать приложение?
Прежде чем погружаться в муки выбора технологий, стоит разобраться, какие вообще есть варианты.
Если сильно упростить, приложения можно делать по трём основным сценариям.
Первый — PWA. По сути, это веб-приложение, которое определённым образом адаптируется под мобильное использование. Такой вариант позволяет реализовать часть привычных возможностей приложения без полноценной разработки отдельных клиентов под iOS и Android.
Второй вариант — кроссплатформенная разработка. Например, Flutter. Здесь мы делаем приложение сразу для iOS и Android, используя общую кодовую базу. В некоторых случаях можно использовать её и для web-версии. Для большинства обычных бизнес-задач возможностей такого подхода вполне хватает.
Третий вариант — нативная разработка. Swift для iOS и Kotlin для Android. Здесь всё понятно: отдельная разработка под каждую платформу.
Разница между этими подходами может быть существенной по стоимости и срокам. В зависимости от проекта она легко может составлять несколько раз. Поэтому выбирать технологию просто по принципу «вот это дешевле» я бы не стал.
Кроссплатформа и нативная разработка во многих проектах дают примерно одинаковый результат с точки зрения пользователя. Если вам не нужно реализовывать какие-то очень специфичные сценарии, связанные с аппаратными возможностями устройства или особенностями конкретной операционной системы, Flutter вполне может закрыть большую часть задач.
С PWA ситуация немного другая. Здесь нужно смотреть на roadmap проекта и понимать, куда продукт будет развиваться дальше. Пуши, отдельный мобильный интерфейс, работа с частью данных — многое можно реализовать. Но если через год проекту понадобится активно использовать камеру, NFC, Bluetooth, сложную офлайн-логику или другие возможности смартфона, первоначальная экономия может потом привести к дополнительным затратам.
На мой взгляд, этот вопрос стоит задавать ещё до того, как команда начала выбирать между Flutter, Swift и Kotlin.
Допустим, у вас интернет-магазин. Пользователь делает покупку раз в полгода, сайт нормально работает со смартфона, авторизация не вызывает проблем, заказ оформляется быстро.
Что изменится для этого человека после установки приложения? Возможно, ничего.
Другая ситуация — сервис, которым пользуются каждый день. Например, B2B-портал, где менеджеры работают с клиентами и заказами. Или доставка, маркетплейс, программа лояльности, корпоративная система, складское приложение. Здесь приложение уже может серьёзно упростить регулярную работу.
Поэтому я бы в первую очередь смотрел на частоту использования продукта. Чем чаще пользователь возвращается в сервис, тем больше шансов, что отдельное приложение окажется действительно полезным.
Есть хороший web — зачем бизнесу приложение?
Самый очевидный плюс — дополнительный канал коммуникации с пользователем. Push-уведомления позволяют сообщать о статусе заказа, напоминать о брошенной корзине, информировать об акциях или других событиях.
Есть и более простой момент — доступ к сервису. Пользователю не нужно каждый раз открывать браузер и искать нужный сайт. Приложение уже находится на телефоне, а часть привычных действий можно сделать быстрее.
В приложении проще проектировать интерфейс под конкретные мобильные сценарии. Не обязательно переносить туда весь функционал сайта. Можно оставить только то, чем человек действительно пользуется со смартфона.
Отдельный плюс — работа с возможностями самого устройства. Камера, геолокация, биометрия, NFC, Bluetooth и другие функции могут серьёзно расширить возможности продукта. В некоторых проектах без этого приложение вообще не имеет большого смысла, а в других именно такие сценарии становятся основной причиной его разработки.
Можно реализовать офлайн-работу с частью данных. Например, каталогом, историей заказов, документами или информацией, необходимой сотруднику для работы. Это особенно актуально для внутренних корпоративных систем, складских решений и сервисов, которыми пользуются вне офиса.
Но есть важный момент: само наличие приложения ещё ничего не гарантирует.
Если взять обычный сайт, перенести его в приложение и добавить иконку на рабочий стол, пользователи не начнут автоматически чаще покупать или активнее пользоваться сервисом. У человека должна быть причина установить приложение и оставить его на телефоне.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13735 тендеров
проведено за восемь лет работы нашего сайта.
1. Приложение — это ещё один продукт, который нужно постоянно поддерживать. Выходят новые версии iOS и Android, появляются новые устройства, меняются требования магазинов приложений. Всё это нужно тестировать и учитывать.
2. Отдельный вопрос — backend и API. Если текущий сайт нормально работает только через собственный frontend и API изначально не проектировалось для внешних клиентов, разработка мобильного приложения может потянуть за собой серьёзную доработку серверной части.
3. Есть публикация и модерация. App Store и Google Play имеют собственные требования, а правила периодически меняются. Обновление нельзя просто загрузить на сервер и через пять минут показать всем пользователям, как это обычно происходит с вебом.
4. Приложение ещё нужно продвигать. Пользователь должен узнать о нём, понять, зачем его устанавливать, и действительно это сделать. Если сервисом пользуются раз в несколько месяцев, убедить человека скачать отдельное приложение может быть непросто.
5. Ну и, конечно, есть стоимость разработки. Особенно если компания сразу идёт в полноценную нативную разработку и фактически создаёт два отдельных приложения — для iOS и Android.
При этом считать нужно не только стоимость первого релиза. У приложения есть дальнейшая поддержка, обновления, тестирование, развитие функционала и инфраструктуры. Первый релиз может быть только началом расходов.
Как я уже сказал, первый очевидный сценарий — высокая частота повторного использования. Пользователь регулярно возвращается в сервис, оформляет заказы, проверяет статусы, работает с информацией или выполняет другие действия.
Второй — необходимость быстро информировать пользователя о важных событиях. Статус заказа, доставка, бронирование или другие события, где своевременное уведомление действительно влияет на пользовательский опыт.
Третий — активное использование возможностей смартфона. Камера, геолокация, NFC, Bluetooth, биометрия, различные датчики. Например, для складского приложения, сервиса доставки или системы для сотрудников, работающих вне офиса.
Четвёртый сценарий — необходимость работать без постоянного подключения к интернету. Это может быть складской учёт, работа торговых представителей, карты или другие сервисы, которыми пользуются в местах с нестабильной связью.
И наверное самый важный момент — приложение должно давать пользователю заметное преимущество в привычном сценарии. Например, повторный заказ оформляется значительно быстрее, авторизация происходит через Face ID, нужные данные всегда доступны, а часть работы можно выполнять офлайн.
Если ничего из этого нет, я бы сначала внимательно посмотрел на веб-версию.
Когда компания решает сделать приложение и фактически переносит туда тот же каталог, те же страницы и те же пользовательские сценарии, то получается второй фронтенд, который нужно отдельно тестировать и поддерживать.
При этом пользователь не получает особой причины его устанавливать.
Если мобильное приложение отличается от сайта только иконкой на рабочем столе, возникает закономерный вопрос: зачем пользователю занимать память телефона?
Именно поэтому перед разработкой полезно посмотреть на roadmap продукта.
Что пользователь сможет делать в приложении такого, что в вебе делать неудобно?
Какие сценарии будут повторяться регулярно?
Как приложение изменит частоту покупок, возврат пользователей или стоимость обслуживания клиента?
Без ответов на эти вопросы обсуждать стек разработки немного преждевременно.
Однозначного ответа здесь не будет. Иногда приложение на 50 пользователей может быть абсолютно логичным и экономически оправданным решением. Например, если эти 50 человек каждый день работают через него и приложение экономит компании время или деньги.
И наоборот, можно иметь тысячи пользователей в день и не нуждаться в приложении. Количество пользователей само по себе мало что говорит о необходимости отдельного мобильного продукта.
Я бы сначала попытался определить, за счёт чего именно компания рассчитывает получить эффект. Вырастут повторные продажи? Сократится время работы сотрудников? Станет меньше ручных операций? Пользователи будут чаще возвращаться в сервис? Снизится стоимость обслуживания клиентов?
После этого уже можно считать затраты на разработку и поддержку. Причём смотреть не только на стоимость первого релиза, а хотя бы на горизонт нескольких лет.
Если предполагаемый эффект перекрывает эти расходы, можно переходить к проектированию продукта и выбору технологии.
Если цифры не сходятся, возможно, сейчас выгоднее инвестировать в веб-версию. Ускорить сайт, переделать мобильный интерфейс, упростить оформление заказа, доработать личный кабинет или автоматизировать процессы на backend.
В некоторых проектах такие изменения дают бизнесу больше эффекта, чем запуск отдельного приложения.
Поэтому я бы начинал обсуждение мобильной разработки с довольно простого вопроса: что изменится для бизнеса и пользователя после появления приложения?
Если на него есть конкретный ответ, дальше уже можно обсуждать PWA, Flutter, Swift или Kotlin. Если ответа пока нет, возможно, приложение ещё просто не пришло время делать.
