Native или cross-platform? Руководство по выбору для владельца бизнеса

Первое техническое решение, с которым вы сталкиваетесь при заказе мобильного приложения, — это native или cross-platform? На самом деле принимать это решение должны не вы, а разработчик. Но вы должны понимать его обоснование, потому что от этого решения зависят стоимость, сроки и то, с кем вы сможете работать в дальнейшем. Эта статья — не техническое сравнение; она написана для того, чтобы владелец бизнеса мог вести этот разговор.

Что такое native и cross-platform? Native (нативное) приложение разрабатывается для одной операционной системы собственными инструментами этой платформы: например, Swift для iOS, Kotlin для Android. Cross-platform (кроссплатформенное) приложение — это подход, при котором из единой кодовой базы создаются версии и для iOS, и для Android; самые распространённые инструменты этого подхода — React Native и Flutter. Ниже мы объясняем, что эта разница означает для владельца бизнеса с точки зрения стоимости, поддержки и команды.

Что означают три варианта?

В кроссплатформенной разработке две самые распространённые технологии — React Native и Flutter. В нативной для iOS используется Swift, для Android — Kotlin.

Практические отличия с вашей точки зрения

• Стоимость: если вы выходите сразу на две платформы, native означает две отдельные разработки. При cross-platform разработка одна, но под различия платформ всё равно возникает дополнительная работа — не ждите «половины стоимости».
• Поддержка: здесь разница ощущается сильнее всего. Каждое исправление и каждая новая функция в native делаются дважды. Если приложение будет жить годами, эта статья растёт.
• Поиск команды: если вы расстанетесь с подрядчиком, найти того, кто примет проект, должно быть несложно. Широко распространённые технологии в этом смысле выгоднее.
• Переход на вторую платформу: если вы планируете начать с одной платформы и затем перейти на другую, cross-platform заметно упрощает этот переход.
• Производительность: в типичных бизнес-приложениях с формами, списками, картами и оплатой пользователь обычно не чувствует разницы. Разница проявляется в приложениях с интенсивной графикой и постоянной анимацией.

В каких случаях нужен native?

Это конкретные основания; «будет качественнее» — не основание.

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

Если ни один из этих пунктов не подходит к вашей ситуации, cross-platform с большой вероятностью является разумным выбором. Но попросите разработчика обосновать это решение именно для вашего проекта; не принимайте его как общее правило.

React Native или Flutter?

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

Единственное, на что вам стоит смотреть, — обоснован ли выбор. «Мы всегда делаем на этом» — недостаточный ответ; «в вашем проекте есть такие-то потребности, поэтому мы выбираем это» — достаточный.

Ещё один вариант: вообще не выходить в магазины

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

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

Вопросы, которые стоит задать разработчику

• Какой подход вы рекомендуете для этого проекта и почему? Можете объяснить обоснование применительно к проекту?
• Сколько человек в вашей команде умеют работать с выбранной технологией?
• Ограничивает ли этот выбор то, что я, возможно, захочу добавить в будущем?
• Сколько работы по адаптации потребуется при ежегодных обновлениях операционных систем и как это оплачивается?
• Если я перестану работать с вами, насколько сложно найти человека, который примет проект на этой технологии?
• Как в договоре прописано право собственности на код и аккаунты?

Последние два вопроса нужно задавать в каждом проекте независимо от выбора технологии. Полный список вопросов при выборе подрядчика мы собрали в статье о выборе IT-компании.

Часто задаваемые вопросы

Кроссплатформенное приложение получается менее качественным?

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

Могу ли я потом перейти на native?

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

Разумно ли начинать с одной платформы?

Если вы знаете распределение устройств у вашей аудитории — да. Выбор cross-platform упростит работу, когда вы захотите выйти на вторую платформу.

Насколько выбор технологии меняет стоимость?

Если вы выходите на одну платформу, разница меньше; если на две и приложение будет годами поддерживаться — разница растёт. Статьи, определяющие стоимость, мы разобрали в материале о стоимости мобильного приложения.

Что будет, если поддержка выбранной технологии прекратится?

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

Давайте вместе посмотрим, что подходит вашему проекту

Расскажите, что будет делать ваше приложение, какими устройствами пользуется ваша аудитория и что необходимо в первой версии; мы объясним выбор технологии вместе с обоснованием. Ознакомьтесь с нашей услугой разработка мобильных приложений и свяжитесь с нами.