что такое гибридное приложение

Натив или гибрид? Специалисты Яндекса отвечают на главный вопрос мобильной разработки

Осталось буквально четыре дня до момента, когда мы закончим принимать заявки на участие во второй «Мобилизации» Яндекса. Она вновь объединит четыре летние школы для начинающих специалистов: Школу менеджмента, Школу мобильного дизайна, Школу разработки интерфейсов и Школу мобильной разработки под Android.

Своим опытом и знаниями с участниками будут делиться не только сотрудники Яндекса, которые делают приложения для миллионов пользователей, но и приглашенные специалисты. Мы не обойдемся только теорией. Будет много практики и командной работы над настоящими продуктами. Как всегда, обучение бесплатное, а всем иногородним студентам Яндекс оплатит проезд и проживание. Если вы еще не отправили заявку, есть немного времени это сделать. Занятия стартуют 3 июля и закончатся 23 сентября — в день двадцатилетия Яндекса.

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

Юрий Подорожный. Руководитель службы разработки мобильных геоинформационных сервисов Яндекса. Работает над Яндекс.Картами и Яндекс.Метро. Занимается мобильной разработкой более восьми лет. Основатель студии Any Void, которая в 2014 году стала частью Яндекса.

Сергей veged Бережной. Руководитель отдела разработки поисковых интерфейсов, в Яндексе с 2005 года. Успел поработать над Поиском, Почтой, Поиском по блогам, Я.ру, Картинками, Видео. Помимо этого, активно занимается развитием внутренних инструментов для создания сайтов.

Лола Кристаллинская. Руководитель департамента дизайна, работает в Яндексе с 2008 года, отвечает за найм, управление и развитие дизайнеров, коммуникации и образовательные программы департамента и всю экосистему дизайна в компании. С Лолы начался коллектив дизайнеров и исследователей дизайна Яндекса. До прихода в компанию руководила отделом создания сайтов Студии Артемия Лебедева.

Лола Кристаллинская:
Давайте для начала дадим определение, что вообще такое нативная и гибридная разработка и в чем между ними разница?

Юрий Подорожный:
В 2007 году появился iPhone, в 2008-м Apple дала возможность под него делать приложения, что и стало отправной точкой нативной разработки. Это компилируемый язык программирования со средой разработки, ограниченной какой-то одной мобильной платформой. Objective-C и Swift для iOS, Java — для Android. Приложения создаются на одном из этих «родных» языков по законам определенной платформы.

Лола:
В части программирования это было что-то революционно новое?

Юрий:
Конечно, нет. Сам термин «нативная» возник просто на контрасте с гибридным подходом.

Сергей Бережной:
Под гибридной разработкой мы подразумеваем способ писать приложения, когда оно полностью или частично рендерится и работает с помощью веб-технологий. То есть внутри используется что-то, реализованное с помощью HTML, CSS, JavaScript.

Юрий:
На самом деле чистое веб-приложение сейчас не сделать. Веб-вью все равно нужно положить внутрь iOS или Android-приложения, то есть в любом случае нужен контейнер, который написан с помощью Java, Swift или Objective-C. Значит, все равно будет какой-то процент нативного кода. Чистые веб-приложений были, наверное, только первый год существования iPhone, когда еще нельзя было создавать их со стороны. И Apple тогда продвигала тему, чтобы разработчики делали веб-приложения. Кстати, эта функция есть до сих пор. Заходишь в Safari, нажимаешь на экран «домой», на рабочий стол добавляется иконка, по сути, это и есть чистое веб-приложение. Только его, конечно, не распространишь через Store.

Сергей:
Сейчас есть целый ряд фреймворков, платформ типа PhoneGap/Cordova, в которых, условно говоря, уже написан этот фрагмент кода. Ты просто берешь их за основу и разрабатываешь на них, сочетая с веб-элементами на свое усмотрение.

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

Гибрид для простых задач, натив — для сложных

Лола:
В таком случае актуальна ли вообще проблема выбора? Например, я менеджер, у меня есть продукт и мне нужно сделать мобильную версию. Как принимать решение, что для меня лучше — гибридная разработка или нативная?

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

