Битва титанов: натив, кроссплатформа и PWA – ищем плюсы и минусы на каждом этапе разработки. Часть 2

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

Тестирование и отладка

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

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

PWA. Меньше людей и времени нужно на тестирование. Экономия около 40% по сравнению с нативом. И большой плюс: на вебе проще всего автоматизировать тестирование. Много специалистов, много фреймворков. Разработчики сами пишут автотесты, и 2-3 тестировщика могут обеспечивать качество всего приложения.

Уже рассказали, как реализуем это на практике: Playwright и Allure как хорошая практика для разработки веб-приложения

Развертывание и публикация

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

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

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

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

Железобетонный ситуативный аргумент: нет сторов – нет санкций.

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

Кстати, а что насчет безопасности приложение вообще?

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

У PWA меньше технических возможностей взаимодействия со смартфоном, но они не проходят проверки в сторах. Фрод здесь вероятнее с точки зрения социнженерии.

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

Однажды у нас спросили, безопасно ли банковское PWA-приложение. Мы сделали мем на этот случай. 

Обновление и поддержка

У натива и кроссплатформы эти процессы опять-таки связаны со сторами и всеми вытекающими проблемами.

В целом поддержка натива будет дороже – нужно больше специалистов.

В этом плане PWA выглядят выгоднее на общем фоне. До 20% стоимости проекта на поддержке можно сэкономить. И это весомая часть бюджета.

Сколько стоит разработка?

Потенциальный клиент всегда хочет видеть точную сумму в ответе на этот вопрос. Здесь ее по объективным причинам не будет. Но подсчитать в процентах реально.

У нас получилось так:

Натив – всегда дорого.

Кроссплатформа – на 15% дешевле натива.

PWA – на 30% дешевле натива:

• в 2 раза дешевле разработка (команда)

• в 1,5 раза дешевле тестирование

• в 2 раза дешевле поддержка

Выжимка главного из двух статей со сравнением удобно визуализирована и лежит на этой доске.

Во время подготовки текста мы много обсуждали и спорили, чтобы оставаться объективными и раскопать все плюсы и минусы. Получилось ли – поймем по комментариям. И готовы к вопросам.