Гибридные приложения

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

Вообще, мы в Bright Mobile специализируемся на сложных серверных бизнес-приложениях, например, аналоги Авито, youdo, мобильные магазины, социальные сети и т.д. Анализируя ТЗ пришли к выводу, что в 95% случаев натив не то что не нужен, но даже вредит проекту. И сейчас я расскажу почему.

Но, сначала, давайте пройдём по общим характеристикам.

Общая архитектура

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

Гибридные приложения

На стороне клиентской части располагается приложение iOS или Android, а со стороны сервера, собственно, серверное ПО и админка для управления данными.

Вот теперь мы подходим к отличиям. А отличия заключаются в том, какой объём функционала несёт клиентская часть, а какой серверная. Непонятно? Давайте начнём с определений

Что такое натив, а что такое гибрид

Чтобы было понятно большинству пользователей я буду писать не строгие технические определения (их можно найти в википедии), а расскажу на пальцах, да простят меня программисты.

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

Гибрид - это скорее подход к программированию, чем какой-то особенный вид приложения. Его принцип заключается в том, что всё что можно (читай "все функции не связанные с железом") программируется на стороне сервера, а на стороне клиента остаётся только необходимый минимум. Если рассматривать типовой мобильный магазин, то GPS и функция отображения данных будет на стороне приложения, а каталог, карточки товаров и т.д. будут грузиться с сервера.

Давайте для примера рассмотрим как бы в гибриде и нативе выглядела наша платформа для создания сервиса поиска исполнителей "Сервис ПИ". Красным выделено то, что нужно делать на стороне приложения для телефона, а зелёным - на стороне сервера.

В нативе:

Гибридные приложения

В гибриде:

Гибридные приложения

Как видно из картинок единственная разница между нативом и гибридом - это объём функционала, который реализуется на стороне телефона. Но есть большое "НО". Весь "зелёный" функционал, который мы в гибриде перенесли на сервер делается 1 раз для обеих платформ, а красный - для каждой платформы пишется отдельно. Давайте разберём какие из этого можно сделать финансовые выводы.

Расчёт стоимости разработки приложений

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

  • Java-программист для андройда
  • Objective-C/Swift-программист для айоса
  • php-программист для сервера. Можно, конечно брать python-разработчика, но для чего он конкретно здесь, непонятно, поэтому, ориентируемся на php, т.к. он более дешёвый.

Нужно учитывать, что Андройд и айос программисты в среднем стоят примерно в два раза дороже php.

При полностью нативной разработке мы заплатим программистам приложений за полный функционал, а в случае гибрида только за нативные функции (отмечено красным). Оставшийся же функционал будет реализовывать php-шник. Причём, нативщики будут делать это всё и для iOS и для Android отдельно, а при гибриде php-шник делает эти экраны один раз для обеих систем. Получается, что почти двукратная работа выполняется специалистами, которые в 2 раза дороже. Путём не хитрых вычислений приходим к тому, что полностью нативное приложение будет стоить ~4 раза выше гибридного. Это, конечно, зависит от того какие нативные функции нужны в приложении и как они применяются, но при стандартном бизнес-приложении (GPS, камера, интернет) экономия в 3-4 раза.

Что выбрать для проекта

Конечно же, у натива преимущества вытекают из той же концепции:

  • "тяжёлые" вычисления, которые нужны на стороне телефона (например, работа с 3D, обработка виртуальной реальности, сложная анимация)
  • Отсутствие требований к постоянному наличию интернета (приложения шагомеры, пульсомеры, игры-кликеры, органайзеры и т.д.)

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

1414
13 комментариев

По поводу "требуют нативное, при этом не понимая что это".

Есть ощущение, что для клиента все несколько проще.

Есть натив - то, что нужно скачивать из стора и плея.

А есть веб. То, что добавляется из хрома функцией "поместить на рабочий стол".

И прося натив они просят именно установку из маркетов.

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

Создание веб-приложения сильно завязано на сам сайт. Кроме того, как я понимаю, с ними есть некие "проблемы" в ios. Поэтому клиенту важен "натив".

Не?

1

Тут стандартный вопрос "как его готовить". Конечно, если в обёртку на iOS упаковать унылый лендос, который разъезжается при ширине меньше 800 и где текст написан 8pt, то тут, конечно, апстор не пропустит. Но если сделать свайп-меню, а приложение будет по гайдам стора, то почему нет?

1

Интересное видение
не, с веб приложениями на iOS нет никаких проблем

Интересно, автор в курсе, что такое React Native?

В курсе конечно, но php кодерам реакт изучать... а html/js роднее.

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

Тоже удивился отсутствию даже упоминания RN. С точки зрения стоимости берём JS Full Stack девелоперов - и сервер на ноде, клиенты - web app, iOS/Android на RN, для win/macOS/Linux оборачиваем web app в электрон (возможно, с аддонами) - и, вуаля: приложения для всех платформ. Только JS. Никаких php))

Кстати насчёт требования постоянного подключения - PWA. Даже на iOS работает))