Юрий:
Согласен, все зависит от задачи. Но, на мой взгляд, веб уместен лишь в нескольких случаях. Например, если это совершенно новый продукт и пока не понятно, воспримет ли его рынок, нужен ли он кому-то или нет, то есть задача — протестировать некую гипотезу. Или если это просто отображение контента в небольшом количестве и не предполагается активного взаимодействия с интерфейсом, переходов между экранами и разделами. Например, приложение Meduza. Заходим на экран новости, это как раз веб-вью. У них простая верстка, точно такая же, как для веба, им даже контент готовить не надо, в мобильной версии все сразу отображается.

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

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

Скованные гайдлайнами

Лола:
В идеале все, конечно, должно идти от смысла, от того, что и зачем тебе нужно, какой продукт и что для него важно. Но мы живем в реальном мире, где не у всех и не всегда в принципе есть выбор. У кого-то не хватает денег, чтобы нанять целую команду разработчиков, поэтому приходится быть изобретательным. Какие еще факторы играют роль при выборе технологии?

Сергей:
Если бы у меня было бесконечное количество денег, я бы нанял трех разработчиков, которые сделали бы хорошие нативные версии под все платформы. Но я слишком жадный, чтобы позволять себе такое расточительство. Гибридный подход позволяет сэкономить: сделать один вариант и использовать его везде. Но если в дальнейшем задача усложнится, и появится необходимость, например, сделать наложение картинок на видео в реальном времени, то все равно придется потратиться на трех разработчиков.

Кроме того, встает вопрос, хотите ли вы трижды рисовать разный дизайн для каждого приложения. Ведь гайдлайны операционных систем сильно отличаются друг от друга, и как лебедь, рак и щука двигаются в разные стороны в мелочах. Если внимательно прочитать гайды Windows Phone, Android и iOS, то окажется, что нужно хорошо продумать, как ваша пользовательская задача будет оптимально решаться на каждой из платформ.

Лола:
Если приложение сделано не по гайдам, то проверку в Store не пройти?

Юрий:
Можно, конечно. Далеко не все приложения, прошедние проверку в Apple, соответствуют дизайнерским гайдлайнам. Никто особо не следит за соблюдением этих правил.

Сергей:
Но мы же говорим о приложениях A+ и AAA-класса, о высшей лиге. Если такие делать, то вопрос о нативном дизайне для каждой платформы обязательно встанет.

Лола:
А общий дизайн невозможен в нативной разработке: если просто свои кнопки и контролы?

Сергей:
Смотря к какому лагерю вы относитесь. Некоторые считают, что приложение должно быть внутри платформы. Альтернативная точка зрения – каждый бренд должен выглядеть на всех платформах одинаково. Если посмотреть на Instagram или Facebook, то это как раз примеры борьбы бренда за самоидентификацию по отношению к платформам. Они специально дизайнят свои приложения так, чтобы те выглядели по-особенному и везде одинаково.

Как делают приложения в Яндексе

Лола:
Для многих тот факт, что Facebook разочаровались в веб-технологиях и перешли на нативную разработку, стал доказательством превосходства последней. Насколько это обосновано?

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

Юрий:
У Facebook в первой версии было полностью нативное приложение, потом они перешли на HTML, пару лет пожили с двумя звездочками в Store, потому что продукт реально тормозил, все их ругали, в итоге вернулись к нативу. Вот живая иллюстрация того, как из благих намерений хочешь сделать хороший интерфейс на веб-технологиях, но в итоге все равно упираешься в низкую производительность или недостаток средств для развития.

Лола:
Но поисковое приложение Яндекса, например, сделано гибридно. Почему, если столько недостатков у веб-технологий?

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

Но сложно приходится нашим дизайнерам — им нужно создавать интерфейсы, которые будут восприниматься пользователями как «общий интерфейс Яндекса» независимо от платформы.

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

Лола:
Как вы в своих продуктах решаете проблему баланса между удобством пользователей и единством бренда?

Юрий:
Два года назад эта проблема в Яндексе была более явной. Все приложения сильно отличались между собой по стилистике. В итоге мы разработали свои общие для всех интерфейсные гайды, выбирая наиболее удачные паттерны из всех мобильных гайдлайнов, а иногда и придумывая свои, лучшие. Но процесс внедрения новых правил очень длительный, с огромным количеством подводных камней и пока не завершен окончательно.

