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 приложения. Например, говорили, что приложения, внутри которых нет нативного кода, не проходят модерацию в App Store. Но это, конечно же, не правда.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

WebView:

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

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

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

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

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

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

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

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

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

#webview #native #мобильное_приложение #мобильноеприложение #разработка #iOS #android #appstore #googleplay