Flutter, React Native или нативная разработка: выбор по критериям
Flutter, React Native и нативная разработка в сравнении по производительности, команде, поддержке, функциям устройства и бюджету, чтобы выбрать подходящий путь.
Команда rabbitclipПубликация: 6 мин чтения
Коротко
Выбор между Flutter, React Native и нативной разработкой представляет собой решение о том, будет ли приложение для обоих магазинов строиться на одной кодовой базе или на отдельном коде для каждой платформы, а если на одной кодовой базе, то с помощью какого инструментария. Нативная разработка означает, что для iOS и для Android пишется отдельный код и используются собственные инструменты каждой платформы. И Flutter, и React Native нацелены на обе платформы с во многом общим кодом; каждый из них является зрелым, широко используемым подходом, созданным именно для этой цели. Правильный выбор не берётся из рейтинга. Он берётся из потребностей продукта, навыков команды и плана поддержки.
Эта статья не хвалит ни одну из сторон. Она ставит три подхода рядом по одним и тем же критериям и объясняет, в какой ситуации каждый из них несёт меньше рисков. Наши статьи о создании мобильного приложения на Flutter и о мобильном приложении и PWA тоже затрагивают эту тему; здесь же основное внимание уделено тому, как три подхода к разработке соотносятся друг с другом.
Чем отличаются эти три подхода?
При нативной разработке приложение для iOS пишется на собственном языке и с помощью собственных инструментов платформы, а приложение для Android на своих. В итоге у вас получаются две кодовые базы. Вы первыми получаете доступ к новым возможностям каждой платформы и самую прямую связь с возможностями устройства, но работа делается дважды.
Flutter представляет собой инструментарий, который сам рисует интерфейс с помощью собственного движка отрисовки и использует язык Dart. React Native пишется на JavaScript или TypeScript и показывает интерфейс через собственные компоненты платформы. Оба подхода нацелены на выпуск в два магазина силами одной команды; они различаются тем, как создаётся интерфейс, и тем, какой язык знает команда.
По каким критериям их стоит сравнивать?
Чтобы выбор не превратился в спор о технологиях, сначала запишите критерии и оцените каждый из них применительно к вашему продукту. Если какой-то критерий для вас критичен, он решает дело, как бы хорошо ни выглядели остальные.
К каждому критерию задаётся один и тот же вопрос: насколько малый риск несёт этот подход в том, чтобы удовлетворить потребности данного продукта? Ответы обычно получаются не в виде чисел, а в виде различия вроде «удобно», «требует внимания» и «трудно».
- Команда: язык и опыт разработчиков, которые у вас есть или которых вы можете найти
- Функции устройства: потребности, близкие к платформе, такие как камера, датчики, Bluetooth и фоновая работа
- Интерфейс и анимация: фирменный и визуально насыщенный или стандартный вид платформы
- Поддержка: кто и как будет следить за обновлениями версий и изменениями библиотек обеих платформ
- Время и бюджет: одна команда или две и насколько срочен первый выпуск
В какой ситуации каждый подход выглядит предпочтительнее?
Если продукт находится очень близко к платформе, например активно использует камеру и датчики, выполняет работу, которая непрерывно идёт в фоне, имеет расширения для часов и автомобиля или с первого же дня нуждается в самых новых возможностях платформы, то нативная разработка обычно приносит меньше всего неожиданностей. Цена этого сопровождение двух кодовых баз и, как правило, двух команд.
Если вы хотите, чтобы интерфейс выглядел одинаково и фирменно на обеих платформах, а команда готова выучить новый язык, Flutter становится естественным кандидатом. Если в вашей команде есть веб-разработчики, которые уже знают JavaScript или TypeScript, React Native оказывается кратчайшим путём к тому, чтобы использовать уже имеющиеся навыки, и обмен кодом и знаниями между вебом и мобильной разработкой тоже может стать проще.
Эти фразы описывают общие тенденции, а не правила. Успешные, быстрые и привлекательные приложения пишутся на всех трёх подходах; проблемы обычно возникают из-за несоответствия между продуктом и инструментом, а не из-за самого инструмента. Поэтому перед принятием решения спор сокращает небольшая проба, в которой самый рискованный экран или самую рискованную функцию продукта проверяют на каждом кандидате.
Как команда и поддержка влияют на выбор?
Работа не заканчивается с выпуском приложения. Каждый год обе платформы выпускают новые версии, библиотеки меняются, а правила магазинов обновляются. При кроссплатформенных инструментах эти изменения приходится учитывать и на стороне платформы, и на стороне самого инструментария. При нативной разработке одно и то же изменение делается дважды в двух отдельных кодовых базах.
Важна и человеческая сторона. Подумайте о том, кто заменит человека, знающего выбранный инструмент, если он уйдёт, и о том, насколько живы сообщество и документация этого инструмента. Оценивайте это не наугад, а исходя из реального положения дел на вашем собственном рынке с поиском разработчиков на этом языке.
- Кто будет следить за ежегодными обновлениями версий обеих платформ
- Кто будет устранять несовместимость библиотек в выбранном инструменте
- Насколько легко можно заменить уходящего члена команды
- Насколько актуальны документация и сообщество инструмента
Какие ошибки часто встречаются при выборе технологии?
Самая частая ошибка состоит в том, что выбор отдают на откуп популярности или спорам в интернете. Инструмент, который сработал в другой компании, может не дать того же результата с вашей командой и вашим продуктом. Вторая ошибка в предположении, что кроссплатформенная разработка всегда дешевле; одна кодовая база сокращает объём разработки, но части, специфичные для платформы, и поддержка всё равно требуют усилий.
Третья ошибка в том, что при решении думают только о первом выпуске. То, кто будет сопровождать приложение через три года, нередко важнее того, как быстро вышла первая версия.
- Отдавать выбор на откуп популярности или спорам в интернете
- Считать, что кроссплатформенная разработка дешевле в любом случае
- Думать только о первом выпуске, не учитывая поддержку
- Принимать решение, не опробовав самую рискованную функцию
Когда это сравнение оказывается неверным вопросом?
Если ваш продукт в основном показывает контент, заполняет формы и почти не нуждается в таких возможностях, как присутствие в магазинах или уведомления, то настоящий вопрос заключается в том, должен ли он быть мобильным приложением или PWA; один из трёх подходов к разработке вытекает из ответа на этот вопрос. Сначала проверьте, действительно ли продукту нужно приложение.
Если вы всё ещё находитесь на стадии идеи, то и выбор технологии преждевременен. Сначала проверьте идею на прототипе; выбор будет здоровее, когда станет ясно, что именно будет построено на самом деле. Существуют и другие варианты, но понимание рассуждений, лежащих в основе этих трёх, также даёт хорошую основу для того, чтобы их оценивать.
Единого правильного ответа для Flutter, React Native и нативной разработки не существует. Правильный ответ складывается из потребностей продукта, навыков вашей команды и вашего плана поддержки. Сначала запишите свои критерии, проверьте самую рискованную функцию в небольшой пробе и учтите поддержку за пределами первого выпуска. Если вы хотите взвесить три подхода применительно к вашему собственному продукту, вы можете договориться с rabbitclip об ознакомительной встрече.
Частые вопросы
Что лучше, Flutter или React Native?
В целом ни один из них не лучше другого; один из них несёт меньше риска в зависимости от языка команды, требований к интерфейсу и плана поддержки. Команды, которые знают Dart или готовы его выучить и хотят фирменный интерфейс, склоняются к Flutter, а команды, знающие JavaScript, к React Native.
Нужна ли ещё нативная разработка?
Для продуктов, очень близких к платформе, например приложений, которым требуется интенсивная работа с камерой, датчиками или в фоне, а также когда с первого дня нужны самые новые возможности платформы, нативная разработка приносит меньше всего неожиданностей. Для многих бизнес-приложений она не обязательна.
Всегда ли кроссплатформенное приложение дешевле?
Нет. Одна кодовая база обычно сокращает усилия на разработку, но части, специфичные для платформы, тестирование и поддержка всё равно требуют усилий. Стоимость определяют объём работ, число интеграций и план поддержки, а не название инструмента.
Можно ли позже перейти с одного подхода на другой?
Можно, но это означает переписать большую часть приложения. Поэтому дешевле тщательно выбрать подход в самом начале, проверив самую рискованную функцию в небольшой пробе и учтя поддержку.