Сергей:
Основные движущие факторы наших экспериментов с технологиями — это оптимизация трудозатрат на разработку и желание предоставить пользователям качественный продукт. Изначально мы делали наше поисковое приложение нативно, но столкнулись, например, еще с такой проблемой, как синхронизация команд и релизов. Даже если изначально вы решили потратиться на разных разработчиков под три разные платформы, то в дальнейшем рискуете столкнуться с проблемой управления. Как сделать так, чтобы новый UI, новые фичи на этих платформах везде обновлялись в одно время, и чтобы у них было действительно синхронное понимание этого интерфейса?

Как показывает практика, в крупных компаниях все это превращается в разные кланы разработчиков: одни делают мобильную версию приложения, другие — тач-версию сайта, третьи — десктопную версию, кто-то создает приложение для Android, а кто-то — для Windows Phone. И нужен менеджер 80-го уровня, чтобы синхронизировать все эти пять команд между собой. А подход единого кода, следовательно, единой команды, помогает избавиться от подобной путаницы.

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

Что нужно знать разработчику, чтобы начать делать приложения

Лола:
Насколько разнится порог вхождения у нативной и гибридной технологий? Вообще, какая база должна быть у программиста, чтобы уйти в мобильную разработку?

Юрий:
Разработчик нативных приложений должен знать Objective-C, или SWIFT, или Java, или C++. Но, на мой взгляд, на каком языке писать, дело наживное, ключевое здесь — базовые знания программирования. Все, с кем я в своей жизни делал приложения, были студенты без мобильного опыта, но с хорошим бэкграундом. Все остальное постигается на практике. Попадешь в хорошую команду профессионалов, вырастешь на порядок быстрее.

Сергей:
Если у человека есть опыт разработки интерфейсов с помощью HTML, CSS или JavaScript, то придется глубже погрузиться в специфику именно мобильных браузеров. Если мы говорим об интерфейсах, то это паттерны взаимодействия — больше пальцами, меньше с клавиатурой. Своя специфика внутри Runtime JavaScript и CSS для мобильных браузеров, но отличий в последнее время все меньше. Как правило, разработка под мобильные проще, чем под широкий спектр десктопных браузеров, потому что у них, как относительно новой технологии, более современная реализация именно веб-стандартов. Но сейчас по мере того, как мобильные платформы стареют, начинают возникать те же проблемы, что на десктопе, когда есть клиенты со старыми браузерами, которые какие-то вещи не поддерживают.

Лола:
А есть у программистов деление на мобильных и не мобильных? Например, на рынке дизайна сейчас это уже обязательный дополнительный скилл. Может быть, ты действительно каждый день не имеешь дела с мобильными интерфейсами, но без базовых знаний мобильного дизайна уже почти невозможно пройти собеседование и отбор.

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

Сергей:
Согласен, разрабатывать под микроконтроллеры или пользовательские интерфейсы — вещи действительно очень разные, и перепрыгнуть из одной лодки в другую не так-то просто. Но если говорить о мобильной разработке, то в Яндекс мы берем людей, которые верстают наши сайты сразу под декстопные и мобильные версии. То есть они должны понимать, как наша верстка, наш HTML, CSS и JavaScript будут работать в десктопных браузерах, а как в мобильных, какие есть особенности и нюансы. Получается, как с дизайнерами, дополнительный скилл фронтенд-разработчика.

Лола:
А внутри мобильной сферы насколько жесткое деление специалистов в зависимости от платформы?

Юрий:
Android и iOS — две совершенно разные истории. При желании, конечно, можно научиться делать и то, и другое. Но среди тех, с кем я работал, не было ни одного, кто менял бы платформы.

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

Адаптивная верстка — не панацея

Лола:
Я слышала, что для бедных, но хитрых, есть еще такая вещь, как адаптивная верстка, которая сразу и для веба, и для мобильных.

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

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

Лола:
Давайте резюмируем, как менеджеру, дизайнеру и разработчику учитывать все эти нюансы?

Сергей:
Я рекомендую не быть упоротыми фанатиками и каждый раз осознанно делать выбор, имея в голове как можно более широкий контекст и принимая во внимание все факторы. Не мыслить типа «Раз Facebook перешел с гибридного подхода на нативный, значит, и нам нужно» или «Раз Яндекс верстает свою выдачу в приложении на веб-технологиях, значит, и нам надо делать так». Нужно погрузиться в тему.

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

Источник

Разработка эффективного гибридного приложения

