Разбор6 мин чтения
React Native или нативная разработка — честное сравнение для бизнеса
Что бизнес на самом деле получает от одного кода на iOS и Android, где нативная разработка выигрывает и какие вопросы задать себе до выбора.
Нуралы КопбосынДизайнер и разработчик цифровых продуктов · 8 лет, 80+ проектовСодержание6 разделов
Для большинства бизнес-приложений — каталог, заказы, личный кабинет, запись, QR-отметки, уведомления — React Native даёт пользователю тот же результат, что и нативная разработка, но одним кодом на iOS и Android. Это дешевле в разработке и проще в поддержке. Нативная разработка — на Swift для iPhone и Kotlin для Android — выигрывает там, где приложение упирается в возможности телефона: сложная графика, внешние устройства, постоянная работа в фоне, новые функции системы в день их выхода. Я чаще всего делаю приложения на React Native и ниже объясню почему — и где этот выбор не подходит.
Что такое React Native простыми словами
React Native — способ написать приложение один раз и собрать его для iOS и Android.
Частый миф — что это сайт, завёрнутый в приложение. Это не так. React Native рисует настоящие системные элементы интерфейса: списки, кнопки, поля ввода, переключатели. Поэтому приложение ведёт себя как родное — прокрутка, жесты и клавиатура работают так, как человек привык на своём телефоне.
Если какой-то функции нет в готовых библиотеках, её пишут нативно и подключают к общему коду. Поэтому выбор не всегда «или — или»: можно сделать приложение на React Native, а один тяжёлый экран или работу с устройством — нативно.
Вокруг React Native есть набор инструментов Expo: сборки в облаке, тестовые версии, которые открываются на телефоне заказчика по ссылке, обновления по воздуху. Для бизнеса это значит, что работающее приложение вы держите в руках с первых недель, а не видите на скриншотах до самого конца.
Что бизнес получает от одного кода
Сроки. Одна команда делает обе платформы сразу. Функция появляется на iPhone и Android в один день, а не тогда, когда освободится второй разработчик.
Поддержка. Ошибку исправляют один раз. Бизнес-логика — скидки, статусы, правила — живёт в одном месте и не расходится между платформами. В нативной разработке это два кода, и со временем они почти неизбежно начинают вести себя по-разному.
Обновления по воздуху. Исправления в логике и интерфейсе можно доставить пользователям без новой проверки в магазине приложений — если они не меняют суть приложения и не требуют нового нативного кода. Критичную ошибку можно закрыть в тот же день.
Общий язык с остальной системой. React Native пишется на TypeScript — на том же языке, что сайты, админки и серверы, которые я делаю. Типы данных и правила проверки можно делить между приложением и остальной системой. Для бизнеса это значит меньше расхождений между тем, что показывает сайт, и тем, что показывает приложение.
Люди. Разработчиков на TypeScript и React найти проще, чем пару «iOS плюс Android». Если однажды проект перейдёт к другой команде, её будет легче собрать.
Где нативная разработка выигрывает
Честно — такие случаи есть:
- Сложная графика и анимации на пределе возможностей телефона — игры, дополненная реальность, редакторы фото и видео.
- Внешние устройства — Bluetooth-датчики, принтеры, терминалы, нестандартные сканеры. На React Native это возможно, но через нативные модули, и выгода от общего кода тает.
- Постоянная работа в фоне — непрерывная геолокация, запись звука, долгая синхронизация. Правила iOS и Android здесь разные, и нативный код работает с ними напрямую.
- Новые функции системы в первый день — виджеты, приложения для часов, новые возможности камеры. Натив получает их сразу, React Native — когда появится библиотека или её напишут.
- У вас уже есть нативное приложение и команда. Переписывать работающий продукт ради модной технологии — плохая причина.
Есть и минус, о котором стоит сказать: приложение на React Native обычно весит больше минимального нативного. На большинстве телефонов это незаметно, но если ваши пользователи сидят на старых устройствах с забитой памятью, это аргумент.
Если свести сравнение в одну таблицу:
| Критерий | React Native | Нативная разработка |
|---|---|---|
| Код | Один на iOS и Android | Два отдельных |
| Новая функция | Сразу на обеих платформах | Дважды, иногда в разные дни |
| Функции телефона | Через библиотеки и нативные модули | Все и напрямую |
| Исправления | Часть — по воздуху, без магазина | Только через проверку магазина |
| Команда | Разработчики TypeScript и React | iOS и Android по отдельности |
Мифы, которые мешают выбрать
«Кроссплатформенное тормозит». Для бизнес-приложения — списки, формы, карточки, оплата — пользователь разницы не заметит. Тормозит обычно плохо написанное приложение, на любой технологии.
«Натив всегда качественнее». Качество определяет не технология, а то, как продуманы сценарии и написан код. Два нативных приложения — это ещё и два места, где может появиться ошибка.
«React Native скоро забросят». Технологию развивает Meta и сама использует в своих приложениях, на ней работают продукты многих крупных компаний. Риск есть у любого инструмента, но здесь он не выше, чем у других.
Есть и другие кроссплатформенные инструменты — например, Flutter от Google, со своим движком отрисовки. Это тоже хороший выбор. Я работаю на React Native из-за общего языка с вебом: когда у продукта есть сайт, админка и сервер, меньше разных технологий — меньше расходов на поддержку.
Пять вопросов перед выбором
- Что приложение делает чаще всего? Списки, формы, оплата, уведомления, камера для QR — React Native.
- Работает ли оно с внешними устройствами или постоянно в фоне? Если да — смотрите в сторону натива или гибрида, где тяжёлую часть пишут нативно.
- Есть ли у вас сайт и админка, с которыми приложение делит данные? Если да — общий язык с вебом упрощает жизнь всей системе.
- Кто будет поддерживать приложение через несколько лет? Одна команда или две — и во что обойдётся каждая доработка.
- Как быстро нужно выйти? MVP приложения я делаю от 3–6 недель, срок зависит от числа экранов и интеграций. Что такое MVP и как в него уложиться, — в заметке «Что такое MVP и как запустить его за 3–6 недель».
Приложение — это окно в систему
Почти всегда мобильное приложение — не отдельный продукт, а ещё одно окно в вашу систему. В Digital Control слушатель отмечается на занятии по QR, и посещаемость сразу видна в CRM. В Arba Wine приложение для покупателей работает на тех же данных, что магазин и ERP. В таких проектах главная работа — не экраны, а связь: откуда приложение берёт данные, куда их отдаёт и что происходит, когда связи нет.
Поэтому технологию я выбираю после того, как понятны данные и сценарии, а не до.
Если вы выбираете технологию для приложения, начните не с неё, а с вопроса, что человек будет делать в приложении каждый день. Иногда честный ответ — что приложение из магазина вообще не нужно и хватит PWA: об этом заметка «Мобильное приложение или PWA». Если нужно — посмотрите, как я делаю мобильные приложения. Для отметки посещений и выездной работы есть отдельная страница — приложение с QR-отметкой.
