Главная

8 причин, по которым мы отказались от разработки гибридных приложений.

Почему кроссплатформенная разработка играет с нами злую шутку.

1,104 

17+

Если для вашего бизнеса понадобится мобильное приложение, что вы выберете: нативное или гибридное приложение?
Нативные приложения пишутся отдельно для каждой платформы. Чаще всего клиенты просят сделать 2 приложения — для iOS и Android. Каждая из версий пишется на родном языке платформы (Swift/Objective-C для iOSJava/Kotlin для Android).
Гибридное приложение, в свою очередь, — это одно решение для всех платформ. Код JavaScriptC# или Dart генерируется посредством фреймворков в нативный.
В интернете можно найти множество информации о различии нативных и гибридных приложений. Кто-то рассказывает о нюансах разработки, а кто-то пытается полностью охватить тему.
Но как понять, что стоит выбрать, если вы клиент? Есть несколько причин, по которым мы делаем только нативные приложения для наших клиентов. Теперь я объясню почему.

Экономия

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

Поддержка

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

Функциональность

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

Исполнение

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

Дизайн

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

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

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

Провалы в Store

Исходное приложение изначально соответствует требованиям конкретной платформы. Таким образом, существует небольшая вероятность возникновения проблем при запуске приложения в официальных магазинах App Store или Google Play. В гибридных приложениях используются официально неподдерживаемые технологии, такие как React Native, который все еще находится на стадии бета-тестирования, Ionic и т.д. Это также повышает риск сбоя.

Сложности с оплатой

Внутренние покупки iOS и Android осуществляются через Apple Pay или Google Pay. Для этого вам не нужно дополнительно вводить данные своей карты. Оплата для гибридного приложения подключается через плагины, платформы или SDK. Эти кроссплатформенные решения нестабильны, потому что каждое изменение в собственных функциях требует обработки или уточнения их гибридных аналогов. А без удобного способа оплаты конвертация будет падать, потому что немногие пользователи держат карту под рукой, чтобы снова и снова вводить ее данные вручную.

Перспективы развития

Если со временем вы захотите оптимизировать скорость работы гибридного приложения, вам нужно будет вводить фрагменты кода на нативных языках. Это означает, что вам нужен разработчик, который хорошо знает все 3 среды. Для гибридных приложений существует множество платформ, и найти программиста, который знает подходящие для вашего приложения, непросто.
Гибридные решения рекомендуются для небольших статических приложений с ограниченным числом пользователей. Если ваше приложение будет расти, возникнет необходимость переписать его в собственный технический стек. У нас были клиенты, которые пришли с гибридным приложением и попросили сделать его нативным, но мы никогда не сталкивались с противоположной ситуацией.

Заключение

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

17+