WebView в мобильном приложении: плюсы, минусы и экономия денег

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

WebView в мобильном приложении:  плюсы, минусы и экономия денег

Находясь в рынке разработки ПО и в роли заказчика, и в роли исполнителя-аутсорсера я вижу прекрасный рыночный тренд – бизнес начал уверенно использовать WebView и запускать на нем мобильные приложения..

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

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

Что такое WebView приложение?

Если максимально просто: WebView – это когда в мобильном приложении встроенный веб-браузер отображает на весь экран специальную мобильную версию сайта.

WebView в мобильном приложении:  плюсы, минусы и экономия денег

В основном, это означает, что или часть, или вообще весь фронтенд приложения работает на каком-нибудь фронтент-фреймворке, например React и отображается внутри WebView.

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

1. Скорость разработки

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

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

В случае WebView, разработчик загружает ветку с обновлением на сервер и тестировщики могут проверить новый цвет кнопки буквально сразу же.

2. Скорость доставки обновлений

Как и в предыдущем пункте, чтобы всем пользователям приложения стала доступна новая кнопка, приложение сперва должно пройти весь цикл публикаций в магазины и проверки независимыми модераторами App Store и Google Play.

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

В случае WebView же, обновление будет доступно сразу и всем 100% пользователям, без необходимости куда-то нажимать или что-то обновлять.

3. Разработка и поддержка WebView приложения дешевле

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

В текущими зарплатами два разработчика могут стоить от полумиллиона рублей и более.

Если же мы используем WebView, то разрабатывать и поддерживать приложение под все платформы может любой фронтенд-инженер, знакомый с TypeScript. И приложение-контейнер на React Native, написанное на TypeScript и веб-приложение внутри, написанное на обычном React и представляющее из себя мобильную версию обычного веб-приложения.

Любой миддл фронтендер с рынка может поддерживать это, экономия минимум 2X.

Звучит хорошо, правда? Это проще, быстрее, идеально подходит под запуск MVP. Но есть и нюансы:

1. Ограниченный доступ к нативным функциям

Для сложных вещей, например, доступа к SMS, аппаратным функциям и настройкам, нужно делать внутреннюю прослойку. Просто небольшой костыль для обмена информацией между веб и самим приложением-контейнером, которое обменивается информацией с устройством.

2. Производительность

Не для сложных анимаций или для сложных, но не на слабых устройствах. В целом ограничение в Сафари (браузер на айфонах) 60 кадров в секунду.

3. Зависимость от доступа к интернету

Как минимум для первого запуска и загрузки приложения нужен доступ к интернету. Потом приложение может жить в хранилище и быть оффлайн.

Кто и зачем выбирает WebView

Серьезные компании не используют WebView? Или используют? Давай посмотрим на рынок вместе. Я встречал несколько заблуждений про WebView приложения. Например, говорили, что приложения, внутри которых нет нативного кода, не проходят модерацию в App Store. Но это, конечно же, не правда.

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

Давайте рассмотрим конкретные примеры, какие компании и зачем используют WebView в своих мобильных приложениях.

Мы в Хуке занимались разработкой для британской экспресс-доставки Jiffy Grocery. Одним из продуктов, которые мы создавали, было клиентское мобильное приложение для заказа. Коллеги из Jiffy поделились с нами опытом X5 и других крупных ритейл компаний, которые используют вебвью.

В итоге, мы разработали мобильное приложение таким образом: это был фронтенд на React и приложение-контейнер на React Native.

Jiffy – сервис экспресс-доставки продуктов
Jiffy – сервис экспресс-доставки продуктов

Это позволило нам достаточно быстро, за 3 месяца, запустить первую версию продукта и очень быстро доставлять обновления до пользователей, минуя циклы проверки модераторами. А UX ничем не отличался от такового в нативных приложениях: та же самая работа с геолокацией, Push-уведомлениями, тактильной отдачей в интерфейсе.

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

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

Игорь Демишев, со-основатель Jiffy

Таким образом, в том числе достигнув очень высоких темпов разработки и невероятно ускорив Time To Market благодаря использованию вебвью, это позволило Jiffy суммарно привлечь $35 миллионов долларов инвестиций.

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

Следующий пример уже личной мой – отечественный фудтех-стартап Postilla. Имея потрясающий опыт в Jiffy, запуская Постиллу мы тоже выбрали использовать WebView.

Postilla – российский фудтех, в котором более 100 ресторанов используют приложение на вебвью
Postilla – российский фудтех, в котором более 100 ресторанов используют приложение на вебвью

Почему? Как и в случае кейсе Jiffy, нам важно было очень быстро запустить продукт, что, в принципе, логично для любого стартапа. Мы создали удобную систему для быстрого запуска мобильных приложений кафе и ресторанов на нашей платформе и централизованной доставки обновлений сразу во все приложения наших клиентов – таким образом, обновляя фронтенд, это обновление получают автоматически пользователи всех приложений, работающих на платформе Postilla.

И точно так же, как и в случае с Jiffy, это позволило без разработки с нуля масштабировать фронтенд до веб версии. И расти дальше.