А помните ли вы свой первый мобильный телефон? Для меня это была Nokia 3310, неубиваемая «трубка», неустанно радовавшая меня скудным набором развлечений в виде игры в змейку, WAP и чудесных монофонических рингтонов. За последние тридцать лет индустрия шагнула далеко вперед. И это ещё мягко сказано: мобильные чипы приближаются по производительности к современным компьютерам, а две самые популярные на текущий момент системы — Android и iOS — предоставляют практически безграничные возможности для создания приложений на любой вкус.

Оплата по NFC, заказ такси буквально за пару свайпов, и даже тот же Instagram настолько плотно вошли в нашу жизнь, что необходимость создания мобильного клиента для своего бизнеса теперь уже не вызывает вопросов. Стандартом разработки в этом случае принято считать нативные приложения. Они работают плавно, имеют привычный пользователям UI и UX, а также доступ к разнообразным аппаратным возможностям смартфона и его операционной системы. Из основных недостатков этого подхода можно отметить необходимость иметь в штате выделенных iOS- и Android-разработчиков, возникновение сложностей в организации тестирования, и более длительный, по сравнению с web, релизный цикл. Нельзя забывать и про сегментацию: часть пользователей предпочитает оставаться на старых версиях приложения, старых версиях iOS и Android, обожают свои старые телефоны. Поэтому ненайденный в релизе баг, просочившись в сторы, напоминает землетрясение с долгим афтершоком.

Если у вас уже есть команда опытных мобильных разработчиков и налажен CI, то кажется, что выбор очевиден. Но зачастую бывают ситуации, когда время запуска функциональности в прод играет решающую роль, а постоянные обновления не идут на пользу репутации приложения. Хотя бы раз в жизни, каждый из нас брал кредит, или, по крайней мере, всерьез задумывался об этом. Обычно этот процесс включает в себя заполнение анкеты. Представим, что такая анкета есть у вас на сайте и в мобильном приложении. И вот банк решил освободить зарплатных клиентов от половины полей — это, безусловно, прекрасно, но влечет за собой изменения на сайте, а также в iOS- и Android-приложениях. Учитывая нашу асинхронность релизных циклов, а также возможность появления багов при обновлении, возникает риск получить три разные анкеты на неопределенный срок. А если подобные изменения нужно вносить часто?

Очевидное решение — гибрид. Существует множество фреймворков, позволяющих писать код сразу под обе платформы: Flutter, React Native, Ionic, однако их внедрение в существующий проект может стоить значительного времени и трудозатрат. Есть способ проще: помещая часть функциональности в WebView, мы можем быстро и относительно дешево переиспользовать часть уже реализованной на сайте логики. Контент, загружаемый из сети, в связке с нативными компонентами подчас абсолютно неотличим от нативного экрана. Так пользователи получат доступ к новым фичам одновременно с веб-версией, а мобильная команда сможет проработать полноценный нативный процесс в менее жестких временных рамках.

Если вы пошли по пути «гибрида», то важно понимать, когда это решение временное, а когда постоянное. Экран в WebView, как и любой другой, является частью экосистемы приложения. Запуская функциональность с объемной бизнес-логикой, придется закладывать значительное время и ресурсы на её поддержку. Но почему, если всё уже давно свёрстано и прекрасно работает?

50 оттенков сервисов

Тестирование под разные браузеры и разрешения — обычное дело при разработке фронта. Теперь этот чеклист пополнит ещё и мобильное приложение. Всё дело в WebKit-е, свободном движке для отображения веб-страниц, на котором работают все самые популярные браузеры. Он отвечает за единообразный разбор HTML, построение DOM, создание объектов window и document, работу с CSS, а также построение макетов и позиционирование UI-элементов. Однако при всём видимом удобстве, он насчитывает немалое количество версий, или, как их ещё называют, — «портов».

От одной версии к другой могут различаться подходы к управлению рендерингом, декодированию изображений и работе с видео; меняется поддержка кодеков, сетевой слой, а также используются разные JS-движки. Также WebKit позволяет включать или выключать любую функциональность на этапе компиляции при помощи compile-time feature flags, и даже в рантайме, при передаче параметров в командной строке или конфигурации. Прибавьте ко всему этому факторы, зависящие от «железа», и становится очевидно: браузер на телефоне точно будет отличаться от своего одноименного десктопного собрата.

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

WebView ≠ адаптив

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