Знаю, пара собственных примеров может звучать не очень убедительно и объективно. Как в детстве, на рынке, когда тебе мама выбирает джинсы, а продавец говорит «Хорошие джинсы, сам такие ношу!». Поэтому, идем дальше.

Можно посмотреть на пример самой авторитетной айти-компании страны – Яндекс. Начав с WebView, они пришли к своему собственному server-driven UI фреймворку, который позволяет примерно то же самое: централизованно в облаке управлять интерфейсом приложения, без необходимости нативной разработки фронтенда.

Сейчас на этой технологии работает большинство продуктов Яндекса: от Лавки до ТВ.

Как запустить приложение на WebView?

Здесь все предельно просто и умещается в несколько шагов.

  1. Создать приложение-контейнер. Универсальным будет выбор React Native: один код под все платформы и поддерживать может любой TypeScript разработчик – то есть, ваш штатный фронтендер. Простейший код приложения-контейнера выглядит так, покажите это вашему фронтендеру.
  2. Разработать обычное веб-приложение на любом привычном для вашей команды фреймворке и разместить его где-нибудь на сервере. Важно учесть нюансы UX мобильных приложений: например, блокировать свайп назад в определенных экранах. И чтобы код веб-приложения кешировался и пользователям не приходилось ждать загрузки каждый раз.
  3. В приложении-контейнере сделать методы для взаимодействия веб-приложения и приложением-контейнером. Например, для передачи методов аналитики и методов тактильной отдачи (Haptic Feedback).
  4. Опубликовать в магазины приложений.

Всё достаточно просто, но если вдруг кажется, что нет – в конце статьи я оставил свои контакты, мне можно написать и я поделюсь с вами опытом.

В итоге, что выбрать: нативное приложение или WebView?

Самый важный вопрос для тех, кто пришел в эту статью за помощью в принятии решения. Для этого еще раз сравним Native vs WebView:

WebView в мобильном приложении:  плюсы, минусы и экономия денег

WebView:

  • Быстрая разработка: Один и тот же код может быть использован для различных платформ (Android, iOS), что сокращает время разработки.
  • Обновления: Легче и быстрее проводить обновления, поскольку в большинстве случаев не требуется выпускать новую версию приложения через магазины приложений.
  • Ресурсы: Меньше нужно специализированных разработчиков (нет необходимости в Android- и iOS-разработчиках).

Нативная разработка:

  • Длительная разработка: Необходимость писать код для каждой платформы отдельно увеличивает время разработки.
  • Обновления: Каждое обновление требует прохождения через процесс утверждения в магазинах приложений, что может занять время.
  • Ресурсы: Необходимы специализированные разработчики для каждой платформы, что также влияет на скорость выхода продукта на рынок.

Объективно видно, что запуск на WebView дешевле и быстрее. Если вы готовитесь начать разработку вашего первого мобильного приложения и быстро протестировать гипотезы, не вкладывая много ресурсов – выбор предельно очевиден, вебвью вам в два-три раза сэкономит деньги и время.

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

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

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

В статье я специально не сравнивал с React Native, Flutter и в целом кросс-платформенными фреймворками, хотя они тоже позволяют ускорить запуск и time to market новых функций – просто для Flutter все еще нужно нанимать специальных людей и обычный фронтендер там не справится, а это не подходит.

Расскажите, какую технологию вы используете в вашей компании и почему? Согласны ли с тезисом, что MVP лучше делать на WebView, потому что это позволяет запустить первую версию дешевле и быстрее?

Какую технологию вы используете в компании?
Нативная разработка (Swift, Objective-C, Java, Kotlin)
Нативная + WebView
WebView
Кросс-платформа (React Native, Flutter, Ionic)
Я просто посмотреть

Буду рад, будучи фаундером нескольких айти компаний и автором телеграм-канала Директор айти компании, абсолютно бесплатно проконсультировать на тему выбора технологии для вашего мобильного приложения! Просто напишите мне в Telegram: @lupikovoleg.

Другие мои материалы:

66
7 комментариев

Дохерищи необоснованных англицизмов. Так можно в курилке с разработчиками базарить за "косты" и "кейсы" и всякие "ачивки".

2
Ответить

Нет, спасибо! Нам за 4000 руб делают с кворка! Разница- почти в 1000 раз! А на разницу в цене можно заказать еще 1000 придожений, ну или 900 🤣

1
Ответить

Удачи с приложением за 4000 руб 😄

Ответить

а сколько стоит у вас приложение вебвью для андроида и ios?

Ответить

Хей, от 3млн рублей

Напиши мне, расскажу

Ответить

Колхоз. Ноль упоминаний кросснатива в статье.

Умышленно дается выбор между нативом и вебвьюхой. Еще и за нее от 3 лямов просят тут ниже, в комментах 😂😂😂😂

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

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

Вывод: автор - колхозан и умышленно скрывает важные нюансы, продвигая устаревшее решение как современное.

Пы.Сы. Да, да, в своей статье пару лет назад про русский биханс автор необоснованно потешил свое эго и чсв, назвав меня колхозном, прошло пару лет и я теперь тешу обоснованно)

Ответить