С точки зрения UX и дизайна, процесс работы с приложением должен оставаться согласованным, а руководящие принципы разработки пользовательских интерфейсов платформ должны быть учтены. Можете считать, что создание отдельной верстки под WebView это неизбежная плата за возможность мгновенного обновления функциональности без привязки к мобильным релизам. Чтобы поддержка функциональности в WebView не причиняла вам боль, с самого начала тратьте время на создание базы UI-компонентов со стилями, использованными в приложении.

Бесшовный процесс

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

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

Хотите встроить экран в существующий процесс? Без проблем. Но при этом логика работы приложения должна оставаться согласованной, а данные — консистентными. Библиотека WebKit в связке со средствами JS, реализованными интерфейсами на стороне Android и message handler со стороны iOS способны обеспечить глубокую интеграцию WebView-экрана и нативного кода. Вы сможете добавлять нативные виджеты поверх страниц, управлять их UI, добавлять требуемое поведение и настраивать видимость.

Тёмная сторона WebView

Начиная с Android 10 и iOS 13 появилась функциональность, называемая «тёмной темой». Это альтернативная цветовая схема UI, предназначенная для заботы о ваших глазах во время использования телефона в ночное время. Библиотека WebKit позволяет выставить настройки, согласно которым загруженная страница будет отображаться в соответствии с темой, установленной в текущий момент на телефоне (рекомендуемый режим), всегда в тёмном или светлом виде. Обратите внимание, что добавление поддержки тёмной темы в CSS веб-страницы строчкой @media (prefers-color-scheme: dark) не даст нужного результата, так эта настройка влияет только на контролы — панель прокрутки, кнопки приближения и отдаления и т.д., но не на стиль контента, отображаемого внутри WebView.

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

Разделяй и властвуй

Одними из важнейших показателей стабильности мобильных приложений являются доля crash-free users и отзывы в сторах. И если раньше все данные об ошибках, логи и пользовательские метрики можно было найти в Firebase или любом другом любимом вами сервисе, то теперь отладка и сбор аналитики станут несколько сложнее. В то же время оценки пользователей всё так же будут отражать их отношение к продукту целиком, вне зависимости от того, в какой части работы с гибридом у них возникли затруднения. Разбор каждого такого случая теперь будет начинаться с выявления источника: ошибка в нативе или вебе, или всё же в интеграции. Решением может стать сегментирование отзывов пользователей по тегам и перенос аналитики в единый кроссплатформенный сервис.

Один из популярных сервисов мониторинга активности приложений в App Store и Google Play — AppFollow. Он предоставляет автоматическую разметку отзывов пользователей. Для этого нужно прописать правила, согласно которым будут проставляться теги. Например, к жалобам на баги можно отнести отзывы с наличием в тексте слов «баг», «ошибка» или «не работает», а также с оценкой меньше 3.

А для сбора аналитики отлично подойдет ClickHouse — open source СУБД российской разработки, предназначенная для работы с большими объёмами данных. Она способна эффективно обрабатывать запросы в реальном времени, при этом их синтаксис максимально приближен к классическому SQL. Помимо быстродействия и низкого порога вхождения для пользователей стоит также отметить отлично реализованное сжатие данных и отсутствие проблем с подключением — у сервиса активное сообщество, на текущий момент есть готовые коннекторы под большинство популярных языков программирования. А если мне до сих пор не удалось вас убедить, то посмотрите руководство, знакомство с функциональностью займёт буквально пару часов, а тестовые данные идут в комплекте.

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

Выбирая между запуском MVP в нативе и WebView, важно понимать, что лучшее решение принимается только в контексте задачи. Нативные SDK позволяют эффективно контролировать объём памяти, используемой приложением, загружать файлы в фоне, хранить локально большие объёмы данных, а также использовать все аппаратные преимущества современных смартфонов и систем iOS и Android. Требуется минимальный Time To Market? Гибридное решение позволяет запускать новую функциональность синхронно с сайтом, фиксить баги быстро и одновременно на всех устройствах. Однако при его некачественном исполнении пользовательский опыт может серьёзно пострадать.

Так где же золотая середина? WebView может неплохо себя показать в качестве заглушки, однако, как известно, нет ничего более постоянного, чем временное. Отличным вариантом будет начать разработку нативной версии одновременно со страницей гибрида. Мобильные разработчики смогут быстро погрузиться в контекст, фронты — корректно доработать вёрстку, пользователи получат фичу в самые короткие сроки, а через релиз экран уже станет нативным. Выбирайте мудро, используйте инструменты правильно, и результат не заставит себя долго ждать.

Источник